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
