Stroustrup's Rule (2024)

# Stroustrup's Rule Source: [https://buttondown.com/hillelwayne/archive/stroustrups-rule](https://buttondown.com/hillelwayne/archive/stroustrups-rule) Just finished two weeks of workshops and am*exhausted*, so this one will be light\. ### Hanuka Sale *Logic for Programmers*is on sale until the end of Chanukah\! That's Jan 2nd if you're not Jewish\.[Get it for 40% off here](https://leanpub.com/logic/c/hannukah-presents)\. ## Stroustrup's Rule I first encountered**Stroustrup's Rule**on this[defunct webpage](https://web.archive.org/web/20240914141601/https:/www.thefeedbackloop.xyz/stroustrups-rule-and-layering-over-time/): > One of my favorite insights about syntax design appeared in a[retrospective on C\+\+](https://learn.microsoft.com/en-us/shows/lang-next-2014/keynote)[1](https://buttondown.com/hillelwayne/archive/stroustrups-rule#fn:timing)by Bjarne Stroustrup: - For new features, people insist on**LOUD**explicit syntax\. - For established features, people want terse notation\. The blogger gives the example of option types in Rust\. Originally, the idea of using option types to store errors was new for programmers, so the syntax for passing an error was very explicit: ``` let file = match File::open("file.txt") { Ok(file) => file, Err(err) => { return err; } } ``` Once people were more familiar with it, Rust added the`try\!`macro to reduce boilerplate, and finally the[`?`operator](https://github.com/rust-lang/rfcs/blob/master/text/0243-trait-based-exception-handling.md)to streamline error handling further\. I see this as a special case of[mental model development](http://teachtogether.tech/en/index.html#s:models): when a feature is new to you, you don't have an internal mental model so need all of the explicit information you can get\. Once you're familiar with it, explicit syntax is visual clutter and hinders how quickly you can parse out information\. \(One example I like: which is more explicit,`user\_id`or`user\_identifier`? Which do experienced programmers prefer?\) What's interesting is that it's often the*same people*on both sides of the spectrum\. Beginners need explicit syntax, and as they become experts, they prefer terse syntax\. The rule applies to the overall community, too\. 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\. This can make it harder for beginners to learn the language\. There was a lot of drama in Python over the["walrus" assignment operator](https://peps.python.org/pep-0572/): ``` # Without walrus val = dict.get(key) # `None` if key absent if val: print(val) # With walrus if val := dict.get(key): print(val) ``` Experts supported it because it made code more elegant, teachers and beginners opposed it because it made the language harder to learn\. Explicit syntax vs terse notation\. Does this lead to languages bloating over time? ### In Teaching I find that when I teach language workshops I have to actively work against Stroustrup's Rule\. The terse notation that easiest for*me*to read is bad for beginners, who need the explicit syntax that I find grating\. One good example is type invariants in TLA\+\. Say you have a set of workers, and each worker has a counter\. Here's two ways to say that every worker's counter is a non\-negative integer: ``` \* Bad \A w \in Workers: counter[w] >= 0 \* Good counter \in [Workers -> Nat] ``` The first way literally tests that for every worker,`counter\[w\]`is non\-negative\. The second way tests that the`counter`mapping as a whole is an element of the appropriate "function set"— all functions between workers and natural numbers\. The function set approach is terser, more elegant, and preferred by TLA\+ experts\. But I teach the "bad" way because it makes more sense to beginners\.