I'm confused about the design constraints on ES4
brendan at mozilla.org
Sun Nov 11 12:14:33 PST 2007
On Nov 11, 2007, at 10:44 AM, Mark Miller wrote:
> 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.
That would be great.
> It is one thing to sigh with despair at other people's tendencies to
> add features to languages over time.
(People tend to do that with all languages, but why despair? It's
either inevitable or good. I'm assuming the philosophy of despair is
something we both try to avoid.)
> 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?
There's not going to be an ES15, and eighty years is way over the
event horizon. The problems JS users face now won't be solved that
slowly in the language. Instead, at the margins at first and
increasing non-linearly, some new runtime (probably only one) will
eat away at all of the open standards implemented in browsers --
unless those standards can evolve quickly.
This is a real threat. Right now major web sites are being paid tons
of money to retool using Silverlight, while others are being paid to
develop Adobe AIR applications. I'm not saying one bad word about the
merits of those closed-standard runtimes, except that they are simply
not open by the same definition as browsers based on web standards
that co-evolve with the browsers are. Even when those other runtimes
embrace and extend web standards, the whole result is proprietary,
With ES4 and other "post Firefox" web standards (the WHAT-WG Web Apps
1 and Web Forms 2 work, which is supposedly feeding into the re-
chartered W3C HTML Working Group), a combination of browser vendors
(minority market share, the game theory explains everything here --
there's no secret alternate-runtime agenda) and web developers (who
have been traditionally *unrepresented* in pay-to-play standards
consortia) have tried to evolve open web standards quickly.
This "open standards common" approach is not easy, and it doesn't
follow the traditional model for language design. At best it involves
a high-quality peer group folding the results of experiments into the
emerging standard, factoring to ensure compositionality and a smaller
core than syntax indicates. And these efforts tend to be rolling
standards parties -- nothing is pushed to de-jure status prematurely.
Again, not ideal for interop, but much better than stagnation.
This model for evolving the web is new since 2004, but something like
it was already happening behind the scenes, without being formalized,
when XMLHttpRequest was implemented in other browsers in the early
2000s. There, an informal peer group (most of the people knew their
peers at other browser vendors via standards work) was following the
lead of Microsoft (which gave Java the boot and then had to add XHR
for Outlook's webmail!), but the general principles of incremental,
backward-compatible change prefigured the more explicit goals and
variants, including Mozilla's and Macromedia's dialects, which fed
forward into Ecma TG1.
You can call this process a bad thing because it's far removed from
what I'll call the Steele/Sussman or Niklaus Wirth language design
model. I don't care to moralize about it at this critical point in
web evolution. I think it's at worst the lesser evil, and it is in
any event inevitable for any of us among the minority-share browser
vendors, and the Ajax web developers who stick to the browser
runtime, who together are trying to make progress without commanding
dominant market power that includes OS auto-updated distribution
What I've written here seems far removed from language design
principles. It is close to a description of fitness characteristics
and survival threats in the web ecosystem. The principles and harsh
realities have to meet somehow. Speaking for myself (since you
addressed me; I'm not sole or lead ES4 designer), I don't see a
better way to proceed than shared effort in groups such as the Ecma
TG1 group, the WHAT-WG, etc.
> 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
First, I don't dismiss "mood" arguments, I object to them being
substituted as evidence for categorically distinct claims about
compatibility and other technical properties. Those "break the web"
claims need to be substantiated or withdrawn.
Second, my point about compatibility being fuzzy is not a subjective
argument. It could be quantified, at great expense, and pretty much
only in hindsight. The plain fact, and Firefox and Safari rising in
market share are proof of this, is that web compatibility does not
mean emulating the last (monopoly or near-monopoly) implementation
bug-for-bug. It never has, not when Netscape took over from Mosaic,
not when IE took over Netscape's market share.
> 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
drawn to Scheme when Netscape recruited me in early 1995, but there
was less than zero time to use it, and anyway, it was and remains a
teaching and research language. People using it industry have to
procure or write a lot of code to make it usable, and interoperation
is not great (as with C) because the reports intentionally
underspecify. At least with JS we specified more for interop. But I
over-minimized the original design, and ES2 and 3 were growth-
restricted. The result has been a big complexity tax on users of the
language, especially those trying to build robust libraries.
The situation with Scheme today seems relevant to ES4/JS2 in another
respect. R6RS has grown from R5, a lot, and it has sometimes
overspecified capriciously, as Will Clinger and others have pointed
out. This has led to an ERR5RS counter-action. From 100,000 feet, you
might compare what's going on to ES4 vs. "ES3.1" or whatever it might
be called. Closer up, the comparison breaks down badly in my opinion.
Notwithstanding all the differences that prevent easy comparisons, I
think it's fair to say that those of us in TG1 working on ES4 take
the traditional first paragraph of the Scheme reports to heart:
"Programming languages should be designed not by piling feature on
top of feature, but by removing the weaknesses and restrictions that
make additional features appear necessary. Scheme demonstrates that a
very small number of rules for forming expressions, with no
restrictions on how they are composed, suffice to form a practical
and efficient programming language that is flexible enough to support
most of the major programming paradigms in use today."
Compositional, orthogonal features really do mean (if the language
designers got it right) that you don't have to think about order N^2
or N! special case combinations as N grows. ES4 is not being monkey-
patched or otherwise hacked simplistically or carelessly on top of
ES3. I note that kind of language-hacking, when it happens in
standards bodies, is more a hazard of growing by too-small increments
forced through a standards process that dumbs down the technical
thinking and stamps the standard before the dominant vendors have
implemented it fully (this happened with ES3; less so with ES2).
> 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
The desugarings I'm thinking of are documented in the wiki (e.g.
destructuring assignment), not so much in the overview. I agree they
should be documented so as to separate the core language -- we're
just getting to spec-writing now, but this is something we'll work
on. The core is still a significantly bigger language than ES3 by a
good bit, however. This is intentional and we had better get it right
before it becomes a standard.
>> 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
Yeah, we are hip to this. It's a crucial point. We haven't led with
it, but it's evident in some of the voluminous materials on the wiki.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Es4-discuss