Common Lisp tragedy: why popular languages swell in complexity
Adapted from 2015 discussion . Here Common Lisp is just one of many illustrative examples.
The future of javascript?
I have been working in the JavaScript Standards Committee (TC39) since 2007. We appreciate the simplicity of the language, but over time have lost their vigilance. The difficulty has become uncontrollable to grow. We need to figure out why this happens naturally, what the price is and what to do about it. This article is addressed not only to colleagues from TC39, but also to everyone who wants to influence the trajectory of the development of JavaScript or any standard that is faced with similar pressure. Learn from our mistakes!
Algol, Smalltalk, Pascal and early Scheme were loved as small and beautiful languages. Early C and JavaScript were rightly criticized for many things and were rarely called beautiful. But they were also small, and it was very much appreciated. When a language is small, our assessment is often determined by the feeling: “I can learn everything and master it,” and then: “I know everything. I like that there are no unknown details left . ” But in the case of C and JavaScript, it was unlikely that someone had a feeling of complete mastery of the language, since the details were in fact devilishly complex. However, the feeling of “small language” largely determined the satisfaction of everyday use.
')
The aesthetics of JavaScript minimalism is preserved in the EcmaScript-5 standard. I actively participated in the development of EcmaScript-5 and EcmaScript-2015, and in both cases I am proud of my contribution. EcmaScript-2015 has grown much in size, but has brought improvements with it. Considering what we started with, it was impossible to improve JavaScript without such an increase in size. I do not regret most of the additions that led to EcmaScript-5 swelling to EcmaScript-2015. If you go back, probably in many cases I would suggest similar additions.
Each of the additions had to overcome a very high bar. Psychologically, it made sense, because we were equal to the minimalism of EcmaScript-5. When a language is small, each additional function is intuitively felt as a significant percentage increase in the size of the language. The specific benefits of the function are always visible to its supporters. For a small language, the contribution of the new feature to the increase in total is also still visible to everyone.
As soon as a language goes beyond a certain complexity - say, LaTeX, Common Lisp, C ++, PL / 1, modern Java - programming becomes more like cutting out a subset of functions for personal use from an infinite sea of functions, most of which we will never learn and put up with with this. As soon as a language is perceived as “infinite,” the specific benefits of the new function are still clear. But the total costs associated with added complexity are no longer apparent. They are no longer felt by those discussing the new function.
.
Even .
This is the death of a thousand cuts, which causes these monsters to grow without any restrictions.
Therefore, I ask everyone who influences the language to apply a higher level when considering a new function than “it is not bad to have such an opportunity, isn't it?”. I believe that EcmaScript-2015 is located on the border area where rampant growth can still be prevented, but only if we begin to restrain each other with high standards for any proposed new function. As a community, we need a more general feeling of panic over the size that EcmaScript-2015 has already reached. Ideally, as the language grows, when the size approaches the point of no return, the panic should increase, not decrease.
Maintain minimal uneven pressure
The relevance of minimalism weakens as the transition from the basic language to the library. Standard language as a whole can be represented as the following structure:
I listed them in order, in accordance with my sense of increasing growth costs and the urgent need for minimalism. For all this, it is necessary to exercise discipline. Only on the last point we can allow unlimited growth, but it is desirable that candidates pass community testing and are accepted de facto first. Ideally, the TC39 committee will cease to be a bottleneck, since external processes are de facto and de jure able to independently develop standard modules for convenience.
The future of javascript?
I have been working in the JavaScript Standards Committee (TC39) since 2007. We appreciate the simplicity of the language, but over time have lost their vigilance. The difficulty has become uncontrollable to grow. We need to figure out why this happens naturally, what the price is and what to do about it. This article is addressed not only to colleagues from TC39, but also to everyone who wants to influence the trajectory of the development of JavaScript or any standard that is faced with similar pressure. Learn from our mistakes!
Algol, Smalltalk, Pascal and early Scheme were loved as small and beautiful languages. Early C and JavaScript were rightly criticized for many things and were rarely called beautiful. But they were also small, and it was very much appreciated. When a language is small, our assessment is often determined by the feeling: “I can learn everything and master it,” and then: “I know everything. I like that there are no unknown details left . ” But in the case of C and JavaScript, it was unlikely that someone had a feeling of complete mastery of the language, since the details were in fact devilishly complex. However, the feeling of “small language” largely determined the satisfaction of everyday use.
')
The aesthetics of JavaScript minimalism is preserved in the EcmaScript-5 standard. I actively participated in the development of EcmaScript-5 and EcmaScript-2015, and in both cases I am proud of my contribution. EcmaScript-2015 has grown much in size, but has brought improvements with it. Considering what we started with, it was impossible to improve JavaScript without such an increase in size. I do not regret most of the additions that led to EcmaScript-5 swelling to EcmaScript-2015. If you go back, probably in many cases I would suggest similar additions.
Each of the additions had to overcome a very high bar. Psychologically, it made sense, because we were equal to the minimalism of EcmaScript-5. When a language is small, each additional function is intuitively felt as a significant percentage increase in the size of the language. The specific benefits of the function are always visible to its supporters. For a small language, the contribution of the new feature to the increase in total is also still visible to everyone.
As soon as a language goes beyond a certain complexity - say, LaTeX, Common Lisp, C ++, PL / 1, modern Java - programming becomes more like cutting out a subset of functions for personal use from an infinite sea of functions, most of which we will never learn and put up with with this. As soon as a language is perceived as “infinite,” the specific benefits of the new function are still clear. But the total costs associated with added complexity are no longer apparent. They are no longer felt by those discussing the new function.
.
Even .
This is the death of a thousand cuts, which causes these monsters to grow without any restrictions.
Therefore, I ask everyone who influences the language to apply a higher level when considering a new function than “it is not bad to have such an opportunity, isn't it?”. I believe that EcmaScript-2015 is located on the border area where rampant growth can still be prevented, but only if we begin to restrain each other with high standards for any proposed new function. As a community, we need a more general feeling of panic over the size that EcmaScript-2015 has already reached. Ideally, as the language grows, when the size approaches the point of no return, the panic should increase, not decrease.
Some differences
Maintain minimal uneven pressure
The relevance of minimalism weakens as the transition from the basic language to the library. Standard language as a whole can be represented as the following structure:
- Fundamental syntax : special forms that cannot be accurately expressed by a local extension to another syntax.
- Semantic state : a state that is manipulated by a calculation.
- Built-in kernel modules (kernel builtins): A part of the built-in library that provides functionality that custom code cannot provide by itself.
- Non-kernel intrinsics: non-kernel intrinsics: built-in libraries that can be implemented in JavaScript, but the semantic state or modules embedded in the kernel depend on them. For example, through a proxy, you can implement an array in user code. But in other modules built into the kernel, there is already a dependency on Array, which gives this particular array a privileged position over any intended replacement.
- Syntactic sugar : syntax that can be expressed by local extension to the fundamental syntax.
- Global libraries for convenience : can be implemented by unprivileged user code, but taking into account standard global naming paths in the original global namespace.
- Standard modules for convenience : Community-developed modules, approved as a standard.
I listed them in order, in accordance with my sense of increasing growth costs and the urgent need for minimalism. For all this, it is necessary to exercise discipline. Only on the last point we can allow unlimited growth, but it is desirable that candidates pass community testing and are accepted de facto first. Ideally, the TC39 committee will cease to be a bottleneck, since external processes are de facto and de jure able to independently develop standard modules for convenience.
Source: https://habr.com/ru/post/454486/
All Articles