The Tragedy of the Common Lisp, or, Why Large Languages Explode (was: revive let blocks)

On Wed, Jun 17, 2015 at 7:27 PM, Kyle Simpson <getify at gmail.com> wrote: > I'd like to ask if there's anyone on TC39 that would be willing to > champion a proposal to add the let-block (let-statement) syntax? > I am not. Further, if anyone were, I would work to kill it. Here's why. The Algol, Smalltalk, Pascal, and early Scheme languages were prized for being small and beautiful. The early C and JavaScript languages were justifiably criticized for many things, and rarely mistaken for a language that was generally beautiful. But they were small, and this aspect was properly and widely appreciated. When a language is small, our appreciation of it is often driven by the sense "I can learn the whole thing, and then I will have a mastery of it", and later "I know the whole thing. I love the fact that there are no corners I don't know." For C and JavaScript, few who thought they knew the whole thing actually did -- the details were actually fiendishly complex. Nevertheless, this sense drove much of the satisfaction with everyday usage. The esthetic of smallness of JS lasted through ES5. I participated heavily in both ES5 and ES6 and in both cases I am proud of my contributions. ES6 is much larger, but nevertheless it is a much better language. Given where we started, we could not have achieved these gains in the utility of JS without such an increase in size. I do not regret most of the additions that grew ES5 to ES6. For many of these, had we the ES6 standards process to do over again, I would likely make similar additions. But each of the additions that grew ES5 into ES6 had to pass a very high bar. Psychologically, this made sense to all of us because we were starting from a language, ES5, whose smallness we could still appreciate. When a language is small, every additional feature is viscerally felt as a significant percentage increase in the size of the language. The specific benefits of a feature are always visible to its advocates. But for a small language, a new feature's general costs in added complexity are also still visible to everyone. Once a language gets beyond a certain complexity --- say LaTeX, Common Lisp, C++, PL/1, modern Java --- the experience of programming in it is more like carving out a subset of features for one's personal use out of what seems like an infinite sea of features, most of which we become resigned to never learning. Once a language feels infinite, the specific benefits of a new feature are still apparent. But the general costs in added complexity are no longer apparent. They are no longer *felt* by those discussing the new feature. Infinity + 1 === Infinity. Even aLargeNumber + 1 === approximatelyAsLargeANumber. This is the death of a thousand cuts that causes these monstrosities to grow without bound. So please, I beg all of you, when considering a new feature, please apply a higher bar than "Wouldn't it be nice if we could also write it this way?". I believe that ES6 is in that middle territory where unrestrained growth is not yet inevitable, but only if we all restrain each other with high standards for any proposed new feature. As a community, we need more of a shared sense of panic about the size that ES6 has already grown to. Ideally, that panic should increase, not decrease, with further growth from here as our size approaches the point of no return. -- Cheers, --MarkM -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150618/71e2a4eb/attachment.html>