>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).
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.
* 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.
> 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".
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`).
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.
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:
"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.
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++.
>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).
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.
I would modify Stroustrup's rule like so:
* 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.
> 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".
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`).
One corollary:
Your students will be mad right away if you teach them the terse syntax, but mad later if you teach them the verbose syntax.
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.
The discussion for the (linked by Hillel) defunct web page when it was submitted a decade ago here:
https://news.ycombinator.com/item?id=13192052 - 16 December 2016, 73 comments
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:
:-)Something similar for human languages:
"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.
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++.
But that's not a rule, it should be Stroustrop's Observation:
For new features, people insist on LOUD explicit syntax.
For established features, people want terse notation.
A rule can be prescriptive (thou shalt...) or descriptive (it's always true that...).
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.