This feels like a pointless semantic trap. Everything is "waffling" or "wiggling". I don't see the parent saying anything in a disguised manner. It's just that reality is complicated. In the immediate wake of violence, it's exceedingly easy to paint any sentiment aside from "this is horrible" as disrespectful or weasel-worded. That's cheap (as I mentioned elsewhere, it's like the way conservatives refuse to talk about guns in the wake of gun violence).
Maybe I have a bit of a brain problem, but for me, 90% of the effort that goes into learning anything in tech is spent on identifying which nouns are Nouns, and which are just nouns, and the (often mushy) semantics of how people use those nouns in varying contexts and sub-contexts. I understand the reasons for this complexity - domain-specific terminology is valuable and forms naturally from pre-existing words. It's just that, in tech, everything is abstract, and everything consists of multiple contexts spread across multiple dimensions (vertically, in abstraction layers; horizontally, in use cases), so the domain-specific terminology explodes like an exponential web. Sometimes I'm talking to somebody and they are using some word, and it takes me days to even realize that they are using it in a much more specific context than I assumed. It's a little hellish.
"Property" here comes from mathematics (and I guess similar definition to science). What are the properties of this function? E.g. x * y has the property that x * y = y * x.
So we do import stuff from Mathematics alot.
I think we need better tutorials. It is a hard problem. How to teach something, who is your audience. For an AI tutorial, do I need to explain what inference is? Maybe. If I don't and they don't know it is another weird word.
In terms of brain problem - I have the same thing. It is worse inside the corporate barrier as there is no internet documentation on what the terms mean. I think all we can do is slow down and write cheat sheets until we remember.
I agree. It’s especially weird moving across related domains because suddenly something you think you know has changed meaning. For instance eBPF is “verified”, but the verification is almost completely unrelated from the usual connotations.
Since we are talking about Haskell, its type system can be explored to answer the question of what is considered a Property by the quickcheck library.
The Property type is a datatype for which the definition is private. So we look at functions that creates Property objects. We find
class Testable prop where
property :: prop -> Property
This means anything of the class Testable can be turned into a Property. So let's look at what are the instances of this class. We immediately find
instance Testable Bool
This means any boolean can be turned into a Property. But more interestingly we find
instance (Arbitrary a, Show a, Testable prop) => Testable (a -> prop)
This means any function where the argument has a generator and the result can be turned into a Property can itself be turned into a Property. This implies that for example a function of `Int -> Bool` can be turned into a property. And due to currying, `Int -> Int -> Bool` can also be turned into a property.
This basically covers the first half of the article.
We continue to find other functions that returns Property objects. We find
forAll :: (Show a, Testable prop) => Gen a -> (a -> prop) -> Property
This states that if we have a function where we explicitly provide a generator and it returns anything that can be turned into a Property, it can also be turned into a Property. This is different from the instance above only by providing an explicit generator.
This states that if we have a Bool, and anything that can be turned into a property, we also have a property.
You see, the beauty of Haskell and similar languages is that you don't need to first gain an intuitive understanding of those vocabularies of a library. The library designer has built up an abstraction of those vocabularies and Nouns and the compiler is tasked to enforce it. You can get things wrong, and the compiler just yells at you. Or you can just mechanically find things to fill in the blanks ("hole-driven development") without understanding the vocabularies. It's your choice.
If I have to resort to hole-driven development then it seems like something has gone very wrong? I like to understand the libraries I’m using. Libraries should have good API documentation and intuitive type definitions. I shouldn’t have to carefully study how they’re put together, like solving a math homework problem.
It doesn't help that many texts approach this as a very pseudo-mathematics abstract. It's not a function, it's an implication. It's there are satisfactions of preconditions, there's a thousand different things.
Unfortunately, very few texts and tutorials on property-based testing actually tell you how to see what properties are. I have it on paper somewhere in some workshop materials. But online I think this is one of the very few that describe what they are: https://fsharpforfunandprofit.com/posts/property-based-testi...
In the link above he's described 7 very practical ways to use it. No functional jargon, no mathematical jargon. Just practical useful ideas. And the language choice in the book is irrelevant - the concepts translate well.
There is an alternate universe where he would be well known as the top author on software engineering. His website is great as well.
That said, if you do know a bit of the math his example introduced commutative, invertible, invariance, idempotency, structural recursion & isomorphism - but anyone reading it would never really know and would never need to know. It's just framed as useful applications of tests.
The worst thing is being corrected about minutiae. It's not a "property" it's an attribute/field/member/key/column/variable/getter/function/procedure. Deep down it's all variables. Even the constants are variables from the viewpoint of the CPU that has to load it in its registers.
Sometimes I see people saying "in LANG, obj.foo is just 'syntax sugar' for foo(obj)" and I think that technically it has always been "syntax sugar" and there have always been ways to call any "method" with any "object" of any "type."
Sometime along the way we decided that "syntax sugar" means "it means the same thing as" but except for (<cast OtherType>obj).foo(), which means that the semantics of "syntax sugar" don't mean it's simpler than the phrase it was supposed to replace.
> It's not a "property" it's an attribute/field/member/key/column/variable/getter/function/procedure.
For what it's worth, to a researcher in the field of programming languages (like the author of the post), these all have distinct unambiguous meanings. At least as far as PL goes, almost every term has a well-defined meaning, but as those terms were adopted into less-than-academic contexts, the meanings have diluted.
"Property" is such a term in the context of programming languages research, and, in particular, it is a very specifically defined term in the realm of property-based testing (no surprise).
> Even the constants are variables from the viewpoint of the CPU that has to load it in its registers.
No; this is not what "variable" means. Registers are properties of the processor, i.e., they are implementation details; variables are an abstract concept from the domain of the formal language specification.
> Sometime along the way we decided that "syntax sugar" means "it means the same thing as" but except for (<cast OtherType>obj).foo(), which means that the semantics of "syntax sugar" don't mean it's simpler than the phrase it was supposed to replace.
No; this is not what "syntax sugar" means. If a language defines some syntax f and it "expands to" some other syntax g, then f is syntax sugar for g. This is well defined in Felleisen's "On the Expressive Power of Programming Languages" [0]. For example, Python's addition operator `+` is implemented in terms of a method `__add__`; therefore, `a + b` is syntax sugar for `a.__add__(b)`, because the former syntax is built on top of the latter.
Notably, syntax sugar has nothing to do with casts; casts are semantic, not syntactic. There are also no promises about whether syntax sugar makes something "easier"; it's simply the ability to syntactically express something in multiple ways.
I'd also like to add that, since immediate-operand instructions exist, constants are absolutely not the same as variables at the machine level, since immediates will never be stored in a register (typically, e.g. "move immediate" will obviously store it in one, and I'm sure there are architectures that use an internal/hidden register that's populated during instruction decode).
Also, in Harvard-architecture systems, the constants, being part of the instruction itself, might not even be in the same memory or even address space as variables ([EEP]ROM/Flash vs RAM).
The problem is that the same word is used for different things.
The comment you are responding to was correct in what "property" means in some settings.
The article itself says:
> A property is a universally quantified computation that must hold for all possible inputs.
But, as you say,
> but as those terms were adopted into less-than-academic contexts, the meanings have diluted.
And, in fact, this meaning has been diluted. And is simply wrong from the perspective of what it originally meant in math.
You are right that a CPU register is a property of the CPU. But the mathematical term for what the article is discussing is invariant, not property.
Feel free to call invariants properties; idgaf. But don't shit all over somebody by claiming to have the intellectual high ground, because there's always a higher ground. And... you're not standing on it.
My point was not that there exists some supreme truth about what words mean and that either you use words "correctly" or you're an idiot.
Yes, words have different meanings in different settings, but that's not the dilution I was referring to. It's absolutely fine that a word can be used differently in different places.
The "problem", such as it is, is that there are people who use terms from programming languages research to discuss programming languages and they use these terms inaccurately for their context, leading to a dilution in common understanding. For example, there is a definitive difference between a "function" and a "method", and so it is inaccurate to refer to functions generally as "methods". However, I see people gripe about interactions where these things are treated separately, and that is what I am addressing.
The parent comment to mine tried to offer some examples of such terms within the context of programming languages, so my corrections were constrained to that context. But your correction of my point is, I think, incorrect, because the meaning you are trying to use against me is one from a different context than the one we're all talking about.
There's no intellectual high ground here; my point was not to elevate myself above the parent comment. My point was to explain to them that they were, from the point of view of people like the author of the post (I assume), simply incorrect. There's nothing wrong with being wrong from time to time.
With most disciplines theres usually a historical reference, homage, or literal-ness to the naming conventions… that can be searched for that will tend to help in illumination.
With software it kind of sort of started out that way… and has seemly devolved into this semblance of appropriating every word ever for who-the-fuck-knows-what… gotta say it’s better than pharmaceutical’s naming conventions. I mean at least software tends to use actual words!
English (int al) distinguishes "proper" nouns as a subset of nouns. A proper noun is a name and is capitalized. Hence you might write: King Charles is a king. Now, you also capitalize the first word of a sentence but here King is not the first word of a sentence - King Charles is a name. If you make a small change (indefinite to definite article), you get: King Charles is the King. The second king becomes a moniker and no longer just a description.
English also tends to get capitalization-loopy as soon as religion rocks up (any religion).
You can obviously ignore all that bollocks and write whatever you like, mostly without blushing!
Some other related languages eg German, capitalize all nouns.
Maybe this is a joke about the dangers of being abstract going over my head, but I don’t think they literally meant they don’t understand capitalization rules :)
I was being humorous/pithy. I meant e.g. the difference between "property" (the dictionary word) and "property" (the programming word, which is a domain-specific usage of the dictionary word) and "property" (as in Property-Based Testing, an even more domain-specific usage). It's analogous to the concept of regular nouns vs proper nouns, but not the same (which is why I didn't use the term "proper noun").
It seems like "jargon" fits the need for a way to label the more specific meaning intended, like "property from objected oriented programming jargon." I think programmers might differ without the more specific description on if OOP, or say, the abstract algebra meaning, of property would be intended, since both seem relevant to different contexts of programming.
I am not speaking for the parent, but my personal interpretation is that they are trying to add perspectives/thoughts, not denying what Dan said (i.e. it's not "inadvertent" in as few words).
Yes, fully agree. Nonetheless, I suspect violence can be used more effectively and more minimally if it's considered and performed by a group rather than haphazardly by individuals. I recognise that's a very simplistic view.
I think it's as realistic as it is simplistic. The State gets a monopoly on violence so that you can sue someone who wrongs you instead of killing them. When conversation and cash fail, violence is all that's left, and we concentrate that power in groups of people tasked with deciding when the alternatives have failed. It doesn't always work but it's a better alternative than the individualized bloodlust disappointingly endorsed elsewhere in this thread.
A lot of what happened during the French revolution was horrific... This is such a bewildering sentence in this context. Yes, killing the rulers is horrific. Revolutions are horrific. Wars are horrific. It seems irrelevant to what the parent is (sarcastically) saying.
Their point was that violence is sometimes justified, using the French Revolution as an example. I'm pointing out that the FR wasn't just a matter of "killing the rulers". Many, many people were killed. It wasn't such an unambiguous good as they seemed to be implying. Also, other countries have transitioned to democracy without such bloodshed.
FYI, you started out with a very common word used to exaggerate or cherry-pick the opinions of enemies ("giddy").
It's more valuable to discuss grievances than to pretend they are simply un-discussable in the wake of related violence (in the vein of "it would be disrespectful to talk about gun control in the wake of gun violence").
Historically, was it always so common for powerful or famous people to seem to purposefully garner hatred like he, and others, have been for the past decade? To speak in a petty, self-important, "trolling" manner, to a very broad audience? To embrace traits that are intrinsically negative? Or are we living in a rare time?
New England colonists had a habit of ransacking and burning down the houses of government officials throughout the 1760s and during the Revolutionary War. Got bad enough that most did not sleep in their government housing.
Yes, but when it comes to politically-motivated murder attempts by random people, part of this is because surveillance technology and policing effectiveness have gotten to the point that it is very difficult to get away with such a murder attempt. See how Luigi Mangione was caught, for example. Many murders are unsolved every year, but when there is a high-profile politically motivated killing, the police seem to really go all-out to solve it.
If it wasn't for the effective policing, I think that such incidents would be more common.
His response here is a synthesis of 1) addressing the "incendiary article" 2) conflating it with a recent attack on himself and 3) joking about having "fewer explosions in fewer homes" at the end. As a reader it's hard to tell if he wants us to empathize with him or laugh at his misfortune. The self-depricating humor does not mix well with photos of his family and an (ostensibly) life-threatening situation.
From the outside looking in, Altman is stressed and showing the same traits that people are accusing him of. He "brushed [...] aside" the article without ever thinking about addressing it, and now he's sitting down "in the middle of the night and pissed" like some Jobsian seraph, furiously condemning society at-large for not understanding his vision where AGI is the end-times. This is probably reassuring news for the market, but on an individual level I'm having a hard time believing in Altman's narrative. OpenAI is a Department of Defense contractor, it's hard to believe that Altman is capable of resisting coercion when they've already capitulated for peanuts. If Sam was a sociopath, it would probably be very easy for him to justify this with threats of AGI and promises about how much safer we are with him in control. Coincidentally exactly what he spends much of this article reiterating, but I'll let you draw your own conclusions.
reply