June 2, 2019 at 17:18The tragedy of Common Lisp: why popular languages swell in complexity
- Transfer
Adapted from the discussion in 2015 . Here, Common Lisp is just one of many good examples.
The future of JavaScript?
I have been working on the JavaScript Standards Committee (TC39) since 2007. We appreciate the simplicity of the language, but over time have lost vigilance. Complexity began to grow uncontrollably. We should find out why this happens naturally, what is the price 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 development path of JavaScript or any standard that has faced 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 much and rarely called beautiful. But they were also small, and it was very much appreciated. When the 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 is unlikely that anyone would have a sense of complete mastery of the language, since the details were actually devilishly complex. Nevertheless, the feeling of a "small language" in many ways determined the satisfaction of everyday use.
The aesthetics of JavaScript minimalism has been preserved in the EcmaScript-5 standard. I actively participated in the developmentEcmaScript-5 and EcmaScript-2015, and in both cases I am proud of my contribution. EcmaScript-2015 has grown significantly in size, but has brought improvements with it. Given where we started, it was impossible to improve JavaScript without such an increase in size. I do not regret most of the add-ons that led to inflate EcmaScript-5 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, this made sense, because we looked at EcmaScript-5 minimalism. When the language is small, each additional function is intuitively felt as a significant percentage increase in the size of the language. The specific benefits of a feature are always visible to its proponents. For a small language, the contribution of the new feature to the increase in total is also still visible to everyone.
As soon as the 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 master and reconcile with this. Once the language is perceived to be “infinite,” the specific benefits of the new feature are still understood. But the overall costs associated with additional complexity are no longer obvious. They are no longer felt by those discussing a new feature.
.
Even.
This is the death of a thousand cuts, which makes these monsters grow without any restrictions.
Therefore, I ask everyone who influences the language to consider a higher bar when considering a new function than “it’s good to have such an opportunity, isn’t it?”. I believe that EcmaScript-2015 is located on the border territory where rampant growth can still be prevented, but only if we begin to restrain each other with high standards for any proposed new feature. As a community, we need a more general sense of panic over the size that EcmaScript 2015 has already reached. Ideally, with the growth of the tongue, when the size approaches the point of no return, the panic should increase, not decrease.
Maintain minimal uneven pressure The
relevance of minimalism wanes as we move from the base language to libraries. The 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. All of this requires discipline. Only on the last point can we allow unlimited growth, but it is advisable that candidates be tested by the community and accepted first de facto. Ideally, the TC39 committee will cease to be a bottleneck, since the external processes de facto and de jure will be able to independently develop standard modules for convenience.
The future of JavaScript?
I have been working on the JavaScript Standards Committee (TC39) since 2007. We appreciate the simplicity of the language, but over time have lost vigilance. Complexity began to grow uncontrollably. We should find out why this happens naturally, what is the price 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 development path of JavaScript or any standard that has faced 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 much and rarely called beautiful. But they were also small, and it was very much appreciated. When the 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 is unlikely that anyone would have a sense of complete mastery of the language, since the details were actually devilishly complex. Nevertheless, the feeling of a "small language" in many ways determined the satisfaction of everyday use.
The aesthetics of JavaScript minimalism has been preserved in the EcmaScript-5 standard. I actively participated in the developmentEcmaScript-5 and EcmaScript-2015, and in both cases I am proud of my contribution. EcmaScript-2015 has grown significantly in size, but has brought improvements with it. Given where we started, it was impossible to improve JavaScript without such an increase in size. I do not regret most of the add-ons that led to inflate EcmaScript-5 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, this made sense, because we looked at EcmaScript-5 minimalism. When the language is small, each additional function is intuitively felt as a significant percentage increase in the size of the language. The specific benefits of a feature are always visible to its proponents. For a small language, the contribution of the new feature to the increase in total is also still visible to everyone.
As soon as the 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 master and reconcile with this. Once the language is perceived to be “infinite,” the specific benefits of the new feature are still understood. But the overall costs associated with additional complexity are no longer obvious. They are no longer felt by those discussing a new feature.
. Even
. This is the death of a thousand cuts, which makes these monsters grow without any restrictions.
Therefore, I ask everyone who influences the language to consider a higher bar when considering a new function than “it’s good to have such an opportunity, isn’t it?”. I believe that EcmaScript-2015 is located on the border territory where rampant growth can still be prevented, but only if we begin to restrain each other with high standards for any proposed new feature. As a community, we need a more general sense of panic over the size that EcmaScript 2015 has already reached. Ideally, with the growth of the tongue, 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 wanes as we move from the base language to libraries. The standard language as a whole can be represented as the following structure:
- Fundamental syntax : special forms that cannot be accurately expressed by local extension to another syntax.
- Semantic state : a state that is manipulated by computation.
- Kernel builtins: A part of the built-in library that provides functionality that custom code cannot provide on its own.
- Not built into the kernel modules (non-kernel intrinsics): built-in libraries, which can be implemented in JavaScript, but it depends on them semantic condition or modules built into the kernel. For example, through a proxy, you can implement an array in user code. But other modules built into the kernel already have a dependency on Array, which gives this particular array a privileged position over any proposed replacement.
- Syntactic sugar : syntax that can be expressed by local extension to the fundamental syntax.
- Global libraries for convenience : can be implemented with 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 standard.
I listed them in order, in accordance with my sense of increasing growth costs and the urgent need for minimalism. All of this requires discipline. Only on the last point can we allow unlimited growth, but it is advisable that candidates be tested by the community and accepted first de facto. Ideally, the TC39 committee will cease to be a bottleneck, since the external processes de facto and de jure will be able to independently develop standard modules for convenience.