[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: > 3) 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. /be _______________________________________________ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
