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

James Long longster at
Thu Jun 18 18:22:07 UTC 2015

I've worked with sweet.js a lot, and someone pointed this email out to
me. I can't agree more. I love all the ES6 features, and some of ES7,
but looking at some of the future ES7 stuff (like decorators, etc)
makes me wonder what a "finished" JavaScript will look like. I'm not
bashing on decorators specifically, just that every new feature (like
classes) seems to require rethinking of so many other things (how do
we wrap class methods?) that we didn't have to do before.

I think Scheme and Lisp have had the most success as small languages,
particularly because of macros. Users weren't just stuck with a small
language, they could extend it when they really needed to.

I think JavaScript needs macros. It's the hardest language to change,
and yet one of the most used languages. Macros would let it thrive and
new features like await/async could be implemented by the community in
a matter of weeks. Babel has already pioneered an environment where
new ES7/8 features are available instantly to everybody, but the
problem is that you have to compile, and nothing is composable. I
can't release a new async library on npm that implements CSP channels
and provides a `go` form which is new syntax for firing off a
blockable process.

Clojure was able to release core.async, precisely the above channel
implementation, as a library that provides that new form. Immediately
people could start using it without having to update Clojure at all.

Of course, there's tons of technical problems here. sweet.js is cool
but you still have to compile, so macros need to be native. sweet.js
is also a bit slow at the moment. I don't know if it's possible for
hygienic macros to be fast enough (Tim Disney, creator of sweet.js,
would need to answer that). It may be possible to use sweet.js's
pattern matching mechanism but avoid hygiene altogether for speed (and
provide gensym capability).

I thing someone should take a serious a look at this, though. TC39
would certainly not have to hand-hold JS quite as much.

On Thu, Jun 18, 2015 at 10:37 AM, Mark S. Miller <erights at> wrote:
> 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.
> --
>     Cheers,
>     --MarkM
> _______________________________________________
> es-discuss mailing list
> es-discuss at

More information about the es-discuss mailing list