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