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

[Robert Sayre-2]

On 10/28/07, Mark Miller <erights@...> wrote:
>
> However, Rebecca is related to the evil Allan of Microsoft, so perhaps
> responsibility based design is part of some evil corporate plot? Or
> maybe we should evaluate the logic of what people are saying
> independent of their corporate affiliation?

This reads like a flame to me. I think every message I've sent has
suggested, you know, pointing out technical flaws when you criticize a
proposal. In response, there have been

 * several messages conflating ES4 with various ungainly languages
  (no technical content)

 * claims that the committee couldn't possibly have come up with a
good proposal
  (no technical content)

 * claims that (optional) static typing and (optional) classes somehow
    represent some kind of "switch"
   (no technical content, some religious content)

 * claims that people (not me, I'm not on the committee) are acting
irresponsibly
   (no technical content)

 * self-righteous grandstanding about the true nature of JavaScript
   (no technical content)

 * claims that everyone should implement before standardizing
   (already done).

 * Temper tantrums about the name.
   (there's really nothing to negotiate, aiui)

This is not a discussion. It is trash talk. And it looks like its aim
is to delay the work of others. Clear?

I understand that you want to explore more restrictive subsets, and
maybe some conservative extensions. That's great. I think you should
call it whatever you want, and it could work very well. Does ES4
redefine your subset? Doesn't seem so, except in a few corner cases
that are undeniable bugs in ES3. None of the scary new features are
involved. Why is this a problem?

--

Robert Sayre

"I would have written a shorter letter, but I did not have the time."
_______________________________________________
Es4-discuss mailing list
Es4-discuss@...
https://mail.mozilla.org/listinfo/es4-discuss

[liorean]

On 29/10/2007, Robert Sayre <sayrer@...> wrote:
>  * Temper tantrums about the name.
>    (there's really nothing to negotiate, aiui)

I can understand wanting to change the name for the reason Steve Yegge
mentions in "How to Ignore Marketing and Become Irrelevant in Two Easy
Steps" - Both JavaScript and ECMAScript are horrible names. On the
other hand they have a considerable mindshare and I think it would be
more confusing if the name was changed to something entirely unknown.

I don't buy the argument that ES4 shouldn't be named "ECMAScript 4" or
"JavaScript 2" because it's too big a a change to it's predecessor
however. ES4 has been developed specifically to be an update to
ECMAScript 3/JavaScript 1.x. As long as ES4 doesn't throw away
considerable parts of ES3 (which it doesn't) then I can't see how that
point is valid. The size of the "new" language compared to the size of
"old" language isn't important, what's important is the fact it's
pretty much entirely additional features that were lacking in the
predecessor or added orthogonal mechanisms that makes things possible
in the engine that were not possible before.
--
David "liorean" Andersson
_______________________________________________
Es4-discuss mailing list
Es4-discuss@...
https://mail.mozilla.org/listinfo/es4-discuss

[Mark Miller-2]

On 10/28/07, Mark Miller <erights@...> wrote:
> .fromJSONString() is inappropriate as a method of String.

Oops. I meant .parseJSON().



On 10/28/07, Robert Sayre <sayrer@...> wrote:

> On 10/28/07, Mark Miller <erights@...> wrote:
> >
> > However, Rebecca is related to the evil Allan of Microsoft, so perhaps
> > responsibility based design is part of some evil corporate plot? Or
> > maybe we should evaluate the logic of what people are saying
> > independent of their corporate affiliation?
>
> This reads like a flame to me. I think every message I've sent has
> suggested, you know, pointing out technical flaws when you criticize a
> proposal. [..]

Fair enough. So long as others discuss technical issues and do not
impugn the motives of others, I will do likewise. But there's one
issue which leaves me puzzled:

> * Temper tantrums about the name.
>   (there's really nothing to negotiate, aiui)

I don't understand your point. Both positions:
* advocating that the name stay the same
* advocating that the name be changed
cannot be resolved by technical arguments. The issue isn't technical.
When you say "there's really nothing to negotiate", I'm not sure what
you mean. Are you suggesting that we avoid deciding the name for the
new language, and confine ourselves instead to deciding only its
technical content? In any case, I agree that we can at least postpone
these non-technical issues for now.


> I understand that you want to explore more restrictive subsets, and
> maybe some conservative extensions. That's great. I think you should
> call it whatever you want, and it could work very well. Does ES4
> redefine your subset? Doesn't seem so, except in a few corner cases
> that are undeniable bugs in ES3. None of the scary new features are
> involved. Why is this a problem?

Regarding Caja, it might be no problem at all. I don't know yet. I
have now read the section of the overview document titled
"Compatibility" and every embedded bold "Note:". Congratulations.
Seriously. So far, I have spotted one thing which surprised me, but
nothing Caja can't live with and several things that are helpful. If
this text really does represent all the compatibility gotchas when
switching from ES3 to the proposed language whose name is not
negotiable, then the introduction of this language will not disrupt
Caja. It looks like the Caja translator can easily continue to
restrict Caja programs to an enforced subset of ES3, or close enough.

As time permits, over the next week, I will read the remainder of the
document carefully and let you know if I spot any other technical
issues that might be problematic for Caja.

--
Text by me above is hereby placed in the public domain

    Cheers,
    --MarkM
_______________________________________________
Es4-discuss mailing list
Es4-discuss@...
https://mail.mozilla.org/listinfo/es4-discuss

[Robert Sayre-2]

On 10/28/07, Mark Miller <erights@...> wrote:

>
> > * Temper tantrums about the name.
> >   (there's really nothing to negotiate, aiui)
>
> I don't understand your point. Both positions:
> * advocating that the name stay the same
> * advocating that the name be changed
> cannot be resolved by technical arguments. The issue isn't technical.
> When you say "there's really nothing to negotiate", I'm not sure what
> you mean. Are you suggesting that we avoid deciding the name for the
> new language, and confine ourselves instead to deciding only its
> technical content?

Yes, but it's also not a good way to participate in any standards
group. Here's the web page:

http://www.ecma-international.org/memento/TC39-TG1.htm

Bullet points #1 and #2 pretty clearly state that the product is
ECMAScript. I'm not an expert on the ECMA process, but I don't think
some dissent concerning new features should require revisiting the
name of the standard produced. Check out the attendees and minutes for
July 27, *2006* on this page:

http://wiki.ecmascript.org/doku.php?id=meetings:meetings

And let's be clear, this example works in ES4:

~/Desktop/es4> ./es4
>> function X() { this.foo = "bar"}
>> X.prototype = {"baz":"qux"}
[object Object]
>> function Y() { this.bop = "wibble" }
>> Y.prototype = new X()
[object Object]
>> var z = new Y()
>> z.bop
wibble
>> z.foo
bar
>> z.baz
qux

No static typing, no classes. The ES4 additions are closer to Bigloo
Scheme or something like that [1,2]. There if you need them, harmless
if you don't.

> In any case, I agree that we can at least postpone
> these non-technical issues for now.

Yep, works for me.

1.) http://pauillac.inria.fr/cdrom/www/bigloo/manual/bigloo-15.html
2.) http://pauillac.inria.fr/cdrom/www/bigloo/manual/bigloo-7.html#container1654

--

Robert Sayre

"I would have written a shorter letter, but I did not have the time."
_______________________________________________
Es4-discuss mailing list
Es4-discuss@...
https://mail.mozilla.org/listinfo/es4-discuss

[Andrew Dupont-2]

On Oct 28, 2007, at 9:01 PM, liorean wrote:

> On the other hand they have a considerable mindshare and I think it  
> would be
> more confusing if the name was changed to something entirely unknown.

I agree with all this. The comparison to C/C++ is fitting — both C++  
and ES4 add a giant glob of features onto an existing language. In C+
+'s case, the name conveys this succinctly, attaching to the C "brand"  
while also suggesting an evolution of some sort.

Those who think that incrementing the version number doesn't convey  
the extent of ECMAScript's evolution have a valid point. But — to  
liorean's point — both "JavaScript" and "ECMAScript" are horrible  
names that we're stuck with. There's no name, in my opinion, that  
would sufficiently detach itself from said awfulness without detaching  
from the brand (and thus the mindshare) an equal amount. I think  
"Smashing Pumpkins" is an awful name for a band, but they'd be mad to  
change it now.

Cheers,
Andrew
_______________________________________________
Es4-discuss mailing list
Es4-discuss@...
https://mail.mozilla.org/listinfo/es4-discuss

[Ric Johnson]

Im sorry to post this here, after being a lurker for so long, but I just
had to respond.

I put my comment on my blog:
http://openajax.com/blog/2007/10/29/god-bless-scoble/

This is not SPAM: I do not use any Advertising or profit.  This is only
to promote the OpenWeb and I wanted to make it public.

Please feel free to respond

Ric johnson

On 10/29/2007, "Andrew Dupont" <andrew@...> wrote:

>On Oct 28, 2007, at 7:36 PM, Robert Sayre wrote:
>
>> On 10/28/07, Douglas Crockford <douglas@...> wrote:
>>>
>>> As responsible stewards of the language, we should...
>>
>> ...discuss technical issues. I encourage you to begin doing so.
>
>I can see this escalating very quickly, so let me try to get ahead of
>it:
>
>Douglas, would you be satisfied if only the name were changed and
>nothing else? Or is the underlying issue the perceived scope creep and
>personality change from ES3 to ES4? Robert (and others) have responded
>as though it were the former. But it feels like the latter; if so
>let's frame it that way.
>
>Cheers,
>Andrew
>
>
>>
>>
>> --
>>
>> Robert Sayre
>>
>> "I would have written a shorter letter, but I did not have the time."
>> _______________________________________________
>> Es4-discuss mailing list
>> Es4-discuss@...
>> https://mail.mozilla.org/listinfo/es4-discuss
>
>_______________________________________________
>Es4-discuss mailing list
>Es4-discuss@...
>https://mail.mozilla.org/listinfo/es4-discuss

_______________________________________________
Es4-discuss mailing list
Es4-discuss@...
https://mail.mozilla.org/listinfo/es4-discuss

[Garrett]

On 10/28/07, Douglas Crockford <douglas@...> wrote:
> Robert Sayre wrote:
> > Fighting over the name is pointless. It's not a good name, and web
> > developers call it "JavaScript".
>
> The name is exactly the point. A new language should have a new name. The deltas
> from ES3 to the proposed language are larger than ES3 itself. Claims of backward
> compatibility do not change the fact that there is more than enough new material
> in the proposal to make it a new language.
>
Well, depends how "language" is defined. I could communicate verbally
at a young age, but have since learned many new words and English
constructs.

Are you saying that ES4 is not backwards compatible?

> But at this point in time I would resist standardizing the new language simply
> because we do not have enough practical experience with it to know if it is good
> enough to be worth standardizing. I can think of one instance in history when a
> standards committee produced a good, new design, and that was a long time ago.
> The current proposal is no Algol 60. It's not even an Algol 68.
>
> ES3, aka JavaScript, aka JScript, aka ECMAScript is a small language with a lot
> of, as you say, not good names. I am in favor of making careful and modest
> improvements to the language, correcting as much as possible the problems that
> are most troublesome to actual usage.
>
> As responsible stewards of the language, we should not be trying to transform
> ECMAScript into something else. I don't care what you call your new strongly
> typed classical language, as long as you don't call it JavaScript or ECMAScript.

The new feature "toJSONString" does change the language, in a bad way.
It means that every object is serializable.

This is bad because it means that I, as a developer, have the
obligation to provide proper serialization for every ADT I create.
Obligation. Not option. That sucks.

Regarding the "responsible steward" part, you've got a good point. I'm
sure who "we" are (probably does not include me, right?)

The tests Brendan provided provide clear evidence of the poor
performance of such techniques. How come you never mention any of
this, Doug? Well, it's obvious that you make a career out of leading
what, sheep? Sheeple?

I have been on three projects that have followed your advice, Doug. In
fact, I mentioned this to you when I met you. Since then you've
completely ignored every email I've sent to you.

I have analyzed code that followed your advice, too. f(m) and dojo
used to use the power constructor for everything. Dojo no longer does
this.

In fact, at my last project at Yahoo, the people (people, not sheep) I
worked with would get confused by your module pattern and would think
that it was a namespace or part of the namespace. Of course, this was
also compounded by the  advice provided Steve Sauders.

I remember the 1100-1200 line file. All in one file, correctly
following Steve Sauder's advice, and neatly encapsulated in your
Module pattern, correctly following your advice. These were
responsible, hard working people, and I am still friends with one of
them.

I think my boss told me to "change as little as possible" and "don't
break anything." Deja vu.

It took quite a long time to convince these guys to break stuff up
into multiple files. We ended up with 25-30 files/page. Convincing
them not to use the memory-intensive module pattern was more
difficult. They had just grown accustomed to it, let there by you.

This file count is fairly common for RIA development, it's
accommodated by a build.

Oh yeah, speaking of the build process, you mentioned in your seminar
about removing assertions from the production code. Remember? You said
you wanted to make a build script to remove assertions. You do
remember this, don't you?

Anyone who puts assertion code in their code should not be doing a build in the
first place. Assertions don't belong in the code.

Testing is done in a completely separate layer. If you'd done any
real-world application development, you'd not only know that fact,
you'd know how it worked and how it affected development.

Anyone who even considers buildng such system is too out of touch with
real world development to be considered a responsible shepherd.

I sent you such comments before in personal email, while at Yahoo, but
since I never get a reply (from any mail I send you, ever); how can I
know you actually read it? Well, now I know you read the list :-)

Now we can go back and forth with "too much change", "it should be
renamed", et c. But until you can provide facts to state why ES4 will
break the web, you have absolutely 0 credibility.

In preparing evidence for your claims, you will need to provide tests
and real-world evidence. I can bring my friend from the project I was
on and he still has the code, I think.

In preparing your tests,you might consider http://www.jsunit.net/ and
http://www.openqa.org/selenium/

Kent Beck and Robert Martin have sume useful books. They're not about
javascript, but software, process, testing. Great stuff.

Regards,

Garrett

> _______________________________________________
> Es4-discuss mailing list
> Es4-discuss@...
> https://mail.mozilla.org/listinfo/es4-discuss
>


--
Programming is a collaborative art.
_______________________________________________
Es4-discuss mailing list
Es4-discuss@...
https://mail.mozilla.org/listinfo/es4-discuss

[Brendan Eich-2]

On Oct 28, 2007, at 7:53 PM, Mark Miller wrote:

> I have now read the section of the overview document titled
> "Compatibility" and every embedded bold "Note:". Congratulations.
> Seriously.

Thanks. There are likely to be even fewer compatibility notes soon  
(see http://bugs.ecmascript.org/ticket/250 and http://
bugs.ecmascript.org/ticket/251).

/be

_______________________________________________
Es4-discuss mailing list
Es4-discuss@...
https://mail.mozilla.org/listinfo/es4-discuss

[wycats]

I was at that presentation. It was effectively a debate between John Resig, who works for Mozilla, and Douglas Crockford, the "concerned" ECMA member mentioned. Bottom line is that Doug wants to have it both ways. He wants everyone to participate and discuss the language changes, but he rails on the majority of the committee for releasing information on what is going on internally. The release of the white paper was extremely helpful in getting the word out about the arcane internals of the working group. Had the paper not been released, his "go talk about the spec and raise your concerns" suggestion would not have been possible. /me shrugs -- Yehuda Katz <quote author="Scott Elcomb"> Hi all, First off, I'd like to say thanks for all the good questions and answers from folks on the list. I haven't been here long, but have already learned a bunch. Looking forward to ES4. Anyway, I received this post* this morning in response to a notice I sent along about the ES4 overview. I'm not sure what to make of the story... Any comments or clarifications? * http://article.gmane.org/gmane.org.user-groups.linux.tolug/36420 ---------- Forwarded message ---------- From: Walter Dnes <waltdnes@...> Date: Oct 27, 2007 3:44 AM Subject: Re: [TLUG]: ECMAScript ("Javascript") Version 4 - FALSE ALARM To: tlug@... On Mon, Oct 22, 2007 at 04:04:52PM -0400, Scott Elcomb wrote > An official overview[1] of "Javascript 2.0" was released today. > It will likely be some months (at least) for this version of the > language to show up in web browsers, but it might be a good idea to > get on-board early. Not so fast. See the note on Slashdot Firehose at http://slashdot.org/firehose.pl?op=view&id=350409 Since it's not too long, I'll quote it in its entirety... > "At The Ajax Experience conference, it was announced that an > ECMAScript4 white paper had been released. The implication being > that the white paper was the upcoming spec, which is untrue. Not to > mention this is not an official ECMA site, but a site run by only > some of the members from the ECMAScript4 group. These facts were > later revealed by another concerned ECMAScript4 member. He encouraged > any interested parties to read the proposed feature white paper, join > the discussion mailing list on that site, and share your opinions > for (or against) the desired features. This seems a little `cloak > and dagger` of those running the site, who desire serious changes > and are unfortunately Mozilla, Adobe, and others. The concerned > individual suggested that they simply create a new language with a > new name, as there are that many fundamental differences. Many of > us are very concerned that the language we love is being rewritten > under our feet." -- Walter Dnes <waltdnes@...> In linux /sbin/init is Job #1 Q. Mr. Ghandi, what do you think of Microsoft security? A. I think it would be a good idea. -- The Toronto Linux Users Group. Meetings: http://gtalug.org/ TLUG requests: Linux topics, No HTML, wrap text below 80 columns How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists -- Scott Elcomb http://www.psema4.com/ _______________________________________________ Es4-discuss mailing list Es4-discuss@... https://mail.mozilla.org/listinfo/es4-discuss </quote>

_______________________________________________
Es4-discuss mailing list
Es4-discuss@...
https://mail.mozilla.org/listinfo/es4-discuss

[Thomas Reilly]

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

[Ric Johnson]

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

_______________________________________________
Es4-discuss mailing list
Es4-discuss@...
https://mail.mozilla.org/listinfo/es4-discuss

[Brendan Eich-2]

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@...> 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@...

[es4-discuss-bounces@...] On Behalf Of Mark Miller

Sent: Sunday, October 28, 2007 1:36 PM

To: Dave Herman

Cc: es4-discuss@...

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@...

https://mail.mozilla.org/listinfo/es4-discuss

_______________________________________________

Es4-discuss mailing list

Es4-discuss@...

https://mail.mozilla.org/listinfo/es4-discuss

_______________________________________________

Es4-discuss mailing list

Es4-discuss@...

https://mail.mozilla.org/listinfo/es4-discuss

_______________________________________________
Es4-discuss mailing list
Es4-discuss@...
https://mail.mozilla.org/listinfo/es4-discuss

[Brendan Eich-2]

On Oct 29, 2007, at 2:05 PM, Brendan Eich wrote:

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.

As did other members of TG1, including Mozilla, of course. I hasten to add this, lest the open-spec conspiracy theory be enlarged to say Adobe, Mozilla, and Opera are trying to advance some hidden agenda.

/be

_______________________________________________
Es4-discuss mailing list
Es4-discuss@...
https://mail.mozilla.org/listinfo/es4-discuss

[Thomas Reilly]

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
a "deal".  

-----Original Message-----
From: es4-discuss-bounces@...
[mailto:es4-discuss-bounces@...] On Behalf Of Ric Johnson
Sent: Monday, October 29, 2007 1:36 PM
To: Thomas Reilly; Mark Miller; Dave Herman
Cc: es4-discuss@...
Subject: RE: [TLUG]: ECMAScript ("Javascript") Version 4 - FALSE ALARM

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

_______________________________________________
Es4-discuss mailing list
Es4-discuss@...
https://mail.mozilla.org/listinfo/es4-discuss
_______________________________________________
Es4-discuss mailing list
Es4-discuss@...
https://mail.mozilla.org/listinfo/es4-discuss

[Ric Johnson]

>Who, besides Doug Crockford, would be among those "several
people"?
I believe some Dojo people were against the new ES4, and I did here two
people sitting next to me reflect that (sorry I do not know who they
were)

>I could not attend that conference (new baby in hospital still).

Congrats.

>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.

Um... I am not accusing you or anyone. This is what was said at the TAE,
but not by me

>
>> 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

I did read it.  However, I do beleive Doug's quote was "half of the of
the working group did NOT agree, but it is being pushed through
anyway".  I wrote this down word for word at the time, but may have
attributed incorrectly.

>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.

I never said you were dumb- quite the opposite, but I fail to see how
rejecting the question gets us anywhere.

>> 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)?

I have reviewed quite a few docs, although I may have missed more.  I
like ES4 and thank you for your hard work.  However, my question still
stands.

>> 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.
>
>
>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.

Upon review, I SHOULD become more informed before sticking my foot in it.
 Sorry.

>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.

You are correct sir:  I do respect Doug and thus lent weight to the
argument, but I also respect John Resig, who was at the conference. The
differing opinions is why we are having these discussions.

Thank you for taking the time to address these postings
_______________________________________________
Es4-discuss mailing list
Es4-discuss@...
https://mail.mozilla.org/listinfo/es4-discuss

[Neil Mix]

> 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
> a "deal".

I'll play devil's advocate for a moment, and say "Tamarin".  It goes  
like this: someone claims Adobe and Mozilla are in cahoots, and that  
triggers the memory that Adobe open-sourced its AS engine to Mozilla,  
and then the wheels start turning.  It's a lazy thought process, of  
course, because what's really gained?  Did they team up to make sure  
the spec results in as little modification to Tamarin as possible?  
So they're teaming up out of laziness?  I don't get it either, but  
you asked.

_______________________________________________
Es4-discuss mailing list
Es4-discuss@...
https://mail.mozilla.org/listinfo/es4-discuss

[Ric Johnson]

If I was not clear before, I would like to thank you for the
contribution.  I love javascript and look forward to the future.

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
Netscape"

Thanks again for your patience

On 10/29/2007, "Thomas Reilly" <treilly@...> 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
>a "deal".
>
>-----Original Message-----
>From: es4-discuss-bounces@...
>[mailto:es4-discuss-bounces@...] On Behalf Of Ric Johnson
>Sent: Monday, October 29, 2007 1:36 PM
>To: Thomas Reilly; Mark Miller; Dave Herman
>Cc: es4-discuss@...
>Subject: RE: [TLUG]: ECMAScript ("Javascript") Version 4 - FALSE ALARM
>
>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@...> 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@...
>>[mailto:es4-discuss-bounces@...] On Behalf Of Mark Miller
>>Sent: Sunday, October 28, 2007 1:36 PM
>>To: Dave Herman
>>Cc: es4-discuss@...
>>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@...
>>https://mail.mozilla.org/listinfo/es4-discuss
>>_______________________________________________
>>Es4-discuss mailing list
>>Es4-discuss@...
>>https://mail.mozilla.org/listinfo/es4-discuss
>_______________________________________________
>Es4-discuss mailing list
>Es4-discuss@...
>https://mail.mozilla.org/listinfo/es4-discuss
>_______________________________________________
>Es4-discuss mailing list
>Es4-discuss@...
>https://mail.mozilla.org/listinfo/es4-discuss

_______________________________________________
Es4-discuss mailing list
Es4-discuss@...
https://mail.mozilla.org/listinfo/es4-discuss

[wycats]

On 10/29/07, Ric Johnson <Cedric@...> wrote:

>Who, besides Doug Crockford, would be among those "several
people"?
I believe some Dojo people were against the new ES4, and I did here two
people sitting next to me reflect that (sorry I do not know who they
were)

I spoke to a bunch of Dojo guys, and while they have concern about specific implementation details, I did not get the sense at all that they were against the direction of ES4.

>I could not attend that conference (new baby in hospital still).

Congrats.

>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.

Um... I am not accusing you or anyone. This is what was said at the TAE,
but not by me

It's what Crockford said at TAE, and his comments, while incredibly well parsed to avoid outright lying, were incredibly misleading. 

>
>> 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

I did read it.  However, I do beleive Doug's quote was "half of the of
the working group did NOT agree, but it is being pushed through
anyway".  I wrote this down word for word at the time, but may have
attributed incorrectly.

Right. He avoided lying. However, he did say that Microsoft and Yahoo! were against, while Mozilla and Adobe were for, giving the strong impression of a split committee. 

>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.

I never said you were dumb- quite the opposite, but I fail to see how
rejecting the question gets us anywhere.

Buying into opposition frames is a great way to get trampled. I'm pretty new to this whole conversation, but accepting the basic frame that Doug outlined is just playing directly into the FUD. 

>> 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)?

I have reviewed quite a few docs, although I may have missed more.  I
like ES4 and thank you for your hard work.  However, my question still
stands.

I commented on this in a previous thread. Forward-looking browser-vendors have everything to gain by pushing the state of the art. Crockford himself, at TAE, said that failure to innovate in the browser space will kill the open web in favor of proprietary solutions like AIR.

>> 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.
>
>
>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.

Upon review, I SHOULD become more informed before sticking my foot in it.
Sorry.

>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.

You are correct sir:  I do respect Doug and thus lent weight to the
argument, but I also respect John Resig, who was at the conference. The
differing opinions is why we are having these discussions.

Thank you for taking the time to address these postings
_______________________________________________
Es4-discuss mailing list
Es4-discuss@...
https://mail.mozilla.org/listinfo/es4-discuss

-- 
Yehuda Katz
Web Developer | Procore Technologies
(ph)  718.877.1325
_______________________________________________
Es4-discuss mailing list
Es4-discuss@...
https://mail.mozilla.org/listinfo/es4-discuss

[wycats]

Some parts of this message have been removed. Learn more about Nabble's security policy.

---------- Forwarded message ----------
From: Yehuda Katz <wycats@...>
Date: Oct 29, 2007 1:52 PM
Subject: Re: [TLUG]: ECMAScript ("Javascript") Version 4 - FALSE ALARM
To: Ric Johnson <Cedric@...>

On 10/29/07, Ric Johnson <Cedric@...> wrote:

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

 

I actually don't know anything about the internal politics, but the names Adobe, Mozilla, and Opera are on the white-paper, and Microsoft/Crockford are actively against. Seems as though a majority of the WG is in favor of the changes, and MS/Crockford are using their opposition to spread FUD about a "deal".   

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

I would love to hear a public statement ;) 

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

 

The forward-looking browser vendors want to advance the state of the art. At TAE, Crockford said that it we don't fundamentally change the tools we have to work with, the open web will lose. This is fundamentally in conflict with his position on ES4, which is that diverging from the status quo will cause "pain" and break the web. 

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

_______________________________________________
Es4-discuss mailing list
Es4-discuss@...
https://mail.mozilla.org/listinfo/es4-discuss

--
Yehuda Katz
Web Developer | Procore Technologies
(ph)  718.877.1325

--
Yehuda Katz
Web Developer | Procore Technologies
(ph)  718.877.1325
_______________________________________________
Es4-discuss mailing list
Es4-discuss@...
https://mail.mozilla.org/listinfo/es4-discuss

[Alex Russell]

On Monday 29 October 2007 3:05 pm, Ric Johnson wrote:
> >Who, besides Doug Crockford, would be among those "several
>
> people"?
> I believe some Dojo people were against the new ES4, and I did here
> two people sitting next to me reflect that (sorry I do not know who
> they were)

Just to be *very* clear, the Dojo community is not monolithic. Opinions
of ES4 inside Dojo span the entire gamut, from fully in favor to
dead-set against. Dojo, as a project, has no official stance.

Regards

--
Alex Russell
alex@...     A99F 8785 F491 D5FD 04D7 ACD9 4158 FFDF 2894 6876
alex@... BE03 E88D EABB 2116 CC49 8259 CF78 E242 59C3 9723


_______________________________________________
Es4-discuss mailing list
Es4-discuss@...
https://mail.mozilla.org/listinfo/es4-discuss