[TLUG]: ECMAScript ("Javascript") Version 4 - FALSE ALARM

Mon Oct 29 13:36:13 PDT 2007

I think the MAIN problem is not technical, but rather political:

When I went to the Ajax Expereince,  several people commented that
1) There was a 'deal' between Adobe and Mozilla
2) There was not consensus on the new features, but they are being pushed
through anyway

Can Abobe or Mozilla make a public statement to address these?

Can anyone else comment HOW either party would benfit if this did happen?

also can you comment on why there was more than AS3 added to the new
language?

Thank you!

On 10/29/2007, "Thomas Reilly" <treilly at adobe.com> wrote:

>
>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: es4-discuss-bounces at mozilla.org
>[mailto:es4-discuss-bounces at mozilla.org] On Behalf Of Mark Miller
>Sent: Sunday, October 28, 2007 1:36 PM
>To: Dave Herman
>Cc: es4-discuss at mozilla.org
>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
>Es4-discuss at mozilla.org
>https://mail.mozilla.org/listinfo/es4-discuss
>_______________________________________________
>Es4-discuss mailing list
>Es4-discuss at mozilla.org
>https://mail.mozilla.org/listinfo/es4-discuss