I'm confused about the design constraints on ES4

Mark Miller erights at gmail.com
Sun Nov 11 10:44:00 PST 2007

Hi Brendan,

There are many individual aspects of the the ES4 proposal that I like,
many things I don't. All of which I hope to enumerate for this list
over time. But overall my main distress is still the size of the

At http://weblogs.mozillazine.org/roadmap/archives/2007/11/es4_news_and_opinion.html
you state:

# [...] the proposed ECMAScript 4th edition (ES4) grammar is a bit
more than twice
# as big as ES3's, counting several ways [...]
# This is not out of line given the eight years since ES3, which came less than
# three years after ES1.

It is one thing to sigh with despair at other people's tendencies to
add features to languages over time. It is another to see this as a
virtue. Perhaps EcmaScript 15, eighty years from now, will be 10 times
as large as ES4. I would agree that this may happen, as it seems to be
happening to Java. But should we look forward to this as a good thing?

Please don't dismiss such "mood of the language" issues. The "fuzzy"
points you made in your previous reply to me were quite valuable, even
though they are at least as non-objectively "mood of the
language"-like as many of the arguments you've dismissed on these
grounds. Language size has a real cost. The "brainprint" you refer to,
at least for my brain, goes up more than linearly in the size of

Fortunately, later in that same paragraph, you say:

# And we're being generous with syntactic conveniences,
# which desugar to a smaller core language.

>From my perspective, this may be very good news! Is this smaller core
language documented anywhere? E, Scheme, Mozart/Oz, and many languages
I like are organized as small core/kernel language + syntactic sugar.
Bottom-up learners like myself can more easily understand such
languages by first absorbing the core language, and then understanding
the rest in terms of their expansion to the constructs they've already

>From a security perspective, a small core/kernel language is
especially important. Secure computing is best understood as a
multi-player game. In order to plan one's moves, one must understand
not only what one is able to do, one must also understand the limits
on what the other players are able to do. Such arguments, whether
formal or informal, are effectively inductions over all the operations
available to the other players. Fortunately, with the core + sugar
approach, such arguments only need to enumerate the elements of the

Text by me above is hereby placed in the public domain


More information about the Es4-discuss mailing list