Translation: The tragedy of common lisp

Your attention is invited to the translation of the letter of Mark Miller , one of the members of the JavaScript Standardization Committee. In this letter, Mark explains what “creeping ficherism” can lead to in the design of programming languages. And why he does not want to add the let-block syntax to javascript.

I am not going to support the initiative to add such syntax to javascript. Moreover, if someone invites you to do this, then I will make every effort to bury such an undertaking. And that's why.

The developers praised Algol, Smalltalk, Pascal, and early versions of Scheme for their small size and beautiful syntax. JavaScript and C were convincingly criticized for different things, and few could take them for languages ​​with a beautiful syntax. But they had a small specification size, and this was always appreciated by the developers. When the description of a programming language is small, then such a language is often perceived as “I can learn the syntax completely and thereby master the language perfectly,” which then changes to “I know the syntax completely. I like the fact that there is nothing in the language that I don’t know about. ” Although, of course, for JavaScript and C, only a few of those who think so, in fact, thoroughly know these languages. In their dark corners hidden many devilishly tangled details. Nevertheless, these feelings added satisfaction with everyday use of a programming language.

The aesthetics of a small language specification persisted until ES5. I actively participated in the development of both ES5 and ES6, and am proud of my contribution to the language. Yes, the ES6 specification is much more than the ES5, but, nevertheless, the language itself has become much better. Considering where we started, we would not have made such progress in the usability of ES6 without significantly expanding its specification. And I do not regret most of the additions that have turned ES5 into ES6. If I had the opportunity to return to the past and replay everything, then I probably would have done everything the same way.
')
But each of the extras that turned ES5 into ES6 should have matched a very high bar. Psychologically, it played a big role for us, since we started with ES5, the size of the specification of which we still appreciated. When the size of the specification is small, each improvement added to it looks like a significant increase in the “weight” of the specification. The use of features is clearly visible to those who offer them. But for a language with a small specification, the price of such a feature is also clearly visible to everyone - how much complexity it adds to the language.

When the complexity of a programming language exceeds a certain value - for example, like LaTex, Common Lisp, C ++, PL / 1 or modern Java, the experience of using such a language turns into a painful selection of a “set of features” for personal use from the seemingly endless ocean of features of this language . Most of which we do not want to ever study. However, even if the set of features of the language seems endless to us, we can easily appreciate the advantages of a single new feature. But the complexity that this feature will add to the language is not so easy to evaluate. Those who discuss new features for such languages ​​are no longer ways to “feel” the complexity added by these features. After all, infinity plus one - it is still infinity. That same “death from a thousand cuts”, which causes these monstrous tongues to grow without any restrictions.

Colleagues, I ask you when you evaluate a new feature for a language - set a higher level than “it would be cool if we could write more like that”. I believe that the ES6 specification is still in a state where it is possible to avoid unlimited growth. But this is possible only if we limit ourselves to wanting to fill in a bit more features, and adhere to only the highest quality standards for everything that we want to add to the language. As a community, a slight sense of panic about the size of the ES6 specification will not hurt us. Ideally, this panic will increase, not decrease, as the size of the language specification approaches the point of no return.

Respectfully,
Mark

Translator's Note

The proposal, after which Mark wrote this note, you can see here . It proposed adding syntactic sugar, which would allow instead of

{ //      let a = 2, b, c; //   ... } 

write something like

 let (a = 2, b, c) { } 

The translator shares Mark's opinion. Moreover, I believe that if it became necessary in the code to isolate a part of it in such a “let block”, then it is time to refactor this part into a function, method, mixin, or something else. Because the complexity does not sleep, and Miller's Wallet is just waiting to chop off something that is necessary for the programmer who is not working.