Translation: The tragedy of common lisp

Original author: Mark S. Miller
  • Transfer
Your attention is invited to translate a letter from Mark Miller , one of the members of the JavaScript Standardization Committee. In this letter, Mark talks about what “creeping featureism” can lead to when designing programming languages. And why doesn’t he want to add the let-block syntax to javascript.

I am not going to support the initiative of adding such syntax to javascript. Moreover, if someone volunteers to do this, then I will do my best to bury such an undertaking. And that's why.

Developers praised Algol, Smalltalk, Pascal and earlier versions of Scheme for their small size and beautiful syntax. JavaScript and C were reasonably criticized for various things, and few could mistake them for languages ​​with beautiful syntax. But they had a small specification size, and this was always appreciated by the developers. When the description of the programming language is small, 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 left in the language that I would not know about. ” Although, of course, for JavaScript and C, only a few of those who think so actually actually know these languages ​​thoroughly. In their dark corners hidden many devilishly intricate details. Nonetheless,

The aesthetics of the small language specification persisted until ES5. I actively participated in the development of both ES5 and ES6, and I am proud of my contribution to the language. Yes, the ES6 specification is much larger than that of 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 a significant expansion of its specifications. And I do not regret most of the add-ons that turned ES5 into ES6. If I had the opportunity to return to the past and replay everything, then I most likely would do the same.

But each of the add-ons that turned ES5 into ES6 had to meet a very high bar. Psychologically, this played a big role for us, since we started with ES5, the specification size of which we still appreciated. When the specification size is small, each improvement added to it looks like a significant increase in the “weight” of the specification. The benefits of features are 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 “feature set” for personal use from the seemingly endless ocean of features of this language . Most of which we never want to study. Nevertheless, 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 is infinity anyway. The very “death from a thousand cuts” that makes these monstrous tongues grow without any restrictions.

Colleagues, I ask you when you are evaluating a new feature for the language - set a higher standard than “it would be cool if we could write more.” I believe that the ES6 specification is still in a state where it is possible to avoid unlimited growth. But this is only possible if we limit ourselves to the desire to fill up a little more features, and adhere to only the highest quality standards for everything that we want to add to the language. As a community, we won’t have a slight sense of panic regarding the size of the ES6 spec. Ideally, this panic will increase rather than decrease as the size of the language specification approaches the point of no return.

Regards,
Mark

Translator's Note


The proposal, after which Mark wrote this note, can be found here . It suggested adding syntactic sugar, which would allow instead

{ // блок для защиты локальных переменных
  let a = 2, b, c; // локальные переменные
  ...
}


write something like

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


The translator shares Mark’s opinion. Moreover, I believe that if the code needs to isolate part of it in such a “let block”, then it's time to refactor this part into a function, method, mixin or something else. Because the complexity is not slumbering, and Miller’s wallet is just waiting to chop off something that is needed for the gaping programmer.

Also popular now: