Is ES3 good enough? Was incrementally strengthening ES3 paradigms considered?
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.
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. Basically, what I'm saying is, I'm willing to give the Java-esque type system a chance.
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.
Macros have been proposed and discussed before - they're somewhere on the wiki. AFAIK, they've been deferred to a future ES5.
-Yuh-Ruey Chen
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
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:
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".
Could the Scheme aspect of ES be strengthened? Tail recursion and let statements seem like good additions. What about macros? Please!
I can speak to the topic of macros. The group has been open to the possibility of macros for a future version of ES, but not Edition 4. There are not very many languages with non-Lisp syntax that have come close to the power of Lisp/Scheme macros. CPP is distinctly not an inspiration! :) Dylan may provide some inspiration, and possibly Boo and Nemerle, though I have to learn more about these languages.
JavaScript's complicated syntax makes macros very tricky. Contrary to the popular view that parsing is a wholly solved problem in CS, moving Lisp-style macros out of the domain of S-expressions and into token-based syntaxes is far trickier than you might first suspect.
Hygiene is another important desideratum; scaling up C macros to be closer to the power of Lisp macros means dealing with the kinds of bugs that arise from name clashes[*]. Automatically hygienic systems generally "do the right thing" but there are a number of different algorithms to choose from, and as Brendan says the last word about hygiene has not been written (this is in fact the topic of my dissertation work). However, the theory doesn't have to be set in stone for the practice to proceed, and there are plenty of excellent, working Scheme implementations with fantastic macro systems that have been around for many years. There's lots of good inspiration to draw from.
So the short answer to your question is: maybe, but not yet. :)
Dave
[*] These problems don't arise in standard C, but with e.g. the GCC extensions to CPP you can easily cause these kinds of name capture.
Brendan Eich wrote:
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" atejohn.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).
- Completely abandoning ES3 in favor of another language(s). I'm definitely not in favor for this, but this has been a very common theme in comments since the release of that language overview. And this gets into the whole proprietary vs. open war, where ES*, rather than browser-unsupported Ruby or Python, is the best bet we have on keeping the (client-side) web open. It does suck though that this has to be one of the motivations behind the bigness of ES4. I'd prefer a much more incremental approach or even an incompatible language upgrade, but market realities call...
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. :-/).
Heh, with the super-multi-paradigm-ness of ES4, those programming cultures wars are bound to happen. Witness the creation of hundreds of "ES4/JS2 style" articles that all disagree with each other :)
I am glad to hear that the people behind ES4 are very cognizant of the "bigness" of the language. My hope is that a future ES5 will revamp the language into a smaller core syntax with much of the ES4 extensions (and some ES3) somehow morphed into syntactic sugar - or even better, user-defined syntactic sugar (could take bootstrapping to a whole new level).//
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.
Yeah, the proprietary vs. open language war again.
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.
Oops, didn't mean to say that the class system in the RI was buggy. I've tried some basic classes and it's working so far, but I haven't gotten knee-deep into it yet. It's just that the best way for me to learn all the ins and outs of a language, learning all its merits and whatnot, is to use for some sort of small experimental project. To give you an example, I didn't really appreciate all the little features Python had until I tried make a game mod with the language. Currently, the RI just doesn't seem stable enough for that.
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.
Oh come on :) I was referring to the syntax of the class system, which is undoubtedly Java-esque. Lot of Java haters in the functional (no 1st-class functions!) and scripting (too verbose!) programming crowd. Pretty much everyone's first impression of the class system in ES4 is that Java is being merged into the language. Kinda like how everyone thinks that Java inherited its type system from C++ instead of Modula-3.
-Yuh-Ruey Chen
[Dude, overciting kills electric trees -- cut more of my deathless
prose when replying, please! :-)]
On Nov 13, 2007, at 9:14 PM, Yuh-Ruey Chen wrote:
- Completely abandoning ES3 in favor of another language(s). I'm
definitely not in favor for this, but this has been a very common
theme in comments since the release of that language overview. And
this gets into the whole proprietary vs. open war, where ES*,
rather than browser-unsupported Ruby or Python, is the best bet we
have on keeping the (client-side) web open. It does suck though
that this has to be one of the motivations behind the bigness of
ES4. I'd prefer a much more incremental approach or even an
incompatible language upgrade, but market realities call...
There will be Ruby and Python support in a couple of years if I can
help it, but one point that enthusiasts for these languages, which
are indeed good languages, tend to forget: they were never web-tested
like only JS has been. Abstracting a sound security model from JS and
supporting it in other languages is a big job. It's best done in a
single VM hosting all the languages. Mean time, JS must be first and
fast, in browsers running on phones.
This does not augur well for a quick multi-language browser story,
but I think we'll get there.
Heh, with the super-multi-paradigm-ness of ES4, those programming
cultures wars are bound to happen. Witness the creation of hundreds
of "ES4/JS2 style" articles that all disagree with each other :)
We get that today with ES3 -- it's multi-paradigm by being functional
and prototypal already.
I am glad to hear that the people behind ES4 are very cognizant of
the "bigness" of the language. My hope is that a future ES5 will
revamp the language into a smaller core syntax with much of the ES4
extensions (and some ES3) somehow morphed into syntactic sugar - or
even better, user-defined syntactic sugar (could take bootstrapping
to a whole new level).
This is a goal of the macro follow-on work I mentioned earlier.
Oh come on :) I was referring to the syntax of the class system,
which is undoubtedly Java-esque. Lot of Java haters in the
functional (no 1st-class functions!) and scripting (too verbose!)
programming crowd. Pretty much everyone's first impression of the
class system in ES4 is that Java is being merged into the language.
Kinda like how everyone thinks that Java inherited its type system
from C++ instead of Modula-3.
Ok, fair enough -- class Foo extends Bar, ewww, Java. Someone on
today's TG1 call joked today "them's fighting words" when someone
else cited Java precedent. But really, I don't see any gain in using
gratuitously different syntax. If we had something more like Scala
traits, instead of interfaces, then we'd do better to use 'traits'.
But we've stuck with interfaces, the DOM uses them, native code on
many platforms uses them, and we're using them in the meta-objects.
At this point cue Alex Russell to argue for something I proposed
earlier, but didn't push hard enough: optional method bodies for
interfaces, for generic programming and default implementation code-
sharing.
On 2007-11-14, at 00:14 EST, Yuh-Ruey Chen wrote:
Oh come on :) I was referring to the syntax of the class system, which is undoubtedly Java-esque. Lot of Java haters in the functional (no 1st-class functions!) and scripting (too verbose!) programming crowd. Pretty much everyone's first impression of the class system in ES4 is that Java is being merged into the language. Kinda like how everyone thinks that Java inherited its type system from C++ instead of
Modula-3.
A key difference from Java is that types are optional. There is not
enough experience with es4 yet to know, but in other type-optional
languages I have worked with, I did not have a Java-esque feeling of
verbosity. Perhaps this is because I was coming from a dynamically-
typed background, so I did not have the reaction that given types I
had to declare them everywhere. Someone coming from a statically-
typed background might just continue their old habits and never
discover the freedom and power of leaving out unnecessary declarations.
In my experience with Dylan, it worked best to only specify types to
enforce contracts and to dispatch generic functions. In particular,
you almost never declared the types of local variables, the compiler
would work that out for you. Ideally, a type-inferencing compiler
should be able to warn you when the lack of a type declaration will
cause a run-time type check (safety warning) or run-time dispatch
(performance warning).
On 2007-11-14, at 00:35 EST, Brendan Eich wrote:
At this point cue Alex Russell to argue for something I proposed earlier, but didn't push hard enough: optional method bodies for interfaces, for generic programming and default implementation code- sharing.
Actually, I think that was me. The thread is titled "Interfaces
without implementation are like a day without sunshine". Eventually,
Dave Herman convinced me that what I wanted was properly called
mixin, not trait, and not interface. The OpenLaszlo Compiler/
Framework supports mixin as a 'power tool' -- we acknowledge that
they are dangerous if mis-used.
I've been reading the blogs and fuss over the the ES4 proposal. It seems to me that if ES3 was so horribly inadequate then big changes to the language would be welcomed unanimously. It must be that ES3 is sufficient to get by well enough that we have the luxury to argue about the worth of the proposed changes.
Was incremental change to the ES3 language ever considered at the beginning of the process for ES4? It seems there are many places where the ES3 language could be improved without changing it's character (ie adding classes). If ES was developed in a hurry then perhaps there was plenty of room to strengthen the paradigms it already contains. If work had continued on ES immediately after ES3 was released, isn't that what would have happened?
There are things that cannot be done with ES3 that could be added...
Could the Self aspect of ES be strengthened? For example, more control over prototypes and the prototype chain would make programming with that model of inheritance a stronger competitor to class-based inheritance. The read/write proto property could be standardized. Objects could have multiple prototypes like in Self. A obj.clone() function.
Could the Scheme aspect of ES be strengthened? Tail recursion and let statements seem like good additions. What about macros? Please!
Binary download for hiding code seems to be something people have been trying to achieve through obfuscation but cannot truly do with ES3.
Complete support for secure mash-ups seems essential and not just because Douglas Crockford says so. Developers want to mash-up and are doing it now even with the security risks to their unknowing users.
Adding types, classes and interfaces is drawing inspiration from languages with other models of programming. The new look of ES4 is very Java-like. Are the screams from the Java programmers enough to control the future of ES? Adding these constructs seems like an attempt to try to please everyone. This is the classic anti-pattern in marketing.
There is an argument that the changes in ES4 are needed for the open web to keep up with rich platforms like Flash and Silverlight. As far as snazzy, sparkley user interfaces go, the ES3 language isn't the problem here but rather it is HTML, the DOM and CSS. Even if Internet Explorer and all browsers suddenly implemented these other standards correctly an HTML/JavaScript/CSS page wouldn't be very impressive compared with a Flash animation. I gulped last weekend when I saw a friend's flash portfolio with sound, video and vector graphics and then thought about my rectangular tabbed panes and drop down menus. I won't be able to do any of the Flash-like stuff with ES4. This paragraph isn't intended as an argument against changing ES but I don't think change to ES should be justified by the "keeping up" argument.
Has ES3 proven itself to be such a disaster that trying to improve it incrementally while retaining its character is obviously the wrong choice? Was ES founded on such poor choices (Self and Scheme) that we should be moving to completely different style of programming (Java)?
I wouldn't be writing this email had others not spoken up. It seems somewhat inappropriate and rude to speak against what Brendan Eich is proposing since it is his language.
Peter