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

[Brendan Eich]

On Oct 29, 2007, at 1:36 PM, Ric Johnson wrote:

> I think the MAIN problem is not technical, but rather political:
>
> When I went to the Ajax Expereince,  several people

Who, besides Doug Crockford, would be among those "several people"?

> commented that
> 1) There was a 'deal' between Adobe and Mozilla

I could not attend that conference (new baby in hospital still). Too  
bad, because if I had, you would have heard another side to the  
story, and a vigorous debate, and then probably we wouldn't be  
playing this "how long have you been beating your wife?" game. Which  
I refuse to play.

> 2) There was not consensus on the new features, but they are being  
> pushed
> through anyway

Did you read my message in response to the slashdot anonymous  
coverage of that TAE panel, sent to this list? Here's a link:

https://mail.mozilla.org/pipermail/es4-discuss/2007-October/001309.html

The history is that for over seven years in total, over two years  
consecutively, Ecma TC39-TG1 has been working on 4th edition drafts.  
Only this year did a minority of TG1 dissent. The majority,  
consisting of Adobe, Mozilla, Opera, MbedThis, and invited experts  
from academia, has continued its work. In previous years to 2007,  
Microsoft was apparently, albeit passively, involved in work on the  
4th Edition, and did indeed implement and ship JScript.NET based on a  
draft spec (with changes for the .NET CLR).

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

This is a public list, will it do?

You may not have heard the story about a politician who was accused  
of being mentally dim. He called a press conference to deny the  
allegation, which did not help. I'm not that dumb, so I'm going to  
reject your question and ask you to justify its premise. If we don't  
share premises, there's no point arguing conclusions.

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

Can you stop assuming your conclusion (Adobe/Mozilla conspiracy) for  
a minute and examine its premise (which can be addressed by looking  
at public materials on exactly who created ES4 as proposed in TG1)?

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

The rationales are summarized in the white paper (http:// 
www.ecmascript.org/es4/spec/overview.pdf). Detailed rationales were  
originally given in the proposals namespace of http:// 
wiki.ecmascript.org/. If you are curious about the detailed history  
of the design evolution, please read these proposal pages, and their  
linked discussion pages. We put these in the open so anyone can check  
our reasoning and see that there's no hidden agenda for ES4.

Here's a good example of what I mean: let binding forms (http:// 
wiki.ecmascript.org/doku.php?id=proposals:block_expressions). The  
summary rationale is mercifully short: it fits on one line and  
accords with decades of computer science and engineering. "The  
rationale for the proposal is that tighter scope discipline for all  
variables is Good." Since we are bound by backward compatibility,  
'var' remains in addition to 'let'.

Another example: destructuring assignment (http://wiki.ecmascript.org/ 
doku.php?id=proposals:destructuring_assignment), which superseded my  
earlier group assignment (http://wiki.ecmascript.org/doku.php? 
id=proposals:group_assignment) proposal. Destructuring (for array  
patterns) was already designed and implemented by Opera.  
Destructuring is a convenience, syntactic sugar, not present in AS3  
but now shipped in JS1.7 in Firefox 2.

These are two of several features not in AS3, but AS3 is hardly the  
ne plus ultra of JavaScript. So again I think your question is skewed  
toward Adobe. Opera contributed ideas and solutions based on its  
experience.

Frankly, I think you are approaching the claims that I've seen  
attributed to Doug Crockford at The Ajax Experience a bit  
credulously. Since I was not there to give the other side, or at  
least one other side, let's back up from taking Doug's claims as  
gospel truth and putting other groups on trial based on one person's  
statements.

/be

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.mozilla.org/pipermail/es-discuss/attachments/20071029/b8e23419/attachment-0002.html