There's seems to be enough sanity in this thread for me to dare to participate, good job everyone for avoiding going over the edge ;-)
I just wanted to point out that a sizable subset of ES4 has receieved substantial usage via the Flash platform (what we call ActionScript3 and Flex 2). This subset includes classes, interfaces, namespaces, packages, optional type checking, and getters and setters. Its important to note that AS3 is missing a non-trivial # of ES4 features but I think its fair to say it passes for a half way point between what browsers support today and ES4 (if not closer to ES4). I'm not sure how you measure language success but its very clear that AS3/Flex2 has been successful in taking ActionScript to higher level of "programming in the large" based on our customers successes. The overwhelming majority of developers prefer AS3 over AS1/2. Sure it was only released into the market 16 months ago but Flash moves fast and over %90 of the world has the AS3 runtime and hundreds of thousands of developers have our various SDKs (I think that says something, although it certainly doesn't prove anything). There was years of hard work, false starts and customer research leading up to that release of course. I think the biggest colloquial point to make is that developers used to static type checking could move comfortably to AS3 whereas before the language was too loose/dynamic. To make the point bluntly, Java developers hit the ground running with Flex. Will ES4 be as successful and will AS3 continue to be successful? Who knows, there's more at play than language features. We can say that real world feedback on AS3 has influenced what Adobe has pushed for in ES4 (parameterized types and multi-methods probably top the list). To look at JavaScript and ES4 side by side is probably a bit daunting but perhaps with AS3 in the middle it looks a little more sane. I would categorize ES4's evolution as diligent and glacial almost to a fault and think that with ActionScript3 and a working RI the spec and language will be adequately battle tested to keep it from being a failure. Of course we hope and believe it'll be much more. For better or worse, Flash's distribution alone may be a bigger factor than the existance or non-existance of any particular language feature (of course I can't say when our platform will support ES4) but the proof's in pudding which in this case, I think, is what people put in their HTML. That said a lot of the ES4 features are new to me and I'd love to hear concrete examples about how these features may not work well together in practice (as opposed to unsupported claims that this might be the case). Language cohesiveness and implementation feasibility are equally relevant. One concern I have is that compilers will be slow for ES4, I realize compilation speed has been a factor in ES4's development (evidenced by the word "optional") but in practice I think a lot of folks will want those optional features. I don't think ES4 compilers can't be fast but it takes time for compilers and their runtimes to mature and real time compilation is important for the web. I guess its a matter of having skilled resources on the problem, on one end of the pendulum javac seemed to take forever to get fast (remember jikes?) but the mono guys seemed to make short work of making mcs fast. Adobe's friends (http://www.mtasc.org/) have helped us in this area before, the skills are out there. I believe the skills/resources/motivation of the engineers has more to do with it than the language design but I can't back that belief up. Cheers and thanks for joining the party... Tommy -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark Miller Sent: Sunday, October 28, 2007 1:36 PM To: Dave Herman Cc: [email protected] Subject: Re: [TLUG]: ECMAScript ("Javascript") Version 4 - FALSE ALARM Thank you all for your feedback. Yes, I understand that my "bad smell" comment may have been less than helpful, though it hardly compares to some of the ad hominem comments in some of the responses. I will spend time reading the new overview paper; and I will post further feedback as I go. In exchange, I suggest that everyone here read Tony Hoare's Turing award lecture: <http://www.sli-institute.ac.uk/~bob/hoare.pdf>. In the meantime, I should explain what I'm reacting to. The first paragraph of the abstract of this new overview paper lists the following features [with connective text removed]: # classes, interfaces, namespaces, packages, program units, optional type annotations, # optional static type checking and verification, structural types, duck typing, type definitions, # multimethods, parameterized types, getters and setters, meta-level methods, proper tail # calls, iterators, generators, type meta-objects, stack marks. Each of these may individually be good ideas. But languages can die of too many good ideas. Personally, I have my doubts about several of these (multimethods, duck typing, proper tail calls). Several of the others are hard to get right enough to do more harm than good, and few have (parameterized types, meta-level methods, iterators, generators, type meta-objects). The problem is the combination. Language features are rarely as orthogonal as one might hope. The interaction of even a small subset of the features listed above can take decades of many failed attempts to work out well. But even if you have succeeded at integrating together more good ideas into a coherent language design than have many previous brilliant language designers, I have another concern: Standards bodies should not do de-novo design. And they especially should not foist a design as a standard before there's a substantial track record of usage. How many large systems have already been written in this proposed ES4 design? E is a much smaller language than ES3, but it has evolved substantially in ways that surprised me, based on actual experience trying to use the language. > [...] Brendan Eich > has repeatedly explained why a multiplicity of languages on the web is > infeasible, e.g. at the URL Jeff Dyer linked to > (http://lambda-the-ultimate.org/node/2504). Are you referring to the post at <http://lambda-the-ultimate.org/node/2504#comment-37607>? I'll wait for a response before responding further to this point. > So obstructing the progress > of JS and consequently the open web in the name of preserving the > purity of a "platonic ideal" of JavaScript strikes me as either a > mistake of philosophical extremism, a convenient cover for conflicted > business interests, or a combination of both. I have now learned ES3 itself quite well. I would not describe it as a platonic ideal of anything. I think ES3 is already too large, and it has many broken features (with, this-capture, pervasive mutability, lack of encapsulation, silent errors, for/in loop dangers, ...). The question we are discussing is which direction constitutes progress. Your response assumes your conclusion. Language vendors and standards committees, constrained by upwards compatibility, can only grow their language. Once a language gets too large, the best that we can hope for is that they grow it slowly, incrementally, and conservatively. Java 1.5 came after Java 1.4, and it adds many features to Java 1.4. All the additional features added are each individually arguably good ideas, and recapitulate some of the elements of ES4's list. Does this imply that Java 1.5 represents progress over Java 1.4? In this case, I am quite familiar with the language both before and after. The process by which 1.5 evolved from 1.4 was much more experience driven and much more incremental than what I see here. Nevertheless, IMO, Java 1.5 is a substantially worse language that Java 1.4. The "convenient cover for conflicted business interests" comment is the sort of ad hominem nonsense that I hope we can avoid in further discussions. I have known both Doug Crockford and Allan Wirfs-Brock for years before they joined Yahoo and Microsoft respectively. The suggestion that either would act with less than integrity in order to serve their corporate interests, I find ludicrous and offensive. > Finally, just to reiterate that the "it's a different language" charge > glosses a critical aspect of the ES4 proposal, namely backwards > compatibility. ES4 is not a new language. It is, as the overview > describes, a significant evolution of ES3. C++ is approximately backwards compatible with C. With a small number of changes, it could have been precisely backwards compatible. Should we consider C++ to be merely a significant evolution of C? The additions that C++ makes to C are larger than the C language itself. >From the list from the ES4 abstract I quote above, I fear this may be true of ES4 vs ES3. -- Text by me above is hereby placed in the public domain Cheers, --MarkM _______________________________________________ Es4-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es4-discuss _______________________________________________ Es4-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es4-discuss
