Cedric at OpenDomain.Org
Mon Oct 29 15:09:32 PDT 2007
If I was not clear before, I would like to thank you for the
This does not mean I agree with everything being put in, but that may be
more a commnet on my understanding rather than anything about the
lanaguage. However, Doug did strike a chord when he said "the ghost of
Thanks again for your patience
On 10/29/2007, "Thomas Reilly" <treilly at adobe.com> wrote:
>I think I can safely make the "public statement" that if Adobe could
>warp space time we would have added more to AS3. As it was we needed to
>ship something and we shipped the best language/implementation we could
>at the time. Since then we've been working hard to make all our
>technologies better as evidenced by our ongoing participation in TG1 and
>contributions to Tamarin.
>What would Adobe and Mozilla possibly have to make a "deal" concerning?
>Its probably the case that the head decision makers of Mozilla and the
>head decision makers at Adobe have never met each other, much less made
>From: es4-discuss-bounces at mozilla.org
>[mailto:es4-discuss-bounces at mozilla.org] On Behalf Of Ric Johnson
>Sent: Monday, October 29, 2007 1:36 PM
>To: Thomas Reilly; Mark Miller; Dave Herman
>Cc: es4-discuss at mozilla.org
>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
>also can you comment on why there was more than AS3 added to the new
>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
>>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
>>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
>>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
>>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
>>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
>>Language cohesiveness and implementation feasibility are equally
>>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...
>>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
>>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
>>> [...] Brendan Eich
>>> has repeatedly explained why a multiplicity of languages on the web
>>> infeasible, e.g. at the URL Jeff Dyer linked to
>>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
>>> 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"
>>> 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
>>Es4-discuss mailing list
>>Es4-discuss at mozilla.org
>>Es4-discuss mailing list
>>Es4-discuss at mozilla.org
>Es4-discuss mailing list
>Es4-discuss at mozilla.org
>Es4-discuss mailing list
>Es4-discuss at mozilla.org
More information about the Es4-discuss