HN

Comments (26)

• CJefferson
  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'.
• tialaramex
  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.
• Menu

  Terr_
  > 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".
• Menu

  quietbritishjim
  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.
• tmtvl
  And that's why all the experts program in APL.
• sph
  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.
• MarkusQ
  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`).
• Menu

  hiAndrewQuinn
  >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).
• wwind123
  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.
• Menu

  Jtsummers
  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
• AdieuToLogic
  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: >oOO3= :-)
• Menu

  aidenn0
  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.
• alok-g
  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.
• Menu

  sakex
  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++.
• epolanski
  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.
• Menu

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