> "I think elegant abstractions are more important than readable code” Typically, that is not the argument. Typically, the argument is that the "elegant abstra

> "I think elegant abstractions are more important than readable code” Typically, that is not the argument. Typically, the argument is that the "elegant abstraction" is just as readable, just in a different way. And further, the typical argument for elegant abstractions is that the “readable code” option is usually most readable for a specific, narrow problem to solve, and that it breaks down when you try to do more complicated things. So if you buy the argument in favour of elegant abstractions, you are trying to make “simple things simple, and complicated things possible.” Whereas the argument in favour of special keywords and other special-purpose constructions is that they also make simple things simple, but do little to make complicated things possible. The argument in favour of languages having these “readability” constructs is actually that they foster standardization, which makes them readable by virtue of the fact that everyone settles on doing them the same way. Which means in fact that they aren’t more readable in an isolated, objective sense. They’re actually more familiar. That has value in its own right, of course. But I don’t think the author--or anyone else who isn’t thrilled by some of the TC-39 choices--is arguing that there is an elegance vs. readability dichotomy. In actual fact, the argument is between elegance and familiarity by fiat.