I'm confused about the design constraints on ES4

[Brendan Eich]

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,  
single-vendor.

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  
methods of the WHAT-WG. Similar work happened with JavaScript  
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  
channels.

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
> grounds.

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
> language.

People invoke Scheme when talking about JavaScript. I was originally  
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
> understood.

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
> core.

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.

/be

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.mozilla.org/pipermail/es-discuss/attachments/20071111/cda4641f/attachment-0002.html