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

Mark S. Miller erights at
Thu Jun 18 14:37:03 UTC 2015

On Wed, Jun 17, 2015 at 7:27 PM, Kyle Simpson <getify at> 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list