* 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.

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 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".

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`).

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).

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
  }

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 ≜

https://news.ycombinator.com/item?id=13192052 - 16 December 2016, 73 comments

Your students will be mad right away if you teach them the terse syntax, but mad later if you teach them the verbose syntax.

"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.

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).

  >oOO3=

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.

For new features, people insist on LOUD explicit syntax.

For established features, people want terse notation.