There's a missing dimension: orthogonality. Having terse notation that implements a feature that you can reason about in isolation is fine for both beginners and experts. But features that have complex interactions with their environment are hard to reason about regardless of the syntax (though bad syntactic choices can certainly make it worse).
You can introduce a notation that's terse without problem, so long as it's comprehensible when encoutered. Example: the (!·!) operator (which I just made up), which can be placed around any expression to log the value of the expression to STDOUT. Its value is the same as the expression (so `(!3+7!)` equals `10`).
* For new features, people insist on LOUD explicit syntax.
* For established features [that turned out to be used disproportionately often], people want terse notation.
So, I argue, it's not really people getting used to the feature that allows it to be terser. It's that enough time passes that you figure out what features are used enough that they warrant the terse syntax (like the Rust example he gave).
It's a form of selection bias: there are many other established features that are rarely used and left with a verbose syntax but you don't notice them later because, well, they're rarely used.
Right, and the exact same thing happens in all human languages. The reason we have words for things is they are common enough ideas to warrant one. There is probably no word for "the feeling one gets when floating in a sea of beans", although I am, of course, able to express this explicitly. If this feeling became important enough we'd probably start getting a word for it, possibly starting with a portmanteau like "beanfloat".
Ultimately we're just lazy and don't like having to use lots of words over and over again.
"The principle of least effort is another possible explanation: Zipf himself proposed that neither speakers nor hearers using a given language want to work any harder than necessary to reach understanding, and the process that results in approximately equal distribution of effort leads to the observed Zipf distribution.[5][31]" -- From: https://en.wikipedia.org/wiki/Zipf%27s_law
"Explicit syntax" would initially be less cognitive effort. Soon that effort would be gone and "terse notation" would lead to lesser typing effort.
This is why you should (generally) teach them both at the same time, or in close succession. If you're teaching Rust (to continue the example in the submission) you should show the verbose form, then the concise form with ?, and explain why you may want to leave something in the verbose form and how to transform code between the two forms. Maybe the explicit match becomes important to use, how do you go from ? to it so you can add more code than ? itself provides? Or code gets simplified and now your match is reduced to exactly what ? provides.
Another thing in that vein is features that were built because the previous approach was obtuse. For instance, find it harder to explain async/await in JS to people who never experienced callback hell, or why there is a borrow checker in Rust to people who never tried C++.
When the article mentioned the "Python 'walrus' assignment operator", which as defined is an homage to Pascal's version of same, a part of me hoped the operator was:
> as they become experts, they prefer terse syntax.
In my experience, the man-hours of expertise may be less than you'd think: I've probably spent more hours (or at least subjective frustration) being the beginner in different things than I have spent hours being able to enjoy expertise after earning it in a language/framework/convention/tool. Sometimes it's even the same subject, years later.
I propose that catering to "beginners in language" is under-valued, since it's not the same as "new in career".
Having observed that this is true, a good designer would see Rust's Editions and seize upon this as a useful, even necessary idea for a language intended to last for more than a few years.
In 2019 P1881 "Epochs" https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p18... was instead given the usual treatment by WG21, Vittorio was told it would be very difficult, numerous obstacles were identified and he was told to go away and solve them (implied: and if you come back we'll find more).
That paper was written after Rust's 2018 Edition (and of course the Rust 1.0 "2015 Edition" implied by the implementation of editions) but since then 2021 Edition and 2024 Edition both landed significant further improvements.
>At the beginning of a language's life, everybody's a beginner. Over time the ratio of experts to beginners changes, and this leads to more focus on "expert-friendly" features, like terser syntax.
Hence why so many shell classics are so short. You don't type R-I-P-G-R-E-P, you type R-G and get on with it, which itself probably evolved from something like the author's own `alias eg="grep -r"` pattern back in the day (that's me spitballing, I don't have proof of that claim).
I guess in this AI age, verbose language features may burn more tokens than terse versions. In that sense, it's probably more economical for the AI to consume and produce terse code. But of course, if the code is to be read by humans eventually, then maybe there could be a service to help explain the terse code if the human reader is confused, or automatically expand the terse code to verbose code at the human reader's comfort level.
Human knowledge is abstraction piled upon abstraction.
For the AI lovers, human brains run natural compression algorithms to maintain the context window small, which allows us to abstract further. The problem with
err := function()
if err != nil {
return err
}
in Go is that is such a common pattern it goes against our natural drive to simplify it so we are able to view more of the program.
I dislike terse notations even as an experienced engineer.
Writing few characters more has never been an issue, at best it's annoying.
I can understand the counter argument and it's benefits but in my experience one never discussed aspect is that terse notations are cool in isolation, yet quickly compound to hard to reason soups.
Take JavaScript: ternaries are cool, yet quickly become hard to understand when nested. Null coalescing operator (??) is cool in isolation, yet becomes hard to reason as soon as compounded with more operators.
Haskell combinators and arrows are the same.. Cool when taken alone, balloon energy needed to understand the code when you start compounding.
I feel this is on of those examples of where humanities and the softer sciences can teach us things. This is exactly how 'normal' languages work. New things are introduced and people (particularly older people) hate them. Over time common words (or even sounds) become shorter, in some cases disappearing entirely when they are 'understood from context'.
Even though the premise sounds true (kind of, sort of), everything about the post makes me question it. And it's not just that Stroustrup is among the last men I'd trust about syntax design, every example in the post just feels wrong.
Python walrus operator wasn't opposed by "teachers and beginners", because it's "harder to learn". Quite the opposite, it was opposed by purist old-timers, because for 20 years the absence of stuff like that was considered a feature and "the Python way". I don't think I pass as a beginner, but while I personally am not opposed to that operator, I totally get what's their problem with it. I think, that := is explicit enough, but addition-assignment was a native feature of most C-like languages which usage was actively discouraged by most teams, at least unless it really makes the concrete situation much more readable. Which the example in the post hardly does.
Rust ? operator isn't some example of terse Perl-like syntax, it's very intuitive and by no way it's any harder to grasp for a beginner, than the explicit match. In fact, it's probably the opposite, since it really matches the surface behavior. It only appeared after the explicit syntax, because it's really just syntactic sugar in Rust's case, and the language primitives are Ok/Err and pattern matching, not the "?" operator.
And I don't even know TLA+, but I could guess what "Good" example does, because it's basically plain English / standard math notation. The explicit "procedural" version is much less clear (mostly, because of the unfamiliar syntax).
I'm pretty ambivalent about this and don't really think the rule is true as stated. It also just comes across as pretty smug. In my experience the preference for terse/verbose or noisy/"quiet" syntax is really down to individual taste and how much things are used, rather than a function of how new or expert a person is.
Since TFA mentions the walrus ":=" operator in python, as an example from another field, when you first learn maths, you might define a function as "f(x)=x^2 - 2" or whatever. Later on, you'll start to see people write ":=" for definitions such as the above and the plain "=" sign just where you have an equation so you are specifying a particular value rather than a definition (eg you might see "let f: R->R be f(x):= x^2-2. Find x such that f(x)=0").
However, some sources (especially in physics or some books on analysis[1]) use an equals sign with an equilateral triangle over it (like this "≜") to mean definitional equality (ie ":="). Now to me, coming from a computer science background, := for a definition seems very natural and ≜ seems super weird, but that really is just down to what you're used to.
And through it all, some people just use "=" everywhere.
This being mathematics, the author gets to choose whatever syntax they want and readers just have to cope as best they can. In computer languages, people go into huge amounts of bike shedding trying to force everyone else to use (or not use) a particular thing.
24 comments
[ 8.2 ms ] story [ 70.3 ms ] threadYou can introduce a notation that's terse without problem, so long as it's comprehensible when encoutered. Example: the (!·!) operator (which I just made up), which can be placed around any expression to log the value of the expression to STDOUT. Its value is the same as the expression (so `(!3+7!)` equals `10`).
[1] https://doc.rust-lang.org/std/macro.dbg.html
https://news.ycombinator.com/item?id=13192052 - 16 December 2016, 73 comments
* For new features, people insist on LOUD explicit syntax.
* For established features [that turned out to be used disproportionately often], people want terse notation.
So, I argue, it's not really people getting used to the feature that allows it to be terser. It's that enough time passes that you figure out what features are used enough that they warrant the terse syntax (like the Rust example he gave).
It's a form of selection bias: there are many other established features that are rarely used and left with a verbose syntax but you don't notice them later because, well, they're rarely used.
Ultimately we're just lazy and don't like having to use lots of words over and over again.
For new features, people insist on LOUD explicit syntax.
For established features, people want terse notation.
The Golden Rule is the first. This is the second.
Nobody follows Hyrum's Law (also the second), they suffer from it inevitably applying to them.
"The principle of least effort is another possible explanation: Zipf himself proposed that neither speakers nor hearers using a given language want to work any harder than necessary to reach understanding, and the process that results in approximately equal distribution of effort leads to the observed Zipf distribution.[5][31]" -- From: https://en.wikipedia.org/wiki/Zipf%27s_law
"Explicit syntax" would initially be less cognitive effort. Soon that effort would be gone and "terse notation" would lead to lesser typing effort.
Your students will be mad right away if you teach them the terse syntax, but mad later if you teach them the verbose syntax.
In my experience, the man-hours of expertise may be less than you'd think: I've probably spent more hours (or at least subjective frustration) being the beginner in different things than I have spent hours being able to enjoy expertise after earning it in a language/framework/convention/tool. Sometimes it's even the same subject, years later.
I propose that catering to "beginners in language" is under-valued, since it's not the same as "new in career".
In 2019 P1881 "Epochs" https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p18... was instead given the usual treatment by WG21, Vittorio was told it would be very difficult, numerous obstacles were identified and he was told to go away and solve them (implied: and if you come back we'll find more).
That paper was written after Rust's 2018 Edition (and of course the Rust 1.0 "2015 Edition" implied by the implementation of editions) but since then 2021 Edition and 2024 Edition both landed significant further improvements.
Hence why so many shell classics are so short. You don't type R-I-P-G-R-E-P, you type R-G and get on with it, which itself probably evolved from something like the author's own `alias eg="grep -r"` pattern back in the day (that's me spitballing, I don't have proof of that claim).
For the AI lovers, human brains run natural compression algorithms to maintain the context window small, which allows us to abstract further. The problem with
in Go is that is such a common pattern it goes against our natural drive to simplify it so we are able to view more of the program.Writing few characters more has never been an issue, at best it's annoying.
I can understand the counter argument and it's benefits but in my experience one never discussed aspect is that terse notations are cool in isolation, yet quickly compound to hard to reason soups.
Take JavaScript: ternaries are cool, yet quickly become hard to understand when nested. Null coalescing operator (??) is cool in isolation, yet becomes hard to reason as soon as compounded with more operators.
Haskell combinators and arrows are the same.. Cool when taken alone, balloon energy needed to understand the code when you start compounding.
Python walrus operator wasn't opposed by "teachers and beginners", because it's "harder to learn". Quite the opposite, it was opposed by purist old-timers, because for 20 years the absence of stuff like that was considered a feature and "the Python way". I don't think I pass as a beginner, but while I personally am not opposed to that operator, I totally get what's their problem with it. I think, that := is explicit enough, but addition-assignment was a native feature of most C-like languages which usage was actively discouraged by most teams, at least unless it really makes the concrete situation much more readable. Which the example in the post hardly does.
Rust ? operator isn't some example of terse Perl-like syntax, it's very intuitive and by no way it's any harder to grasp for a beginner, than the explicit match. In fact, it's probably the opposite, since it really matches the surface behavior. It only appeared after the explicit syntax, because it's really just syntactic sugar in Rust's case, and the language primitives are Ok/Err and pattern matching, not the "?" operator.
And I don't even know TLA+, but I could guess what "Good" example does, because it's basically plain English / standard math notation. The explicit "procedural" version is much less clear (mostly, because of the unfamiliar syntax).
Since TFA mentions the walrus ":=" operator in python, as an example from another field, when you first learn maths, you might define a function as "f(x)=x^2 - 2" or whatever. Later on, you'll start to see people write ":=" for definitions such as the above and the plain "=" sign just where you have an equation so you are specifying a particular value rather than a definition (eg you might see "let f: R->R be f(x):= x^2-2. Find x such that f(x)=0").
However, some sources (especially in physics or some books on analysis[1]) use an equals sign with an equilateral triangle over it (like this "≜") to mean definitional equality (ie ":="). Now to me, coming from a computer science background, := for a definition seems very natural and ≜ seems super weird, but that really is just down to what you're used to.
And through it all, some people just use "=" everywhere.
This being mathematics, the author gets to choose whatever syntax they want and readers just have to cope as best they can. In computer languages, people go into huge amounts of bike shedding trying to force everyone else to use (or not use) a particular thing.
[1] Kevin Murphy's machine learning books use ≜