Fwd: [TLUG]: ECMAScript ("Javascript") Version 4 - FALSE ALARM
On 10/27/07, Scott Elcomb <psema4 at gmail.com> wrote:
---------- Forwarded message ---------- From: Walter Dnes <waltdnes at waltdnes.org> On Mon, Oct 22, 2007 at 04:04:52PM -0400, Scott Elcomb wrote Not so fast. See the note on Slashdot Firehose at slashdot.org/firehose.pl?op=view&id=350409 Since it's not too long, I'll quote it in its entirety...
"[...] This seems a little
cloak and daggerof 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."
I was not at the Ajax Experience conference, but I just spent the last week at OOPSLA. Everyone at OOPSLA I ran into who knows about the ES4 proposal hates it. The general sense is that they think it's a train wreck. But there's a feeling of resignation: Yet another runaway standards process to oppress us. The people expressing this opinion include some extremely good programming language folks with great track records and reputations.
I have only skimmed the proposed ES4 spec, so I can't yet venture an informed opinion. However, as a language designer myself, my initial sense of smell corroborates the consensus I saw at OOPSLA.
I did raise with people the notion that the new larger language be given a different name. One reason that C managed to stay small is that all those who wanted to grow it self-selected to grow C++ instead. Likewise, the existence of Common Lisp probably helped protect the smallness of Scheme. Everyone I mentioned this to thought this name change would be a good idea, and would help protect the continued evolution of the language we now call Javascript, i.e., EcmaScript 262 Edition 3. Whatever its flaws or virtues might be, the ES4 proposal is simply a very different language. Please let's be honest about that and change its name.
I've responded briefly to the slashdot posting. Bottom line is that the majority of the participants are working in the open to finish a set of language proposals that largely originated in 1999 at Netscape. It is not new and there should be few surprises to those, including Microsoft, who have participated in TG1 since then.
Opposing members from two companies have made general claims along the lines that "it is too different to be called the same language" and "it will destabilize the web". Both arguments have been refuted in detail, in private and public (e.g. lambda-the-ultimate.org/node/2504). And we have yet to hear similarly detailed or convincing response from those 'minimalists'. That could be because their motives have more to do with specific business concerns, rather than broad technical concerns. I guess we won't know until they come out and say it.
On 10/27/07, Mark Miller <erights at gmail.com> wrote:
I was not at the Ajax Experience conference, but I just spent the last week at OOPSLA. Everyone at OOPSLA I ran into who knows about the ES4 proposal hates it. The general sense is that they think it's a train wreck. But there's a feeling of resignation: Yet another runaway standards process to oppress us.
I have only skimmed the proposed ES4 spec, so I can't yet venture an informed opinion. However, as a language designer myself, my initial sense of smell corroborates the consensus I saw at OOPSLA.
Hi Mark,
I'm afraid your message falls into a pattern I've been seeing lately: unsubstantiated, non-technical criticism. In other words, FUD.
If you have technical criticism to contribute, it is of course welcome.
On 10/27/07 10:17 AM, Mark Miller wrote:
On 10/27/07, Scott Elcomb <psema4 at gmail.com> wrote:
---------- Forwarded message ---------- From: Walter Dnes <waltdnes at waltdnes.org> On Mon, Oct 22, 2007 at 04:04:52PM -0400, Scott Elcomb wrote Not so fast. See the note on Slashdot Firehose at slashdot.org/firehose.pl?op=view&id=350409 Since it's not too long, I'll quote it in its entirety...
"[...] This seems a little
cloak and daggerof 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."I was not at the Ajax Experience conference, but I just spent the last week at OOPSLA. Everyone at OOPSLA I ran into who knows about the ES4 proposal hates it. The general sense is that they think it's a train wreck. But there's a feeling of resignation: Yet another runaway standards process to oppress us. The people expressing this opinion include some extremely good programming language folks with great track records and reputations.
I have only skimmed the proposed ES4 spec, so I can't yet venture an informed opinion. However, as a language designer myself, my initial sense of smell corroborates the consensus I saw at OOPSLA.
I did raise with people the notion that the new larger language be given a different name. One reason that C managed to stay small is that all those who wanted to grow it self-selected to grow C++ instead. Likewise, the existence of Common Lisp probably helped protect the smallness of Scheme. Everyone I mentioned this to thought this name change would be a good idea, and would help protect the continued evolution of the language we now call Javascript, i.e., EcmaScript 262 Edition 3. Whatever its flaws or virtues might be, the ES4 proposal is simply a very different language. Please let's be honest about that and change its name.
Mark,
Thanks for this news from the street. Although, I'm not sure what it means that "everyone...hates" ES4. Can you be more specific?
And, I'd be curious to know what evidence is given that the standard's process is "running away". There are detailed notes of the working group meetings since late 2005 when work on ES4 was restarted. They are posted at:
Brendan an others have clearly articulated the need for the language to evolve. And yet all we hear in response are the hollow generalizations such as are above. People's track records and reputations don't mean much if they are unnamed and uninformed.
In the hallway in an OOPSLA in late 90's the inventor of Self made the remark to me [paraphrased, of course], "I don't know much about JavaScript, but I haven't heard many good things about it". I have spoken with that same person recently and he said "JavaScript is a pretty interesting language...I be interested in working on it." The point is that knowledge and experience changes perspective.
Do you really believe that ES4 is a train wreck? I'd like to hear back from you after you have a chance to do some homework.
On Oct 27, 2007, at 8:00 AM, Scott Elcomb wrote:
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.
Thanks. Here's hoping ES4 as proposed is not quashed by the
combination of anonymous propaganda campaigns and truly-secret
maneuverings within the standards body by the pay-to-play members
(Mozilla is not one; we don't have that access).
What follows below are my opinions, presented bluntly as ever. This
is long, but evidently necessary and appropriate to es4-discuss. I'll
blog about the situation soon too.
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?
A link to a slashdot anonymous posting? What's to clarify? :-/
As much as possible, those of us in Ecma TG1 actually working
productively on ES4 for over two consecutive years have made our work
and intentions known by means of this list, the ecmascript.org
site, the SML reference implementation, and blog posts and public
talks I've given.
In opposition, only Doug Crockford has spoken his mind forthrightly
in the last several months. Good for him (I'll argue with his version
of the reality elsewhere), but shame on the biggest company involved,
which has not contributed at all in the open, instead leaving people
with wrong impressions about its commitment to ES4.
Many people don't know where Microsoft stands, knowing only that it
contributed over the years to draft ES4 proposals, implemented a
variant of one such draft specification in JScript.NET, and had one
of its employees (Rok Yu) contributing to TG1 work, with his name on
E4X (ECMA-357) as well as ES3 and the 2003 interim ES4 draft report.
Indeed, up until early this year, the rest of us in TG1 had no clear
statement of dissent from Microsoft. So, who is not dealing
forthrightly or openly here?
To be more fair than the opponents of ES4-as-proposed have been, I'll
add this obvious reassurance: any organization or person can change
position. Indeed one Microsoft rep confided to me that "we were
asleep!" about what was going on with Microsoft passively
participating in TG1 before this year. So let's say there was no
duplicity, no playing along with the rest of TG1's long-standing
work, only to reverse suddenly late in the process.
Nevertheless, standards do not require unanimity, and even Microsoft
loses sometimes. That's life.
Cc'ing Walt Dnes.
---------- Forwarded message ---------- From: Walter Dnes <waltdnes at waltdnes.org> Date: Oct 27, 2007 3:44 AM Subject: Re: [TLUG]: ECMAScript ("Javascript") Version 4 - FALSE ALARM To: tlug at ss.org
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 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.
That untrue implication comes from the anonymous coward, not from any
of us involved in TG1 who have worked in the open on ES4. From the
white paper's introduction:
This overview reflects the position of the majority in Ecma TC39-TG1.
A minority in TG1 do not agree that the language presented here
should become ES4. However, Ecma and ISO do not require unanimity to
make standards, and no alternative proposal has been submitted to
TG1. Therefore the language described in this overview continues to
be proposed as ES4.
No one reading this overview could confuse it for a specification.
From the front page of the overview, the first footnote:
This document reflects the understanding of the language as of
October 2007. TG1 is no longer accepting proposals and has started
writing the language specification. The ES4 reference implementation
is undergoing stabilization and is already passing large parts of its
test suite, and this document describes the final language in most
respects. That said, TG1 maintains a bug tracking system at http://
bugs.ecmascript.org/, and ES4 is subject to further refinement as
known and new bugs in the design are resolved
Not to mention this is not an official ECMA site, but a site run by only some of the members from the ECMAScript4 group.
With permission from Ecma staff.
These facts
The insinuation that someone was passing a self-described overview
off as a spec is not a "fact", it's a lie from the anonymous
miscreant. The same goes for the claim about ecmascript.org
being passed off as an "official ECMA site" -- that site would be
www.ecma-international.org. The ecmascript.org site
was clearly announced, to this list and elsewhere, as a tool for
making draft specs, the reference implementation, and trac tickets
available to everyone, in order to get feedback to Ecma TC39-TG1.
were later revealed by another concerned ECMAScript4 member.
Who was that concerned member, pray tell?
Another bogus tactic: play the underdog, oppressed into anonymity by
the majority in some formerly-consensus-based group. Yeah, right!
Microsoft is never the underdog. (I'm assuming that member was not
Doug Crockford.)
Anonymous, easily falsified assertions do not help persuade anyone.
They are obvious signs of political intrigue instigated by the
anonymous party, in preference to joining in open discussion and debate.
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.
As we have encouraged people for a long time. It's not as if http:// ecmascript.org/ was a secret, ever. It was announced on http://lambda- the-ultimate.org/ and my blog at weblogs.mozillazine.org roadmap/, and elsewhere.
This seems a little
cloak and daggerof those running the site,
I hope it's clear to everyone that the shoe is on the other foot.
This is a classic inflammatory propaganda technique: anonymous
parties accuse the group that has acted openly of the very traits the
dissenters and their allies are demonstrating. It's a nervy move:
pretend against all evidence that open work on ES4 was somehow
deceptive or secretive, and pose as heroes shining light instead of
heat.
This propaganda technique is meant to inflame all parties and
distract from the substantive question, which is this:
Should ES4 grow to address real problems in ES3, and thereby subsume
(in the case of ActionScript 3) or compete with (Microsoft's
favored .NET languages) the proprietary languages some vendors now
opposing it are selling (Microsoft) or using (Yahoo!)? Or should ES4
be a small and mostly formal (deprecation, not actual
incompatibility) set of changes to ES3?
who desire serious changes and are unfortunately Mozilla, Adobe, and others.
Big-company snobbery shows here: "others" would be Opera, MbedThis,
and invited experts from academia and the Ajax community (sponsored
by me, as it happens) on TG1, but I guess Opera doesn't count -- only
big companies deserve mention.
The "unfortunately" above is telling. It's "unfortunate" that
organizations other than the dominant browser vendor (you know, the
one convicted of abusing its monopoly and forced back into the web
standard bodies only by renewed browser competition) have tried to
build a meaningful successor version to Edition 3 of ECMAScript, one
that addresses real problems in the language faced by JS users every
day. After eight years of stagnation, mostly due to the monopolistic
vendor.
It would be good fortune, then, I suppose, to keep JavaScript "down
on the farm", while Silverlight and its likely integration (if not
the full WPF stack integration) in IE8 have time to reach and
penetrate the Web. I get it! We should just lie back and rest easy.
Indeed Microsoft does not desire serious change to ES3, and we heard
this inside TG1 in April. The words were (from my notes) more like
this: "Microsoft does not think the web needs to change much".
Except, of course, via Silverlight and WPF, which if not matched by
evolution of the open web standards, will spread far and wide on the
Web, as Flash already has. And that change to the Web is apparently
just fine and dandy according to Microsoft.
In this view, standards bodies exist to give advantage to competing
companies, preferably by stamping -- sometimes rubber-stamping -- de
jure approval on vendor-created de facto standards. If one company
has dominant market position, it's fine for that market power to
translate directly into standards power. Sometimes, as in the case of
OOXML vs. ODF, it is also fine for a company to compete with an open
standard being favored by governments, by trying to create an
alternative standard and push it through ISO.
Mozilla's position is different: standards bodies exist to serve
developers and users, in this case web developers who write JS and
use its libraries, and browser users who face increasingly advanced
graphical and hypertext web applications that are pushing the limits
of open standards implemented natively in the browsers. In our view,
standards bodies can and should evolve standards to meet unmet needs.
This view is shared by the majority cohort in TG1, who favor ES4.
Look at the history of JavaScript from 1995 through 2004, when
Firefox launched and took back market share from IE. When Netscape
had majority browser share, Microsoft worked aggressively in ECMA (as
it was then spelled) to evolve ES1-3. Once Microsoft had near-
monopoly share, progress utterly halted.
Is Microsoft's philosophy of standards the right thing? Is it the
best way to improve the web? Take a side, but spare me the pretense
that the group acting openly and working on ES4 is somehow
victimizing the ES4 rejecters, who have to use anonymous sock puppets
to speak (with forked tongues) for themselves.
The concerned individual suggested that they simply create a new language with a new name, as there are that many fundamental differences.
Another easily refuted claim, since everything in the new language is
optional.
I'm actually not sure Doug or Microsoft's representatives know this,
however. Sometimes they speak as if type annotations or static type
checking are being mandated in ES4. Of course that's not true, but
such misapprehensions keep coming up, mostly as "spin" or "talking
points", not as substantive technical claims that could be proven
true or false.
Many of us are very concerned that the language we love is being rewritten under our feet."
Love is important, it's what keeps a boat in the air (Serenity).
This sounds all heartfelt -- but it's phony as a three dollar bill!
ES4 is a superset of ES3, with optional new facilities. It does
nothing to "the language we love" but supplement it where its
weaknesses are manifest to anyone who has written large programs in
JS. No one is required to use the new features, nothing is lost from
the common core language.
I created JS, so I can speak more authentically than whoever was
quoted above: I love JS too, quirks and all, but the idea that it
should be kept small, like a Toy Poodle, while giant companies such
as Microsoft and Yahoo! are purveying and propagating onto the Web
proprietary Rottweiler languages -- JS-beating programming languages
with ES4-like features -- and even hyping such languages against JS
(see the rigged C# chess demo from Mix07 that MS wrote to show up the
JScript version of the same program: primates.ximian.com
~miguel/pictures/mix-chess.png) -- this is a breathtaking imposture.
Sure, keep JS small in your hearts. But please, don't kid yourselves
that it has not reached the big-time, or that it and the open web
standards it works with to enable Ajax apps will survive the
onslaught of proprietary competitors, unless JS and other open
standards evolve significantly.
On that note, I'll stop. Peace, love, and truth to all, including the
anonymous cowards.
Mark,
I was not at the Ajax Experience conference, but I just spent the last week at OOPSLA. Everyone at OOPSLA I ran into who knows about the ES4 proposal hates it. The general sense is that they think it's a train wreck. But there's a feeling of resignation: Yet another runaway standards process to oppress us. The people expressing this opinion include some extremely good programming language folks with great track records and reputations.
I've been to lots of conferences with reputable PL people too, and I know that they are no more immune to rumor than other venues. All it takes is one person to start spreading FUD about a technology for it to become the buzz and ultimately accepted "wisdom." I was not at OOPSLA, so I couldn't say for sure what people are really saying. But just to hear that unnamed people were bad-mouthing ES4 contributes nothing but bad blood to the conversation. Please stick to arguments about substance. Your expertise in language design is well known and more than welcome here, Mark; I would love to hear you weigh in on content.
I did raise with people the notion that the new larger language be given a different name. One reason that C managed to stay small is that all those who wanted to grow it self-selected to grow C++ instead. Likewise, the existence of Common Lisp probably helped protect the smallness of Scheme. Everyone I mentioned this to thought
The example of Scheme seems to contradict your point. Common Lisp grew out of an incumbent language, whereas Scheme came out of a separate rewrite of Lisp. As I understand it, Guy and Gerry designed Scheme for their own purposes largely out of whole cloth. Note also that Scheme too has had to grow as it has matured. In fact, Guy Steele gave a famous talk--at OOPSLA, no less--on the importance of language growth.
At any rate, Scheme and C++ are languages with different ecosystems from JavaScript. JavaScript exists first and foremost on the web. It's the only open-standard engine behind the platform of the web. Brendan Eich has repeatedly explained why a multiplicity of languages on the web is infeasible, e.g. at the URL Jeff Dyer linked to (lambda-the-ultimate.org/node/2504). 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.
this name change would be a good idea, and would help protect the continued evolution of the language we now call Javascript, i.e., EcmaScript 262 Edition 3. Whatever its flaws or virtues might be, the ES4 proposal is simply a very different language. Please let's be honest about that and change its name.
The language is without doubt much larger than it was. Part of this is driven by a desire to provide conveniences that in ES3 people are forced to simulate, often at cost to both performance and clarity: classes via prototypes, local bindings and private members via closures, etc. And part of this is driven by a need for language features with tighter guarantees; ES3 features such as the prototype system, global object, with-bindings, eval, etc. are famously anathema to abstraction, reasoning about code, and practical compiler optimization. So introducing new language features provides programmers the features they need and implementors greater flexibility in optimization, in order to keep JS competitive.
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.
On Oct 27, 2007, at 1:53 PM, Dave Herman wrote:
In fact, Guy Steele gave a famous talk--at OOPSLA, no less--on the
importance of language growth.
On 10/27/07, Brendan Eich <brendan at mozilla.org> wrote:
On Oct 27, 2007, at 8:00 AM, Scott Elcomb wrote:
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.
Thanks. Here's hoping ES4 as proposed is not quashed by the combination of anonymous propaganda campaigns and truly-secret maneuverings within the standards body by the pay-to-play members (Mozilla is not one; we don't have that access).
What follows below are my opinions, presented bluntly as ever. This is long, but evidently necessary and appropriate to es4-discuss. I'll blog about the situation soon too. [... ~12Kb ]
Not sure if you're active on Slashdot or not. Would you mind if I attached your message to the /. thread? (I won't post it without permission, and will mention "with permission" if it's provided.)
There's much I'd like to say in response to the various points of your message (mostly in the form of questions and support); unfortunately I lack your clarity in communication.
If there's an "abuse of Slashdot" (perish the thought! lol), I'd like to see /. participants weigh-in. (evil grin)
On Oct 27, 2007, at 3:38 PM, Scott Elcomb wrote:
Not sure if you're active on Slashdot or not. Would you mind if I attached your message to the /. thread? (I won't post it without permission, and will mention "with permission" if it's provided.)
You could instead hyperlink to:
mail.mozilla.org/pipermail/es4-discuss/2007-October/001309.html
I'm assuming readers who would benefit would know and bother to
follow a link. (I stopped reading /. long ago, as having my own small
children to look after involved less chin-wiping and was more
edifying and entertaining. :-)
On 10/27/07, Brendan Eich <brendan at mozilla.org> wrote:
On Oct 27, 2007, at 3:38 PM, Scott Elcomb wrote:
Not sure if you're active on Slashdot or not. Would you mind if I attached your message to the /. thread? (I won't post it without permission, and will mention "with permission" if it's provided.)
You could instead hyperlink to:
mail.mozilla.org/pipermail/es4-discuss/2007-October/001309.html
I'm assuming readers who would benefit would know and bother to follow a link. (I stopped reading /. long ago, as having my own small children to look after involved less chin-wiping and was more edifying and entertaining. :-)
Lol. I am also a father, and know exactly of what you speak. :-)
The hyperlink (which was provided to TLUG earlier today) is the kernel of my thought; my suggestion is to "activate the marketing potential"* of /. - by re-wrapping the original thread in a question posed to "Ask Slashdot." The whole idea of "anonymous journalists" is reminiscent of recent articles in the mainstream media about the quality of certain Wikipedia entries.
Regardless of the quality of /. articles, editors, or commentators, it remains a communication nexus.
Just a thought.
- By this I mean, encouraging communication among those who don't belong to the group "readers who would benefit" - a few years ago it was conversations such as this that drew me inexorably into the world of FOSS.
On 10/27/07, Dave Herman <dherman at ccs.neu.edu> wrote:
Mark,
The language is without doubt much larger than it was. Part of this is driven by a desire to provide conveniences that in ES3 people are forced to simulate, often at cost to both performance and clarity: classes via prototypes, local bindings and private members via closures, etc.
You've stated that people are forced to simulate both performance and clarity by using closures. That is a bold statement and you have provided no evidence to back that up. In fact, I have never heard Douglas Crockford mention anything about performance implications or code clarity in any of his talks, when he explains things like the Module Pattern or Power Constructor.
Can you provide proof for this?
And
part of this is driven by a need for language features with tighter guarantees; ES3 features such as the prototype system, global object, with-bindings, eval, etc. are famously anathema to abstraction, reasoning about code, and practical compiler optimization. So introducing new language features provides programmers the features they need and implementors greater flexibility in optimization, in order to keep JS competitive.
What features do programmers need?
Garrett
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: 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 (lambda-the-ultimate.org/node/2504).
Are you referring to the post at 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.
On 10/28/07, Mark Miller <erights at gmail.com> wrote:
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.
JS has evolved since IE6 was released. Many of the "new" features are already available in ActionScript, Mozilla, Opera, and elsewhere. The language design also relieves pressure on library designers, each of whom must write essentially the same wrappers on core types, the same type-checking routines, and on and on. Too much code that "fixes" the language is being sent over the wire, and JavaScript or built-in browser objects must continually evolve to avoid that. ES4 seems like a much better base to push out innovation to libraries (notice you'll find very little new "standard lib" stuff in ES4).
The "convenient cover for conflicted business interests" comment is the sort of ad hominem nonsense that I hope we can avoid in further discussions.
Well, in principle I agree, and I think it is best to be avoid discussing motivations when possible. In this case, your message is just latest in series of "it's too ______", where the blank is some subjective quality. This one is longer, with a calmer tone, but I still don't see much substance. If the language is as radical and complicated departure as you say it is, it should be easy to find bugs in the design.
On 10/28/07, Robert Sayre <sayrer at gmail.com> wrote:
If the language is as radical and complicated departure as you say it is, it should be easy to find bugs in the design.
I should add: I have been following AdSafe and Google Caja with interest. But I don't see how ES4 makes your subset any bigger, unless it has new features authors need/want. :)
It's not all disagreement, though. One aspect of Google Caja seems preferable to me: the JSON object. In fact, I would like the committee to drop the JSON methods on the object prototype in favor of letting host environments provide that API.
bugzilla.mozilla.org/show_bug.cgi?id=387522
Fighting over the name is pointless. It's not a good name, and web developers call it "JavaScript". It seems like the right choice to represent the output of the ECMA committee, though.
On Oct 28, 2007, at 2:16 PM, Robert Sayre wrote:
On 10/28/07, Mark Miller <erights at gmail.com> wrote:
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.JS has evolved since IE6 was released. Many of the "new" features are already available in ActionScript, Mozilla, Opera, and elsewhere.
Beyond what has happened since MIcrosoft tried to stagnate the web,
ES4 takes into account solid (and far from novel) research from the
'90s on generic functions (Dylan, Cecil) and structural types (Modula
3, others), both of which are variously hard-coded or latent in
JavaScript: see the existing +, <, and other operators; see also
object and array duck types used for data definitions, JSON, and the
like, with ad-hoc shape-testing code enforcing the latent type
discipline (e.g. MochiKit's Base.isArrayLike).
The most novel aspect of ES4 is the gradual typing support (Siek and
Taha; Flanagan et al.), but this machinery (like, wrap, the
compatibility type relation) is almost trivial to prove. You could
argue that it is not worth including, but putting scare quotes (or
scare-Latinisms) around it to make it seem bleeding-edge would be bogus.
ES4 is not radically new and risky. No one criticizing it in general,
vague, and by some reports misleading terms has produced specific
evidence to the contrary.
But I'll go further, to call out what may be a disagreement over the
proper function of standards bodies. I believe that standards bodies
should synthesize well-studied, relevant research results,
implementation extensions shipped for years in derived dialects, and
pragmatic solutions to small bugs in the existing language defined by
the standard body, when working on the next version of the standard.
Whatever the motivations of ES4 critics, the assertion that standards
bodies should not host such collaborative, developer- and user-
oriented work means in practice that big companies will dominate
standards bodies, as I wrote here recently. That may be fine for pay-
to-play consortia and their biggest (and best-paying) members. It is
not good for developers, users, small and medium size vendors, or the
public in general.
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.
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.
On 10/28/07, Douglas Crockford <douglas at crockford.com> wrote:
As responsible stewards of the language, we should...
...discuss technical issues. I encourage you to begin doing so.
On 10/28/07, Robert Sayre <sayrer at gmail.com> wrote:
It's not all disagreement, though. One aspect of Google Caja seems preferable to me: the JSON object. In fact, I would like the committee to drop the JSON methods on the object prototype in favor of letting host environments provide that API.
I agree. Let's also not add .toJSONString() and .fromJSONString() to the language.
.toJSONString() creates quoting confusions that can lead to XSS-like vulnerabilities google-caja.googlecode.com/svn/trunk/src/js/com/google/caja/JSON.js.
.fromJSONString() is inappropriate as a method of String. A String can represent source text of any of a large variety of languages. Each language should know how to parse Strings. Strings should not know how to be parsed in any particular language. We should follow the object design principle that Rebecca Wirfs-Brock calls "responsibility based design".
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?
On Oct 28, 2007, at 7:36 PM, Robert Sayre wrote:
On 10/28/07, Douglas Crockford <douglas at crockford.com> 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.
On 10/28/07, Mark Miller <erights at gmail.com> 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?
On 29/10/2007, Robert Sayre <sayrer at gmail.com> 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.
On 10/28/07, Mark Miller <erights at gmail.com> wrote:
.fromJSONString() is inappropriate as a method of String.
Oops. I meant .parseJSON().
On 10/28/07, Robert Sayre <sayrer at gmail.com> wrote:
On 10/28/07, Mark Miller <erights at gmail.com> 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.
On 10/28/07, Mark Miller <erights at gmail.com> 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:
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:
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.) pauillac.inria.fr/cdrom/www/bigloo/manual/bigloo-15.html 2.) pauillac.inria.fr/cdrom/www/bigloo/manual/bigloo-7.html#container1654
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.
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: 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/28/07, Douglas Crockford <douglas at crockford.com> 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 www.jsunit.net and www.openqa.org/selenium
Kent Beck and Robert Martin have sume useful books. They're not about javascript, but software, process, testing. Great stuff.
,
Garrett
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 bugs.ecmascript.org/ticket/250 and http://
bugs.ecmascript.org/ticket/251).
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? * article.gmane.org/gmane.org.user-groups.linux.tolug/36420 ---------- Forwarded message ---------- From: Walter Dnes <waltdnes at waltdnes.org> Date:
Oct 27, 2007 3:44 AM Subject: Re: [TLUG]: ECMAScript ("Javascript") Version 4 - FALSE ALARM To: tlug at ss.org 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
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 at waltdnes.org> 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: gtalug.org TLUG requests: Linux topics, No HTML, wrap text below 80 columns How to UNSUBSCRIBE: gtalug.org/wiki/Mailing_lists -- Scott Elcomb www.psema4.com/_______________________________________________ Es4-discuss mailing list Es4-discuss at mozilla.org, mail.mozilla.org/listinfo/es4-discuss</quote>
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 (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
I think the MAIN problem is not technical, but rather political:
When I went to the Ajax Expereince, several people commented that
- There was a 'deal' between Adobe and Mozilla
- 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 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
- 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.
- 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:
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 (
doku.php?id=proposals:destructuring_assignment), which superseded my
earlier group assignment (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.
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.
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".
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
- 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:
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
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.
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/07, Ric Johnson <Cedric at opendomain.org> 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.
- 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:
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.
---------- Forwarded message ---------- From: Yehuda Katz <wycats at gmail.com>
Date: Oct 29, 2007 1:52 PM Subject: Re: [TLUG]: ECMAScript ("Javascript") Version 4 - FALSE ALARM To: Ric Johnson <Cedric at opendomain.org>
On 10/29/07, Ric Johnson <Cedric at opendomain.org> wrote:
I think the MAIN problem is not technical, but rather political:
When I went to the Ajax Expereince, several people commented that
- There was a 'deal' between Adobe and Mozilla
- 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
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.
Thanks for the clarification Alex.
On Oct 29, 2007, at 3:05 PM, Ric Johnson wrote:
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
Yes, but you're repeating what was said, including some assumed
premises I want to argue about first.
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.
Wow, I can't tell what Doug said now, since he just today told me
that he included Opera among the pro-ES4 sub-group, and 3 is greater
than 2. Perhaps John Resig, who was on the panel, can testify. Not
that we need to dwell on what Doug said :-/.
Since you are repeating more dubious claims, possibly from Doug, I'll
repeat that TG1's majority outnumbers its minority, counting
companies active over the last two years, by four to two. By people
including invited experts, more like seven or eight to three. But in
any event, this is an Ecma and potentially ISO issue, and unanimity
is not required to make progress on a draft standard.
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,
That was supposed to be a humorous aside; never mind.
but I fail to see how rejecting the question gets us anywhere.
See below about arguing premises before questioning anyone based on
conclusions based on the premises.
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.
If your question is about motives for companies in favor of ES4 as
proposed, then I can answer only for Mozilla. If you are asking me to
prove a negative -- to disprove a hidden agenda, a secret Adobe/
Mozilla (Opera/MbedThis/UC Santa Cruz/Northeastern University)
pecuniary or other supposedly malign interest of some sort served by
ES4, then you are laboring under a fallacy (can't prove a negative).
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.
My understanding is that John, who has not participated in TG1, did
not try to rebut anything Doug said, but simply affirm that he was
enthusiastic about JS2 and that Mozilla was committed to ES4.
Let's step back from personal authority and who said what. Mozilla's
position, is that standards should address unmet use-cases and actual
bugs in prior editions of a standard, and work to address them
without a-priori restrictions on things like competitive positions in
the market, or even size or "mood" of programming language as
perceived by some of its fans. Standards should evolve in the open,
sometimes rapidly, to incorporate sound research results and real-
world feedback.
And make no mistake: JS developers have real problems using JS1/ES3
at scale, both because of limitations in current implementations, and
because of the small design of the language (see Guy Steele's
"Growing a Language" talk, please!).
This is why Mozilla has invested in ES4.
from what I can understand ES4 seems to bother some people
is it because of fear of change, fear of competition, or whatever software politics, I don't know and I don't care
but I do know this, if me, the little guy, could access this mailling list, the different wiki, ask questions etc. why the hell microsoft and yahoo, or whatever other party being against this ES4 proposal could not just do the same and participate ?
so sorry I don't buy the "ECMAScript must change its name" and I don't buy either the "ES4 is too large, blah blah , it change too much ES3".
languages are meant to evolve, I waited long enought as a coder to see ES evolve, didn't liked at all the ES4 draft of 99, didn't liked the JScript.NET implementation, and didn't liked either the AS2 implementation, but what we have now in the current proposal is good, it really evolved in the right direction keeping the dynamism that I always loved in ES3, and I didn't see it evolve from yesterday it's been months all that is being discussed.
And all that obviously in the open as I, the little monkey, could even read all that.
zwetan
ps: thanks a lot for Guy Steele's talk link :)
On Oct 29, 2007, at 3:06 PM, Neil Mix wrote:
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.
As the press release noted, Tamarin was open-sourced to share effort
and accelerate development (and inform specification!) of a sound,
implementable, high-performance ES4. I think I can say that without
speaking too much for Adobe.
Also, and this is edgier: it's not as if Macromedia (remember, it was
Macromedia who developed the VM originally) wanted to bear the cost
of a high-performance VM all by itself. To add relevant information
at the risk of dishing a rumor (sue me), I heard that Macromedia
originally tried to license an existing small VM, and started on what
became Tamarin only after being denied that license.
I'll also testify, as an outsider with no interest in Adobe, that the
Adobe (originally Macromedia) employees on TG1 have always worked
from shared principles and evidence to reach better design decisions,
without regard for a corporate agenda. In particular, they've been
willing to develop changes -- even if those changes inflicted
incompatibilities on ActionScript users. I've heard this came at some
political cost inside Adobe; it's not hard to imagine marketeers and
evangelists there who might prefer a rubber-stamp.
But ES4 is not AS3, and it differs enough (see http://
wiki.ecmascript.org/doku.php?id=clarification:adobe_as3) that the
claim that Adobe is forcing something it owns, without thoughtful
changes, through a rubber-stamp process, is demonstrably false.
(Rubber-stamped standards exist; you may have heard of OOXML?)
Of course Adobe desires to standardize, even at the cost of
incompatibility. Reduced developer brainprint from variant dialects
of JS is in their interest, and in their developers' interest. How
nefarious.
On 10/29/07 4:51 PM, Brendan Eich wrote:
On Oct 29, 2007, at 3:06 PM, Neil Mix wrote:
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.
As the press release www.mozilla.com/en-US/press/mozilla-2006-11-07.html noted, Tamarin was open-sourced to share effort and accelerate development (and inform specification!) of a sound, implementable, high-performance ES4. I think I can say that without speaking too much for Adobe.
Yes, you can. And its still true.
Also, and this is edgier: it's not as if Macromedia (remember, it was Macromedia who developed the VM originally) wanted to bear the cost of a high-performance VM all by itself. To add relevant information at the risk of dishing a rumor (sue me), I heard that Macromedia originally tried to license an existing small VM, and started on what became Tamarin only after being denied that license.
True or not, I¹m sure glad Adobe was denied that option. Open standards and open vms will work out better for Adobe customers and web users in general.
I'll also testify, as an outsider with no interest in Adobe, that the Adobe (originally Macromedia) employees on TG1 have always worked from shared principles and evidence to reach better design decisions, without regard for a corporate agenda. In particular, they've been willing to develop changes -- even if those changes inflicted incompatibilities on ActionScript users. I've heard this came at some political cost inside Adobe; it's not hard to imagine marketeers and evangelists there who might prefer a rubber-stamp.
Thanks Brendan.
But ES4 is not AS3, and it differs enough (see clarification:adobe_as3) that the claim that Adobe is forcing something it owns, without thoughtful changes, through a rubber-stamp process, is demonstrably false. (Rubber-stamped standards exist; you may have heard of OOXML?)
Of course Adobe desires to standardize, even at the cost of incompatibility. Reduced developer brainprint from variant dialects of JS is in their interest, and in their developers' interest. How nefarious.
³A rising tide lifts all boats². A better web will become a bigger web. This is good for Adobe, and just about everyone else on this list.
Any questions?
Brendan Eich wrote:
I'll also testify, as an outsider with no interest in Adobe, that the Adobe (originally Macromedia) employees on TG1 have always worked from shared principles and evidence to reach better design decisions, without regard for a corporate agenda.
I would like to confirm this as well, as a competing browser vendor and fellow member of TG1. The direction ES4 has taken is the result of user feedback and internal experience with the extensions each of the involved companies has made, as well as honest attempts to promote implementation compatibility (always a concern for minority browsers, though only a concern for the majority browser when it suits them politically).
Chris Pine Opera Software
Ric Johnson wrote:
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.
I'm not sure how Doug could have honestly said this, but whatever was said: this is simply untrue, no matter how you count.
There were 3 dissenting people (from 2 companies) for the last year. On the other hand, there were 8 people (from 4 companies and 2 universities) in favor, for 2 years (or 7, depending on how you count it).
If you look at the amount of work put forth (discussion, ref-impl, testing, bug-tracking), the disparity becomes staggering. (Well, work that has been done in the open, anyway.) The amount of time and care that has gone into ES4 as we are proposing simply dwarfs the weak, inconsistent attempts to halt the work.
To suggest that there is a 50/50 split in the group is simply absurd.
Chris Pine Opera Software
Okay, good to air things out I suppose. If we wanted to use Tamarin as leverage to keep ES4 as close to AS3 as possible we're extremely incompetent (as evidenced by ES4's progress beyond AS3). Luckily, we have some competencies. Tamarin was well designed and shouldn't have to change too much but the compiler guys will have their hands full!
Hopefully the end result of all this is folks that should be participating in ES4's development and aren't start to. Better late than never I suppose, although if my ES4 spec isn't printed out and heavily dog eared by XMas 08 I might have to sucker punch Santa. Having personally had my ideas sandbagged by committees (all hail J2EE) I'm cheering TG1 to the finish line with or without additional participation. It should be noted I don't directly particpate in TG1, I'm just a well informed cheerleader. Hopefully ES4 will start getting some more and more positive cheerleading in the blogosphere.
Its funny to hear this don't break the web stuff, its exactly the conversation that dominates every release of flash since one player runs all swf versions. We routinely surprise ourselves with our ability to make sweeping changes to things and maintain backwards compatibility and I'm confident TG1 can do the same with ecmascript (and mozilla with its implementation). I'm confident b/c as the stewards for Tamarin we'll be helping directly.
Regrettably we didn't have time to do what Brendan aims to do (run all script versions on one VM) but we knew it was possible and a good idea. Its still sits pretty prominently on the shelf of un-realized pet projects. Really you probably just want to keep the compiler separate I think.
Anyways, the main point is that if anyone starts fear-mongering about breaking the web they are probably either incompetent or have ulterior motives (or both). Hopefully the sticker shock of the "its too big" reaction will be fleeting once folks realize there's measured reason and precedent behind the grab bag of features that the overview lays out.
Ric Johnson wrote:
I think the MAIN problem is not technical, but rather political:
Clearly. Hence the lack of substantive argument against the proposal and the recurring issue of the name of the language.
When I went to the Ajax Expereince, several people commented that
- There was a 'deal' between Adobe and Mozilla
And Opera? Yes, I am maybe the fourth or fifth person to point this out, but perhaps if enough people say it, this can be the last time we have to deal with this point.
There is no deal, no secret coalition. The ES4 work has been open, and has been the collaboration of more than two companies, frequently competitors. I think our motivations should be clear: to improve the web. We have do a fair amount of in-house ecmascript development, and ES4-as-proposed is simply a stronger, better language. As Jeff so aptly put it, "a rising tide lifts all boats".
And any concerns about ES4 destabilizing the web are either disingenuous or simply ignorant: no one is more concerned about breaking the web than a minority browser vendor. :) The ES4 work has been both about increasing the programming-in-the-large tools to the programmer, as well as increasing implementation compatibility. We run the reference implementation against ES3 test suites to ensure backwards compatibility. When we say "it's backwards compatible", this isn't a guess or a hope.
We can't bet Opera's future on guess or a hope.
If you want to continue programming is ES3, and leveraging existing ES3 code, that will be fine. But for some ecmascript developers, it just isn't enough for the platform the web has become.
- There was not consensus on the new features, but they are being pushed through anyway
There has always been a clear majority. There was never unanimous agreement, nor is that necessary. When you are voted down 8-to-3, to say "there was no censensus" is to say "I will not accept that I did not get my way". In my opinion, such an attitude is disrespectful to the other members of the committee (personally) and to the standards process (professionally). I would be ashamed if I conducted myself in such a manner.
Chris Pine Opera Software
zwetan wrote:
so sorry I don't buy the "ECMAScript must change its name"
No, of course not. Nevermind that the scope of TG1 is "to standardize the syntax and semantics of a general purpose, cross platform, vendor-neutral dynamic scripting language called ECMAScript":
www.ecma-international.org/memento/TC39-TG1.htm
I don't think that anyone believes there is honest concern that the name of the language might confuse people about which language they are getting. ES3 programs will continue to work.
The push to change the name is a push to kill the ES4 proposal. It's that simple.
First you change the name. Then you admit it's a new language, and thus a new spec. Incompatibilities with ES3 inevitably follow, in order to incompatibly fix bugs (something we'd all like to do, but not at the expense of breaking the web). Browser vendors must then ship two runtimes to support the new language (impossible on small devices), while no work is required to truthfully claim "our browser has full ecmascript support". So small devices don't get it, IE doesn't do it, and ES4 as proposed dies.
So I don't buy it either: I don't believe that anyone arguing to change the name thinks the language would thus succeed. This rose, by any other name, would not be smelled at all.
Chris Pine Opera Software
From a pragmatic perspective, it seems to that the critical goal behind all
of this, is what will bring a better development environment for the future of the web, and the key to this is what will be broadly implemented. The choice of the name is of course around this central issue since the ES title brings such a strong motivitation for implementation. However, if ~10 years down the road, ES4 is not implemented broadly enough that web developers can code to it, than it is of signficantly less value. While unanimity is not needed for a standard to be passed, if the one of the key browser vendors will not implement it, than how valuable are our efforts? I know that there are, or will be efforts to provide a Tamarin plugin for other browsers, but is this really what we are pinning our hope on? Plugins usually don't reach necessary distribution for developers to rely on them. Or are we hoping that the ES4 title will be sufficient to get an implementation from every vendor? I certainly acknowledge that it is insidious that there might a suggestion to design around one member, but I will still ask, is there any concessions that can be made to increase the probability that MS would implement ES4 in the future? Perhaps this has already been discussed, so I apologize if it has. Does MS have specific issues, or is their dissent simply for the purpose of avoiding committing to implementation (regardless of the content of ES4)? Is security one of the main issues? Is it the size and scope of the language? From what I understand, I think these are Crockford's concerns, although I don't know if that is true for MS. I think that if even 25% subset of ES4 was uniformly implemented in all browsers in 10 years, web developers would be vastly further along than if the 100% of ES4 was implemented in half the browsers. While unfortunate that such orthogonal issues could affect language design, and perhaps stifle innovation, I would like to see what will be best for the future of the web. Does anybody know if there is anything that can be done to increase the likelood of full cross browser implementation of ES4? Does anyone know the issues or parts of ES4 that are causing dissent? Is it the impact of the size of the language (on security, implementability, etc)? Apologies for my excessive pragmatism, Kris
Please note that Microsoft HAS responded on my blog (with a reply from Brendon and myself)
PLEASE note: Although the domain is OpenAjax.Com, we are NOT part of the Open Ajax Alliance (although I am the contributor or Openajax.Org to Jon Ferraiolo )
I do not have any advertising or spam on my site, so please feel free to visit and comment
Ric Johnson
Ric Johnson wrote:
Please note that Microsoft HAS responded on my blog (with a reply from Brendon and myself)
Yes, I read that. I am extremely doubtful that Microsoft is suddenly so concerned about browser compatibility for the benefit of the web. (When IE passes the Acid 2 test, let's talk again.)
It's nice that MS has constructed this document identifying browser differences. But frankly, this is too little, too late. We are painfully aware of the significant differences. Suggesting that we all sit down and strive to fix every last trivial discrepancy under the guise of "browser compatibility" is manipulative and, from a business standpoint, absurd. It is an unnecessary task that would never be completed.
In essence, it is just another stalling tactic.
Chris Pine Opera Software
The suggestions of bloat and instability from some corners are rather disingenuous when you consider that
(1) at least one high-quality ES4 engine (Tamarin) will be available with a source license compatible with both open-source and commercial vendors, so the claim that it will be hard for browser vendors to implement can theoretically be reduced to a claim that it will be hard for browser vendors to integrate. (Sure, there may be technical or political obstacles to using a particular engine, but assuming that the ES4 spec will require every browser vendor to write their own implementation is clearly false.)
(2) at least two active contributors to Tamarin (Adobe and Mozilla) have a very high vested interest in keeping code size small, as the success of both Flash Player and Firefox are predicated on acceptable download sizes.
As Tom pointed out, the compiler for ES4 will definitely get more complex, but the VM is unlikely to grow significantly in size or complexity.
On Oct 30, 2007 10:13 AM, Chris Pine <chrispi at opera.com> wrote:
Yes, I read that. I am extremely doubtful that Microsoft is suddenly so concerned about browser compatibility for the benefit of the web. (When IE passes the Acid 2 test, let's talk again.)
It's nice that MS has constructed this document identifying browser differences. But frankly, this is too little, too late. We are painfully aware of the significant differences. Suggesting that we all sit down and strive to fix every last trivial discrepancy under the guise of "browser compatibility" is manipulative and, from a business standpoint, absurd. It is an unnecessary task that would never be completed.
In essence, it is just another stalling tactic.
When I raised non-technical points critical of the ES4 proposal, people rightly shot back with a "technical discussion only!" response, which I've respected. Since then, most of the traffic on the list has been non-technical criticisms of the critics of the ES4 proposal. Much of this traffic, such as the message I quote above, continues to speculate about the motives of others, rather than engaging with what they are saying. My comments, which provoked so much response, contained no such speculation. I can only conclude that, on this list, the injunction "technical discussion only!" should be interpreted as carrying the additional clause "unless you agree with us."
Ooo... busted! (And right after I send out a non-technical-related email.)
But yes, you are quite correct: we should probably go back to the original charter of this list (technical discussion only) and move the political issues to another venue.
Totally agree that ES4 can be implemented without undue bloat. ES4 VMs should remain small with modest growth despite the features being considered for ES4.
We too are creating a compliant ES4 implementation to serve embedded devices. So our target is not so much browsers, but small embedded devices including mobile. Typical uses are mobile widget engines and embedded web servers. Our implementation (EJScript to add yet another name) is dual license: open source and commercial as are our previous embedded projects. You won't see much on our web about this yet
Sent from my iPhone
Sent from my iPhone
Begin forwarded message:
On Oct 30, 2007, at 10:45 AM, Steven Johnson wrote:
The suggestions of bloat and instability from some corners are rather disingenuous when you consider that
(1) at least one high-quality ES4 engine (Tamarin) will be available
with a source license compatible with both open-source and commercial
vendors, so the claim that it will be hard for browser vendors to implement can theoretically be reduced to a claim that it will be hard for browser
vendors to integrate. (Sure, there may be technical or political obstacles
to using a particular engine, but assuming that the ES4 spec will require every browser vendor to write their own implementation is clearly false.)(2) at least two active contributors to Tamarin (Adobe and Mozilla)
have a very high vested interest in keeping code size small, as the success
of both Flash Player and Firefox are predicated on acceptable download sizes.As Tom pointed out, the compiler for ES4 will definitely get more
complex, but the VM is unlikely to grow significantly in size or complexity.
For embedded browser-hosted implementations (like Safari on the iPhone
and iPod touch, or Nokia's S60 Browser), it's important for it to be
possible to implement a complier that is small in memory use and code
footprint, not just a VM. I have not yet read the spec in enough
detail to know if this is the case. But your points seem to primarily
address VM size, and to my knowledge the Flash download only includes
the VM, not a compiler.
Can anyone address feasibility of a small full implementation (source
code all the way to execution)?
, Maciej
On Oct 30, 2007, at 10:49 AM, Mark Miller wrote:
On Oct 30, 2007 10:13 AM, Chris Pine <chrispi at opera.com> wrote:
Yes, I read that. I am extremely doubtful that Microsoft is
suddenly so concerned about browser compatibility for the benefit of the web.
(When IE passes the Acid 2 test, let's talk again.)It's nice that MS has constructed this document identifying browser differences. But frankly, this is too little, too late. We are painfully aware of the significant differences. Suggesting that
we all sit down and strive to fix every last trivial discrepancy under the guise of "browser compatibility" is manipulative and, from a business standpoint, absurd. It is an unnecessary task that would never be completed.In essence, it is just another stalling tactic.
When I raised non-technical points critical of the ES4 proposal, people rightly shot back with a "technical discussion only!" response,
No, that's not what Rob Sayre wrote -- he said (in a later post) that
you (among others) were trash-talking without any technical
substance. Rob wrote:
I'm afraid your message falls into a pattern I've been seeing lately: unsubstantiated, non-technical criticism. In other words, FUD.
If you have technical criticism to contribute, it is of course
welcome.
That's different from saying "technical discussion only." It is not a
demand for exclusively technical criticism. It is a request to stop
unsubstantiated FUD.
which I've respected. Since then, most of the traffic on the list has been non-technical criticisms of the critics of the ES4 proposal.
Guess why? Because the critics have made no technical objections on
this list, and some carefully parsed (in Yehuda Katz's phrase; I
wasn't there and I really can't tell what was said) statements about
the politics and division within Ecma TC39-TG1 by Doug Crockford at
last week's The Ajax Experience in Boston.
Of course people are going to argue about the political fight
spilling out of TG1, and we may as well argue here. It's not as if
pretending this political fight is not happening, or that it has no
consequences on ES4, serves anyone's interest except those trying to
stop ES4 from making it out of Ecma. It's not as if we have a better
venue.
Much of this traffic, such as the message I quote above, continues to speculate about the motives of others, rather than engaging with what they are saying.
Chris Pine is on TG1 and a witness to what's going on. He is not
sowing unsubstantiated FUD, he is talking about what he has observed
happening inside TG1, and giving his interpretation of it. He could
be wrong, but his message is not simply speculation.
Politics inevitably involve motives and conflicts of interest, apart
from purely "technical" concerns genuinely expressed. And as should
be very clear by now, the objections to the proposed ES4 that TG1
members have heard are either non-technical, or technical only in a
vacuously general sense.
My comments, which provoked so much response, contained no such speculation.
No, you merely called ES4 a train wreck and a runaway standard, by
repeating what you heard from someone at OOPSLA. In my book, that's
much worse than speculating about Microsoft's motives or business
interests.
Please note that I'm not talking about individuals who work for
Microsoft, many of whom are fine people who may hold sincere
technical opinions about ES4 as proposed, or at least their
understanding of it. I'm talking about the company's business
interests, its strategies.
Microsoft's interests and strategies are absolutely critical to
consider when developers ask about the future of ES4, as Kris Zyp
just did -- and I am going to respond to him on this list. My
response will contain technical as well as political content.
I can only conclude that, on this list, the injunction "technical discussion only!" should be interpreted as carrying the additional clause "unless you agree with us."
You never heard "technical discussion only", and no one ever demanded
agreement with some mythical "us". You've made a straw man and
knocked it down.
On Oct 30, 2007, at 11:37 AM, Yehuda Katz wrote:
Sent from my iPhone
Twice :-/.
Begin forwarded message:
From: Yehuda Katz <wycats at gmail.com> Date: October 30, 2007 11:26:58 AM PDT To: Michael O'Brien <mob at mbedthis.com> Cc: es4-discuss <es4-discuss at mozilla.org> Subject: Re: [TLUG]: ECMAScript ("Javascript") Version 4 - FALSE
ALARMI spent all of yesterday writing code in ES4 but the current state
of the RI is so crippling as to make it a fairly useless tool for
exploring how one would really write ES4 code.
The RI is working well, but for reasons I should have paid more
attention to, the snapshot at www.ecmascript.org is out of
date, as you say. I think it should be udpated soon, even if it does
not track the overview document yet. I'm working on this. Apologies
for the hassles.
Maciej Stachowiak wrote:
Can anyone address feasibility of a small full implementation (source
code all the way to execution)?
If we didn't think it was feasible, we wouldn't be here. :) While we don't have a full implementation yet (no one does), progress is looking good. Our latest engine, just out in Opera 9.5 beta, is both smaller and considerably faster than our previous engine (which we've shipped on many small devices). It runs on devices smaller than an iPhone, no problem. (How much ram does an iPhone have? I don't see that on Apple's site.)
Chris Pine Opera Software
Its the es4 "discuss" list, I think the "technical discussion only" is probably overly restrictive, there's lots of subjective judgements involved in evaluating languages. We just want to hear workable feedback and "it has too many features" or it has many good features that won't work well together isn't particularly helpful. What features would you drop? What problems arise when exactly which features are combined?
Why do you think Java 1.5 is worse than 1.4? That may be relevant given the overlap between the languages. We write a lot of Java around here and we generally prefer 1.5. Our ActionScript3 compiler is written in 1.5 even though to meet our customers needs we had to write a class file "downgrader" to be able to run the compiler on older jvms. We also use a lot of python and that's probably evident in ES4, personally I wish ES4 could have the indent scoping feature but that got shot down long ago.
So don't feel limited to technical discussions, just help us out by adding some meat to your criticisms. It would also help if you could get all the extremely good programming language folks you met with at OOPSLA who hate ES4 and feel they are being oppressed by this runaway train wreck of a standards process to voice their concerns. Sounds horrific! Can't imagine how those feelings got scared up ;-) Well its good that people care, they should, but obviously we don't want to steam roll anyone and would like to hear from them, oppressed or otherwise.
www.engadget.com/2007/07/01/iphone-processor-found-620mhz-arm
I've heard its got 128MB with 11mb of memory reserved for the display, add 620 mghz processor, 8 GB disk, fp and integer SIMD units. Does this still qualify as an embedded device? It probably sports virtual memory for cying out loud (backed up by claims of a native SDK on the horizon). Personally I think they should lose to java coprocessor and add more cache.
The iphone could probably run a poorly written, bloated, interpreted ES4 implementation well enough to run most web pages.
On Oct 30, 2007, at 1:45 PM, Thomas Reilly wrote:
www.engadget.com/2007/07/01/iphone-processor-found-620mhz-arm
I've heard its got 128MB with 11mb of memory reserved for the display, add 620 mghz processor, 8 GB disk, fp and integer SIMD units. Does
this still qualify as an embedded device? It probably sports virtual
memory for cying out loud (backed up by claims of a native SDK on the
horizon). Personally I think they should lose to java coprocessor and add more cache.The iphone could probably run a poorly written, bloated, interpreted
ES4 implementation well enough to run most web pages.
I can't talk about the details of the iPhone's hardware but I can tell
you that iPhone and iPod touch do not have room for significantly more
runtime memory use or code footprint. Getting WebKit (pretty small for
a browser engine) to run was hardly a cakewalk.
In any case, I'm not trying to spread FUD here. I'd honestly like to
get some estimates of language size and implementability. I'm going to
put my money where my mouth is and do the counts I suggested.
, Maciej
[Kris asks legitimate questions, to be answered by more than a
Microsoft spokesperson. I'm going to reply cc'ing the list, even
though there are political points here along with technical content.
The list is for discussion of ES4, and that category looks like it
must include some political discussion.
Also, this reply is LONG. Sorry, I've tried to compress without
doing anyone an injustice.
Skip if you want to avoid any political content. If you think I'm
FUDding or attacking individuals unfairly, call me on it -- with
specific quotations if possible. If I'm out of line, I'll apologize
to the list and amend my words. If we simply disagree on the
fundamental substance, that's good to know too.
I'm trying to shed some light on what has clearly been too much of
a dark-room standards process, excluding the materials we've exported
at ecmascript.org.
/be]
On Oct 30, 2007, at 9:17 AM, Kris Zyp wrote:
From a pragmatic perspective, it seems to that the critical goal
behind all of this, is what will bring a better development
environment for the future of the web, and the key to this is what
will be broadly implemented. The choice of the name is of course
around this central issue since the ES title brings such a strong
motivitation for implementation. However, if ~10 years
Try two years -- ten is way, way too long for developers to wait, and
anyway beyond any credible crystal ball's range. The proprietary
stacks from Microsoft and Adobe won't wait that long for competition
from browser-based web standards, as Doug Crockford and others warn;
they'll propagate all over the web well before ten years.
down the road, ES4 is not implemented broadly enough that web
developers can code to it, than it is of signficantly less value.
While unanimity is not needed for a standard to be passed, if the
one of the key browser vendors will not implement it, than how
valuable are our efforts?
Let's find out, by having a standard that browsers and plugins can
choose to implement for interoperability and shared developer
knowledge. Enough companies want ES4 as a standard that (absent
technical problems), it ought to become one, whether or not all
browser vendors buy into it.
If you give all the power over standardization to any one company,
then you are that company's slave, and I predict you'll get treated
accordingly. This happened once already, after IE achieved a virtual
monopoly. Just consider all the unfixed JScript bugs, many dating to
IE4, still in IE7.
I know that there are, or will be efforts to provide a Tamarin
plugin for other browsers, but is this really what we are pinning
our hope on?
Not necessarily, but (hey, I came up with it ;-) it's not a bad plan
absent competitive pressure on Microsoft to support ES4 in IE.
You may not know this, but minority-share browsers do not have as low
market share as the Comscore and WebSideStory analytics firms'
results show in aggregate for the U.S.. At high value sites, visited
more frequently by "lead users" and otherwise influential (and better-
monetized) visitors, Firefox, Safari, and Opera do better --
sometimes much better. If you look at Xiti's results for Europe,
Firefox is trending to cross the 50% market-share line in some
countries.
Whatever you do, never give up your own sovereignty as a browser user
or a web developer to a dominant player. You always have a choice.
Plugins usually don't reach necessary distribution for developers
to rely on them.
Counterexample: the Flash Player.
I have no idea whether Flash would ship ScreamingMonkey support. I
certainly hope so, given Microsoft's rejection since early this year
of ES4.
Or are we hoping that the ES4 title will be sufficient to get an
implementation from every vendor?
Title, schmitle. :-) The "brand value" of ES4 may be an issue for
browser vendors, but it is not the main issue for developers, and
users don't know or care. What matters is whether web developers can
effectively demand, and count, on near ubiquity and quality from ES4
implementations, soon (a year or two). That is an open question, as
noted above -- and there are several reasons to have hope.
I certainly acknowledge that it is insidious that there might a
suggestion to design around one member, but I will still ask, is
there any concessions that can be made to increase the probability
that MS would implement ES4 in the future?
No. Without speaking for anyone else, I am now going to give more
information about what has already been said inside TG1, since the
TG1 dispute has already spilled out into the blogosphere since last
week's Ajax Experience East, when as part of a panel discussion, Doug
Crockford made some statements about TG1 members and motives. Others
in TG1 can back this up, and anyone can check our meeting minutes,
which are public at with complete
revision histories.
While at certain times, as in late 2006 and before March 2007,
Microsoft talked in TG1 (or possibly just to me) about perhaps
standardizing JS1.7 in Firefox 2, at other times we have heard a very
clear "No" to the question of substantive changes from ES3 like those
in Firefox: No JS1.7 extensions, no change from ES3 apart from
deprecations and maintenance.
IIRC, you yourself heard a "No" in reply to your "JS1.7 features
coming in IE?" face-to-face question posed to Chris Wilson at The
Ajax Experience West this summer (I happened to be nearby at the
time). I recall seeing some back-peddling to avoid committing either
way in a comment from Chris at ajaxian.com after that, but you
tell me: do you really expect anything more, given statements such as
Allen Wirfs-Brock's comment at Ric Johnson's OpenAjax blog, and the
content available at the JScript blog?
Sure, a Microsoft "vision" for JScript will be rolled out, real soon
now. Based on everything we've heard in TG1, it is safe to say that
the vision is either a fork of ES3 away from ES4, or a lot of do-
nothing posturing about maintenance and safeguarding compatibility,
to give Silverlight and WPF time to penetrate the Web. I would love
to be proven wrong -- c'mon, Microsoft, make me eat my words
(happily): embrace (and extend, for all I care) ES4. Just get the
mandatory core language right, as in, far fewer overt bugs than
JScript vs. ES3.
Perhaps this has already been discussed, so I apologize if it has.
Does MS have specific issues, or is their dissent simply for the
purpose of avoiding committing to implementation (regardless of the
content of ES4)? Is security one of the main issues? Is it the size
and scope of the language? From what I understand, I think these
are Crockford's concerns, although I don't know if that is true for
MS.
One at a time:
- Not only the majority of TG1, but many on this list, have asked for
specific technical objections, and received none in reply. Even a
summary technical judgment against ES4 in full needs to be
decomposable into smaller technical arguments. ES4 needs to be fully
specified and implemented, for sure, so we're not claiming it is done
or proven yet. But disproof that disqualifies it as a candidate
successor edition needs to be demonstrated.
On a positive note, I will say this: as a working group, when we have
not been wearing political armor, we've had productive technical
dialogs about proposed ES4 features and their progenitors in the
literature, especially with Allen Wirfs-Brock. But the Microsoft
position (so-called -- it's clear when Allen is speaking for
Microsoft, which is a good thing!) has not consisted of detailed
analysis and conclusions against specific technical features. It has
simply been a summary judgment expressed as "Microsoft opposes ES4"
and (memorably, from April) "the web doesn't need to change much".
- The browser profile I cited above, started by Pratap Lakshman of
Microsoft, was superseded by an ES3.1 proposal, which was made
following an agreement at the March TG1 meeting. At that meeting, it
was also agreed that any ES3.1 would be implemented as a subset of
the ES4 reference implementation (for testability) This has not
happened.
Everyone also agreed at the March meeting that ES3.1 would not be
approved by TG1 until it could be evaluated for forward and backward
compatibility. Finally, I recorded an agreement at least among the
majority of TG1 that ES3.1 was not approved of as a standard-to-be,
but was something the majority thought could be explored further by
the minority group, under TG1's charter from TC39.
Note that the "3.1" name does not work in Ecma terms. There is no
minor edition process in Ecma (mozilla.org has hosted the only errata
page), so if ES3.1 were standardized as a successor to ES3, it would
be renamed the 4th Edition. This obviously would create conflict in
TG1 and confusion in the market.
-
ES3.1 was superseded by no substantive work in the es3.1 section
of the wiki since April. Instead, two documents describing JScript
(one about the @if/@else/@endif preprocessor (PDF), the other about
JScript deviations from ES3), have been produced by Pratap. These are
informative, but not even potentially normative as written, except
where browser implementations have already matched JScript (in order
to gain market share by interoperating) -- and ES4 already contains
such bug fixes to ES3. -
Security is an "issue" (not in the Oprah sense), all right. A bit
more precisely, it is a set of end-to-end properties that need solid
enforcement mechanisms at many layers of abstraction. Security is
however not a unitary good or "product". You sometimes hear demands
for TG1, or all browser vendors, to stop the world and work on
security. That is an unrealistic demand; the world doesn't work that
way.
We've talked a bit in TG1 about security properties, mainly Integrity
and Confidentiality. Apart from making ES4 statically checkable and
improving binding forms to reduce mutation hazards, we are not biting
off riskier work. The academic research is not solid yet (unlike the
research on multimethods, for example). There is no good way that
anyone involved in TG1 can see, in the core ECMAScript language only,
to standardize a capability system for the web.
It's clear from experience from Mozilla and many security researchers
that even a posteriori mashups built on a capability system will leak
information. So information flow type systems could be explored, but
again the research on hybrid techniques that do not require a priori
maximum-authority judgments, which do not work on the web (think
mashups in the browser without the user having to click "OK" to get
rid of a dialog), simply is not there yet. Mashups are unplanned,
emergent. Users click "OK" when they shouldn't. These are hard, multi-
disciplinary research problems.
Experiments such as Google Caja are interesting (discussion here),
and Mark Miller will (I hope) smite me mightily if I misspeak about
it, but as far as I can tell, such systems create an incompatible
subset of JS into which developers may "opt" -- not a successor
standard for the ECMAScript language that is backward compatible.
Such a subset could be a very good thing, don't get me wrong. But it
does not fall neatly under TG1's charter, because it's not backward-
compatible, and profiled standards are considered harmful.
Anyway, it's early days for Caja and other such systems. If TG1
continues to function, it should definitely harvest good ideas from
it, and stand on shoulders, not toes.
We've pressed Doug Crockford on this point and heard nothing in the
way of concrete proposals, save for a small one I championed at the
last face-to-face meeting (a better-isolated String.prototype.evaluate
() taking a scope object). But that went nowhere for lack of effort
-- I half expect it to turn up in "Microsoft's vision for
ECMAScript", which would make a fork in the standard. I'll still try
to rescue it for ES4, but it's just a small isolation device, good to
have, but not nearly enough for "Security" with a capital S.
I hope to hear more from Doug and others as things evolve, but ideas
like a capability-based message-passing architecture built on Google
Gears, which Doug proposed at a talk given at Google recently, do not
fit in ES4's schedule and mandate to avoid premature standardization.
ES4 is not about to normatively specify Google Gears APIs, which only
came out this past spring. Gears APIs for workerpools are a great
idea, but they are out of scope for the core language, which has not
only an apparently single-thread execution model, but one-thread-only
and even zero-OS implementations.
APIs such as those purveyed by Gears should be standardized in the
WHAT-WG and/or the W3C (and I've seen some WHAT-WG standardization
work on Gears already).
I think that if even 25% subset of ES4 was uniformly implemented in
all browsers in 10 years, web developers would be vastly further
along than if the 100% of ES4 was implemented in half the browsers.
You're kidding, right? Ten years is far too long, and there's no
coherent 25% -- a lot of ES4 depends on the type system. Would you
cut that and try to stitch the remaining pieces back together? King
Solomon only offered to bisect a child to find the true mother.
Quartering was not a good idea even for that purpose. Anyway,
Microsoft is now the avowed anti-mother of ES4, so you are only going
to help mutilate or kill ES4 with this kind of bargaining.
To switch metaphors to something less biblical, gory, and humorless:
given the on-again/off-again flirtation with JS1.7 compatibility by
Microsoft in TG1, I would not be surprised if you got a little foot-
bumping under the table. But take it from me, they are teasing. ;-)
While unfortunate that such orthogonal issues could affect language
design, and perhaps stifle innovation, I would like to see what
will be best for the future of the web. Does anybody know if there is anything that can be done to increase
the likelood of full cross browser implementation of ES4? Does
anyone know the issues or parts of ES4 that are causing dissent? Is
it the impact of the size of the language (on security,
implementability, etc)? Apologies for my excessive pragmatism,
I don't think you are being pragmatic. I think you are making
yourself too much of a victim :-], seemingly giving all power to the
dominant player and hoping for some scraps from the table. Pragmatism
means using the tools you have and looking out for your own
interests, even if it is scary, or requires some risk in the short run.
For me, pragmatism means ES4 as a standard that any browser can
interoperably implement and deploy, with ScreamingMonkey for browsers
that don't like ES4.
The world can change. Before Firefox, there was no hope. Who knew in
2002 or 2003 that we would be having an exchange like this one,
within (my best prediction) a year or two of ES4 support rolling out,
possibly to the majority of browsers? To quote from a great movie:
Never give up, never surrender! ;-)
Brendan, Thank you for the thorough and even somewhat inspiring response, that certainly helps me (and hopefully others) to understand the situation better. I may a have few other questions later, but for now, Thank you! Kris
On Oct 30, 2007 2:38 PM, Brendan Eich <brendan at mozilla.org> wrote:
Experiments such as Google Cajagoogle-caja.googlecode.com/files/caja-spec-2007-10-11.pdfare interesting ( discussionwww.nabble.com/Initial-draft-Caja-design-docs---library-now-available-t4611010.htmlhere), and Mark Miller will (I hope) smite me mightily if I misspeak about it, but as far as I can tell, such systems create an incompatible subset of JS into which developers may "opt" -- not a successor standard for the ECMAScript language that is backward compatible. Such a subset could be a very good thing, don't get me wrong. But it does not fall neatly under TG1's charter, because it's not backward-compatible, and profiled standards are considered harmful.
Hi Brendan,
Your summary may well be accurate. I'm just confused about a few points of terminology I hope you might clarify:
Caja is approximately a subset of ES3, much as JSON is a subset of ES3, and ES3 is approximately a subset of the ES4 proposal. ADsafe is also approximately a superset of JSON and a subset of ES3. We have yet to understand well (or decide) the degree to which ADsafe is a subset of Caja.
AFAIK, the only subset relationships here with unqualified compatibility are JSON < ES3 and JSON < proposed ES4. All the others have hazards that programmers need to understand in order to make use of the subset relationship. In this sense, the situation is analogous to C being approximately a subset of C++: When writing a correct C program, if you know what hazards to avoid, it isn't much harder to write it (without ifdefs) so that it's also a correct C++ program.
Although many may prefer C to C++, no one would propose C as a successor to C++. Nevertheless, it's valuable to both communities to maintain this almost-compatible-subset property between the languages. Likewise, it would make no sense to propose Caja as a successor to ES3.
So, depending on what you mean, I might argue with your phrase "incompatible subset". We are seeking to create, as close as we possibly can, a compatible subset. If you see a way in which we could be more compatible while still meeting our other goals, please let us know. Thanks.
Also, could you explain the phrase "profiled standards"? Thanks.
Anyway, it's early days for Caja and other such systems. If TG1 continues to function, it should definitely harvest good ideas from it, and stand on shoulders, not toes.
Thank you. I will read the ES4 proposal carefully and let you know what shoulder and toe issues I find.
We've pressed Doug Crockford on this point and heard nothing in the way of concrete proposals, save for a small one I championed at the last face-to-face meeting (a better-isolated String.prototype.evaluate() taking a scope object). But that went nowhere for lack of effort -- I half expect it to turn up in "Microsoft's vision for ECMAScript", which would make a fork in the standard. I'll still try to rescue it for ES4, but it's just a small isolation device, good to have, but not nearly enough for "Security" with a capital S.
I would like to hear more about this. A safe eval primitive that provides good isolation could actually be a very powerful lever for expressive security. Chapter 10 of erights.org/talks/thesis tries to explain
some of the relevant issues. Unfortunately, this is the most confusing and badly written chapter of that document, and badly needs a rewrite. If you do wade into it and find it confusing, please do not hesitate to ask me to clarify.
On Oct 30, 2007, at 4:04 PM, Mark Miller wrote:
AFAIK, the only subset relationships here with unqualified
compatibility are JSON < ES3 and JSON < proposed ES4. All the
others have hazards that programmers need to understand in order to
make use of the subset relationship. In this sense, the situation
is analogous to C being approximately a subset of C++: When writing
a correct C program, if you know what hazards to avoid, it isn't
much harder to write it (without ifdefs) so that it's also a
correct C++ program.
Someone just submitted a patch to old C code in Mozilla, to a header
file. All void f(); prototypes became void f(void); for C++ to be
happy. This avoided warnings, so it was not strictly required, at
least not by the compilers we use.
ES4 does not require, or even warn in favor of, any such syntactic
changes to existing ES3 code.
Although many may prefer C to C++, no one would propose C as a
successor to C++. Nevertheless, it's valuable to both communities
to maintain this almost-compatible-subset property between the
languages. Likewise, it would make no sense to propose Caja as a
successor to ES3.
Sure, but my thought was that a Caja-like language supported by
browsers might be successful enough that it should be considered for
standardization. For that to happen (I think), the objections to
profiled standards would have to be overcome.
So, depending on what you mean, I might argue with your phrase
"incompatible subset". We are seeking to create, as close as we
possibly can, a compatible subset. If you see a way in which we
could be more compatible while still meeting our other goals,
please let us know. Thanks.
I thought I saw something, but I just reread the Caja paper and don't
see it. Sorry about the false alarm -- it's a proper subset (and well
done too). Question about it: do you allow the alternative way people
create prototypes for constructor functions? Instead of
function F(a...){...} F.prototype.mname = /method or function/; F.prototype.pname = /expr with no F/; ... F.sname = /function or expr with no F/;
the following is popular:
function F(a...){...} F.prototype = { mname: function (a,b,c) {...}, pname: /expr with no F/, ... }; F.sname = /function or expr with no F/;
Also, could you explain the phrase "profiled standards"? Thanks.
Standards with a menu of profiles, usually progressively subsetted,
for implementations to choose from. One example: MPEG-4 has profiles
(and levels, to support different qualities of encoding that can be
decoded several ways, IIUC):
ECMAScript has a compact profile:
www.ecma-international.org/publications/standards/Ecma-327.htm
As the overview for ES4 notes, the Web has not been kind to the
compact profile. Mobile browser vendors found that, outside of walled-
garden content, they had to implement the full ES3 spec.
It could be that profiles make sense "next time", more than they
have. It might be a historical accident that ES3 became so
widespread. Still, people on TG1 who have expressed an opinion about
profiled standards also worry about the complexity, the size of the
testing problem in ensuring that the profiles are in a subset
relation, the specs don't contradict one another, and implementations
work together. I remember PHIGS and PEX (which makes me think of X
Windows, and now I'm sad).
Anyway, it's early days for Caja and other such systems. If TG1
continues to function, it should definitely harvest good ideas from
it, and stand on shoulders, not toes.Thank you. I will read the ES4 proposal carefully and let you know
what shoulder and toe issues I find.
That's great, thanks.
I would like to hear more about this. A safe eval primitive that
provides good isolation could actually be a very powerful lever for
expressive security.
A sketch in ES3:
String.prototype.evaluate = function (scope) {
/* eval this in scope and only scope -- no other scope chain
contents! */
};
"a + b * c".evaluate({a: 2, b: 5, c: 8}) => 42
For ultimate compatibility and integrity, it might be better to
provide this only as a fixed static method (can't be replaced or
overridden due to finality) of string:
string.evaluate(someStringLikeThing, theScoleScopeObject);
On Oct 31, 2007, at 9:38 AM, Brendan Eich wrote:
string.evaluate(someStringLikeThing, theScoleScopeObject);
Heh, theSoleScopeObject of course.
String.prototype.evaluate = function (scope) { /* eval this in scope and only scope -- no other scope chain contents! */ };
To me this like an extremely useful feature for security. If future browsers had the combination of some ability to make cross-site requests (JSONRequest or cross site XMLHttpRequest), and this sandboxed eval, with the getters and setters of ES4, developers can create safe sandboxes with host object wrappers with fine grained access control to enable cross site scripts to be loaded and executed with controlled limited ability to interact with environments. I think if we had these capabilities, the most gaping hole in browser security could be effectively dealt with. One thing could make this a little smoother would be a constructor for a global object, with it's own set of global values, Object, Array, etc. for the sandboxed code to mutilate. Nice, but I don't think necessary. Perhaps, I am missing something, and I don't know for sure how to capitalize the s in security, but this seems a way more valuable asset to security than constraints provided by fixtures and intrinsics. Kris
On Oct 31, 2007, at 9:55 AM, Kris Zyp wrote:
, and this sandboxed eval, with the getters and setters of ES4,
developers can create safe sandboxes with host object wrappers with
fine grained access control to enable cross site scripts to be
loaded and executed with controlled limited ability to interact
with environments. I think if we had these capabilities, the most
gaping hole in browser security could be effectively dealt with.
There are lots of exploits. Gaping holes that careful JS coders can
close, with the right tools, should be closed -- first the right
tools are needed as you note. But defense in depth plus fallible
human nature mean that no one is ever careful enough. The crackers
find really subtle holes. Security is never "done". So while I am in
favor of something like Doug's proposal, I'm not so confident as you
are.
One thing could make this a little smoother would be a constructor
for a global object, with it's own set of global values, Object,
Array, etc. for the sandboxed code to mutilate. Nice, but I don't
think necessary.
This is exactly the path we went down. Obviously my a + b * c == 42
example is a useless toy. Real uses of eval like this will want to
evaluate complex object graphs, possibly even containing functions.
It's a sandbox, right? Should be safe. Not so fast:
-
Information can flow out of the sandbox as well as into it from the
evaluated string. What result types should be allowed? If dynamic
objects, see below. -
From GreaseMonkey experience, the trusted caller of evaluate often
wants to add new API functions and objects to the sandbox. This
cannot be done safely in ES3. Among other problems are the mutable
prototypes, and Function.prototype.call/.apply which fixtures do
address. -
This kind of sandbox is a leaky reference monitor in general. There
is no mandatory access control specified for all control flows.
Implicit flows[*] are unmonitored. We have experience going back to
Netscape 4 (and earlier) that such a system is "advisory" -- people
may use it, or not; they may use it in one place and not in another;
they may use it but it's easy to leak information across the sandbox
object reference, and out from the return value.
Some proposals have insisted on primitive types only as the result.
That's insufficient, and judging from real web apps and add-ons such
as GM, crippling.
Perhaps, I am missing something, and I don't know for sure how to
capitalize the s in security, but this seems a way more valuable
asset to security than constraints provided by fixtures and
intrinsics.
Please don't set up a false dilemma.
As noted above, without fixtures and other mutability controls
missing from ES3, you can't safely inject added APIs into the
sandbox. You can't even trust the sandbox object after the evaluate,
in the sense that even getting a property from an object in it might
trigger a getter, with unexpected results. The trust label for the
getter's code should be other than the trust label of evaluate's
caller, of course, and perhaps there is a reference monitor comparing
those labels somehow.
But now the mission creep has turned into a whole new, extremely
"researchy", mission, until ES4 specifies mandatory access control
(MAC) and even non-interference: secure information flow: public and
secret inputs to a program only mix in secret outputs, never in
public outputs.
Security is never simple, and from our experience in Mozilla, it
actually hurts to be simplistic about things like an eval sandbox.
Nevertheless! I'm in favor of something like Doug's proposal, but it
needs a vigilant detailing and critical thinking about the issues you
raise, and others. These issues are not peripheral or minor:
- populating the sandbox with standard objects,
- populating it with custom objects,
- explicit result type restrictions,
- sandbox side effect hazards, including code (getters on objects in
the sandbox, etc.) - (from the last point) mutation controls in general -- new in ES4,
not in ES3 - real end-to-end MAC for implicit flows, information security.
/be
[*] www.informatik.uni-trier.de/~ley/db/journals/cacm cacm19.html (ACM members: portal.acm.org/citation.cfm? id=360056 -- anyone know of a free version?)
On Oct 31, 2007 12:21 PM, Brendan Eich <brendan at mozilla.org> wrote:
One thing could make this a little smoother would be a constructor for a global object, with it's own set of global values, Object, Array, etc. for the sandboxed code to mutilate. Nice, but I don't think necessary.
This is exactly the path we went down. Obviously my a + b * c == 42 example is a useless toy. Real uses of eval like this will want to evaluate complex object graphs, possibly even containing functions. It's a sandbox, right? Should be safe. Not so fast:
I just want to underscore that last line.
Python has an eval() function that accepts an optional "globals" argument. For years Python had with a restricted-execution module (rexec) built around this feature. It was in the Python standard library. For years they plugged holes as they were discovered. At last they gave up. rexec was removed from the language. I know of no other Python feature of that size and importance that has ever been flat-out removed. It was simply impossible to maintain. The feeling was that there were always more holes remaining to be discovered and exploited, and that the system was fundamentally too fragile to afford dependable protection. Nobody volunteered for the hard and endless work of maintaining it. There are Python solutions for sandboxing today, but this particular approach failed.
I think static analysis is a more promising approach. I also think ES4 has important stuff to contribute other than sandboxing.
On Oct 31, 2007, at 10:21 AM, Brendan Eich wrote:
One thing could make this a little smoother would be a constructor for a global object, with it's own set of global values, Object, Array, etc. for the sandboxed code to mutilate. Nice, but I don't think necessary.
This is exactly the path we went down.
See doku.php? id=discussion:resurrected_eval#resolved_issues.
Great to hear this important issue is being thoroughly discussed and examined. Thanks, Kris ----- Original Message ---
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?
---------- Forwarded message ---------- From: Walter Dnes <waltdnes at waltdnes.org>
Date: Oct 27, 2007 3:44 AM Subject: Re: [TLUG]: ECMAScript ("Javascript") Version 4 - FALSE ALARM To: tlug at ss.org
On Mon, Oct 22, 2007 at 04:04:52PM -0400, Scott Elcomb wrote
Not so fast. See the note on Slashdot Firehose at slashdot.org/firehose.pl?op=view&id=350409
Since it's not too long, I'll quote it in its entirety...
-- Walter Dnes <waltdnes at waltdnes.org> 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: gtalug.org TLUG requests: Linux topics, No HTML, wrap text below 80 columns How to UNSUBSCRIBE: gtalug.org/wiki/Mailing_lists
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 at waltdnes.org> Date: Oct 27, 2007 3:44 AM Subject: Re: [TLUG]: ECMAScript ("Javascript") Version 4 - FALSE ALARM To: tlug at ss.org 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 at waltdnes.org> 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/