Is ES3 good enough? Was incrementally strengthening ES3 paradigms considered?

[Brendan Eich]

On Nov 12, 2007, at 1:56 PM, YR Chen wrote:

> Personally, I'm still mixed on the introduction of the whole  
> nominal type system with classes and whatnot. I'm very sympathetic  
> to views that ES4 should concentrate on ES3's weak points. At  
> times, I feel that ES3 is just too "alien" a base to build the  
> "programming in the large" features that ES4 advocates on to. Like  
> fitting a square peg into a circle.

I think this is a valid criticism of ES3, not ES4. ES3 had "native"  
and "host" objects right there in the spec and real browser  
embeddings. These objects were clearly instances of nominal types, in  
the case of the DOM with interfaces, even -- single-inherited classes  
with interfaces for method-suite mixins.

That these built-in object types were alien to the core language, and  
hard to deal with, was obvious. That users would want to emulate,  
wrap, and extend such types did not seem as well-motivated in 1998 as  
it does now.

Now, Ajax apps and libraries routinely wrap, etc., and try to blur  
the lines. This succeeds only to the extent that a bad actor doesn't  
attack the mutable bindings in prototypes and the global object, and  
the good JS programmers don't (have to) worry too much about the  
costs of closures for this-binding, name hiding, etc. But there are  
real limits to JS1's scaling in several dimensions. See the "Side  
Discussion" at

http://ejohn.org/blog/native-json-support-is-required/

and note that the requirement is to produce a DOM (not some tree of  
JS objects to be walked in order to generate a DOM). I've heard this  
from many Ajax devs: XML, XSLT (yuck, but it works pretty well in  
browsers), and HTML with its DOM beat pure JS approaches that then  
must generate a DOM, at scale. And the DOM is nominally typed.

Two ways forward:

* Change the native and DOM bindings to look more like prototypal JS,  
or ES4 with structural types only, or something like that -- but  
that's a whole new DOM binding and even DOM interface formalism, and  
the DOM ships sailed many times already. This task would involve  
rolling big stones up many browser-war hills, at the same time.

* Add enough support to ES3 to self-host, which is more or less what  
ES4's nominal types do, plus interfaces for the DOM and many similar  
"host" object systems already hooked up to ES3 engines. Self-hosting  
much of the DOM is possible (and may even perform better, besides  
being memory-safe compared to a C++ DOM implementation).

Given the programming-in-the-large and integrity goals, the second  
path looks much more attractive, not to mention realistic. It  
supports self-hosting and so levels the playing field between "native/ 
host" and "hosted" (written-in-ES) abstractions, which has further  
good effects in the ecosystem. It provides tools for scaling and  
hardening those abstractions that need to scale and become hard  
across larger populations, higher method call rates (but this is a  
non-goal in my book, more later), and accidents or intentional attacks.

Yes, this path leads to a bigger language than the first path. But  
nothing will avoid growth, and too little growth can compromise both  
the language's integrity and leave too big a complexity tax on its  
users.

Having written this, I will say that the general objection to ES4 as  
too big, I find deeply "true" in many ways, and the most serious  
challenge to those of us working on ES4.

Yet the web is big. There's a lot in the real world that is too big.  
My emphasis on nothing being lost from the ES3 core is not meant to  
excuse bigness, only to observe that (unlike in other parts of  
virtual and real worlds, where bigness is imposed and smallness is  
lost, through exclusive offerings and even coercion), we are not  
"breaking the web".

Still, I'm strongly sympathetic to those who are "defending the  
Shire" (if you get my reference) by objecting to ES4's bigness. And  
there's a real risk that ES4, even though backward compatible, will  
be twisted via bad programming "culture wars" that in effect stamp  
out the old ways. Should it come to this, I'll be on the other side  
of those wars, with the Hobbits and Doug Crockford (if they'll have  
me. :-/).

But I don't think the old ways suffice. I've seen too many users  
waste hours and days struggling to enforce latent types with ad-hoc  
checks, or no checks at all. I've seen lots of security exploits that  
take advantage of mutability and extensibility at the heart of JS1.  
And I hope we all can see the onslaught of alternative but near-the- 
web (typically browser plugin at first, but then embrace, extend,  
extinguish soon follow) runtimes that boast bigger, stronger, and  
more scaleable (in practice) programming languages.

Against these, JS1 or a small "cleanup" of it cannot compete, not  
only in my opinion, but in the successful marketing judgments of  
several mighty companies (including Microsoft and Yahoo!). And to be  
fair to those big companies, many (most?) programmers do deserve  
better programming-in-the-large and integrity support, including an  
expressive type system with optional static checking. If they have to  
switch to C# or ActionScript to get it, many programmers will. JSLint  
is not enough.

> Nonetheless, I see that languages based on the old ES4 draft  
> (2002?) that have been successful, namely ActionScript. I'm not  
> very familiar with it, but the overall feeling I get from ppl  
> developing in AS is positive. I also want to get my hands dirty  
> testing out classes in ES4, but sadly the RI is too buggy at the  
> moment.

Please mail me about these RI bugs, or file them yourself at http:// 
bugs.ecmascript.org/ -- I have access to the monotone repository, and  
I see classes and interfaces doing more right than wrong, but we need  
to see your testcases. Thanks.

> Basically, what I'm saying is, I'm willing to give the Java-esque  
> type system a chance.

Java-esque is not fair, even if you are talking only about the  
nominal types. Unbounded type parameters are not classically "Java- 
esque", and Java generics go beyond what we are doing in some ways  
(variance annotations) while still being much less (erased, static  
only) in others. ES4 is a dynamic language. Java-esque doesn't begin  
to do it justice.

> With that said, some of your ideas are interesting, such as  
> multiple prototypes. I imagine, however, that that would slightly  
> less efficient, and more importantly, result in similar problems to  
> multiple inheritance (think diamond inheritance issues). I would  
> like to know how Self handled that issue.

Self supported multiple prototypes. Since Self came up, I thought I'd  
point out Cecil, Craig Chambers' Self-with-optional-types-and-generic- 
methods sequel. It has been an inspiration to ES4 at least for me:

http://www.cs.washington.edu/research/projects/cecil/pubs/cecil- 
spec.html

> Macros have been proposed and discussed before - they're somewhere  
> on the wiki. AFAIK, they've been deferred to a future ES5.

Researchers on the list may be willing to speak to macros with more  
authority than I have. I'll just say that apart from the fun with C- 
like syntax (which can be handled; we're close to specifying standard  
ASTs for ES4), sound hygiene theory is still a research topic. I  
expect good results from academia in a year or so, and hope that TG1  
will take advantage of them.

In the mean time, I think it would be very wrong to defer syntactic  
conveniences until after macros are done. With macros, conveniences  
that de-sugar in ES4 could be re-specified (and implemented at the  
same time) cheaply, for sure -- but users deserve convenient syntax  
sooner than "after macros".

/be