* 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.
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.
In the below code snippet, that it is assumed was gotten on GitHub or a documentation site or somewhere else, you are not allowed to figure out which edition the code is meant for. You must tell, without knowing the edition, whether the code has a deadlock or not. You may not assume a specific edition.
fn f(value: &RwLock<Option<bool>>) {
if let Some(x) = *value.read().unwrap() {
println!("value is {x}");
} else {
let mut v = value.write().unwrap();
if v.is_none() {
*v = Some(true);
}
}
}
If you are not able to, you must delete all your social media accounts and never comment on any topic related to programming languages or Rust ever again.
In my point of view, editions do not achieve much more than a plain -std=langXY, alongside clang-tidy, or equivalent depending on the compiler, or AI based tool.
Because they don't support as many language and standard library evolution scenarios, as many think they do.
> 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".
This is why I think the "AI agents are useless for seniors" framing is misleading.
Unless you're doing something very niche and specific, you will constantly encounter new libraries, new domains, new protocols, new things you're not that familiar with. Very few people are an expert in CORS, Postgresql query optimization, advanced Typescript generics, setting up Blue-green deployments on Kubernetes, and modeling the domain of labor union disputes in the automotive industry. It is not impossible for one software engineer to need to touch all five within a week.
AI isn't really an expert in any of them either, but if it's something you need once and expect to never need again, it can often get you past whatever hump you're facing right now.
I think it's more like "LLMs agents are especially dangerous for beginners in $X."
Those are the users who won't have (as much) necessary knowledge, unused mental-bandwidth, or "instinctive taste" to recognize things that need validation and then fact-check them.
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`).
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).
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'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.
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.
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.
> Writing few characters more has never been an issue, at best it's annoying.
I don't think the implication is that writing is the issue. In my experience it's the _reading_ that is an issue. I don't mind writing verbose code -- I don't enjoy it but I'd understand the rationalisation in a team of developers that prefer that -- not as much as I mind _reading_ verbose code myself. It feels like you hit the brakes and the accelerator interchangeably. Which proves the point the law is trying to make, for my part.
"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.
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:
>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).
> probably evolved from something like the author's own `alias eg="grep -r"` pattern
this is from the official faq:
> When I first started writing ripgrep, I called it rep, intending it to be a shorter variant of grep. Soon after, I renamed it to xrep since rep wasn't obvious enough of a name for my taste. And also because adding x to anything always makes it better, right?
> Before ripgrep's first public release, I decided that I didn't like xrep. I thought it was slightly awkward to type, and despite my previous praise of the letter x, I kind of thought it was pretty lame. Being someone who really likes Rust, I wanted to call it "rustgrep" or maybe "rgrep" for short. But I thought that was just as lame, and maybe a little too in-your-face. But I wanted to continue using r so I could at least pretend Rust had something to do with it.
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.
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'.
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++.
In well thought out C++ software lifetime rarely becomes an issue because deciding on ownership and object lifetime is unavoidable as part of the design process.
Language "pedants" such as "grammar nazis" confuse their prescriptions for how they believe a language should be used for descriptions of how it is used and then get angry because they're wrong.
But equally confusing descriptions of Mother Nature's laws for a prescriptive rule you could defy won't end well. No matter how many TikTok viewers you have, or how fervent their belief in your ability to fly, no matter how many US Supreme Court Justices have insisted that the US constitution says you can fly, when you jump off the roof Gravity doesn't give a shit and you're going down.
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.
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.
A challenge:
In the below code snippet, that it is assumed was gotten on GitHub or a documentation site or somewhere else, you are not allowed to figure out which edition the code is meant for. You must tell, without knowing the edition, whether the code has a deadlock or not. You may not assume a specific edition.
fn f(value: &RwLock<Option<bool>>) {
}If you are not able to, you must delete all your social media accounts and never comment on any topic related to programming languages or Rust ever again.
In my point of view, editions do not achieve much more than a plain -std=langXY, alongside clang-tidy, or equivalent depending on the compiler, or AI based tool.
Because they don't support as many language and standard library evolution scenarios, as many think they do.
> 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".
More concretely, as many as half of the users of a popular programming language will have less than four years of experience: https://entropicthoughts.com/python-programmers-experience
This is why I think the "AI agents are useless for seniors" framing is misleading.
Unless you're doing something very niche and specific, you will constantly encounter new libraries, new domains, new protocols, new things you're not that familiar with. Very few people are an expert in CORS, Postgresql query optimization, advanced Typescript generics, setting up Blue-green deployments on Kubernetes, and modeling the domain of labor union disputes in the automotive industry. It is not impossible for one software engineer to need to touch all five within a week.
AI isn't really an expert in any of them either, but if it's something you need once and expect to never need again, it can often get you past whatever hump you're facing right now.
I think it's more like "LLMs agents are especially dangerous for beginners in $X."
Those are the users who won't have (as much) necessary knowledge, unused mental-bandwidth, or "instinctive taste" to recognize things that need validation and then fact-check them.
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 operator exists as a macro in rust as dbg[1]. I know this wasn't the point of your comment; I just thought it was a funny coincidence.
[1] https://doc.rust-lang.org/std/macro.dbg.html
Yup.
But 1) `dbg!(·)` uses normal syntax and 2) my expository version is two characters shorter. :)
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).
Mainly I disliked the walrus operator because Python already has a keyword that means "capture the output of this clause into this variable": as.
E.g.,
And now: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
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'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.
[1] Kevin Murphy's machine learning books use ≜
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
And here's an archive for that defunct web page https://web.archive.org/web/20210118175621if_/https://www.th...
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.
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.
> Writing few characters more has never been an issue, at best it's annoying.
I don't think the implication is that writing is the issue. In my experience it's the _reading_ that is an issue. I don't mind writing verbose code -- I don't enjoy it but I'd understand the rationalisation in a team of developers that prefer that -- not as much as I mind _reading_ verbose code myself. It feels like you hit the brakes and the accelerator interchangeably. Which proves the point the law is trying to make, for my part.
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.
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:
:-)>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).
> probably evolved from something like the author's own `alias eg="grep -r"` pattern
this is from the official faq:
> When I first started writing ripgrep, I called it rep, intending it to be a shorter variant of grep. Soon after, I renamed it to xrep since rep wasn't obvious enough of a name for my taste. And also because adding x to anything always makes it better, right?
> Before ripgrep's first public release, I decided that I didn't like xrep. I thought it was slightly awkward to type, and despite my previous praise of the letter x, I kind of thought it was pretty lame. Being someone who really likes Rust, I wanted to call it "rustgrep" or maybe "rgrep" for short. But I thought that was just as lame, and maybe a little too in-your-face. But I wanted to continue using r so I could at least pretend Rust had something to do with it.
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.
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'.
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++.
In well thought out C++ software lifetime rarely becomes an issue because deciding on ownership and object lifetime is unavoidable as part of the design process.
But explicit terse and leveraging on common vocabulary is often if not always also an option.
And that's why all the experts program in APL.
[flagged]
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.
And muddling these two goes poorly
Language "pedants" such as "grammar nazis" confuse their prescriptions for how they believe a language should be used for descriptions of how it is used and then get angry because they're wrong.
But equally confusing descriptions of Mother Nature's laws for a prescriptive rule you could defy won't end well. No matter how many TikTok viewers you have, or how fervent their belief in your ability to fly, no matter how many US Supreme Court Justices have insisted that the US constitution says you can fly, when you jump off the roof Gravity doesn't give a shit and you're going down.