Re: [TLUG]: ECMAScript (Javascript) Version 4 - FALSE ALARM
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 [*] http://www.informatik.uni-trier.de/~ley/db/journals/cacm/ cacm19.html (ACM members: http://portal.acm.org/citation.cfm? id=360056 -- anyone know of a free version?) ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: Language Size (was Re: [TLUG]: ECMAScript (Javascript) Version 4 - FALSE ALARM)
If you come at this (like I first did) thinking of Packages as
containers, things can get confusing.
The secret to understanding is to start with namespaces, which are
central and critical to ES4 and backwards compatibility. I won't try to
describe namespaces here and will leave that to others far more
competent than me, but given namespaces, then packages are really just
a syntax shortcut for namespaces.
Now you could (as we did), overload the package name as the file name
of compiled program elements. However, this has restrictions and
complications. It starts burdening package names with meaning you
really don't want. Imports directives then become program unit
dependencies also.
Unit directives provide an independent naming for how various
components of a program will be bundled. Often these do not lie along
package or namespace boundaries. Units also provide dependency
information.
We use units directives to group program elements and name them as
external (pre-compiled) byte code files. In our case, we use the
UnitName as the name of the byte code file. We currently don't use the
unit URL. The compiler also has the option to merge all units and
dependent units into a single output file. Each unit file can thus have
code from one or more packages. Determining the units for an
application thus become a loading and network consideration.
So the unit proposal gives flexibility in deciding what program
elements should be loaded or transmitted as a unit. This is often
independent of and at cross purposes to package or namespace naming.
Michael
Our compiler uses the UnitName of the unit directive to name compiled
byte code files.
Brendan Eich wrote:
On Oct 31, 2007, at 3:46 AM, Maciej Stachowiak wrote:
I notice some seemingly duplicate
features that will perhaps become
more clear on closer reading of the spec.
For instance I see all three
of namespace, package and unit
productions in the grammar. With my
limited imagination it's hard to think of
how those could be three
interestingly different features.
What's the Sesame Street song? "... one of these things is not
like the other, one of these things just doesn't belong."
You are not alone in wondering about these three -- this has
come up at past TG1 meetings and we went ahead and implemented to get
experience. Michael O'Brien has a small-device implementation that he's
posted about here. He may have useful feedback.
This may help separate namespaces and units:
* A namespace is a qualifier on property name (a string in
general in ES1-3). It's a prefix to apply to unqualified identifiers
used by a block in which a 'use namespace N' pragma occurs at the top.
There are sane rules about ordering and ambiguity errors, covered
briefly in the overview. As you can see from the RI, namespaces are
used heavily. One benefit is to avoid incompatible name pollution of
unqualified identifiers in the standard objects and the global object.
* Aprogram
unitis an explicit reflection of the Program production's
semantics from ES1-3. When you see a program unit body's closing brace,
the steps in ES3 Chapter 10.2, plus ES4 steps like those, kick in. You
can nest units, and a server framework can expand them server side when
they are stated without bodies, but with locators that point to the
body in question. This preserves accurate source coordinates for errors
coming from nested units, and avoids downloading too many small files.
See the proposal for more detail.
These two are genuinely different, orthogonal, and useful
things, I think.
* Packages are built on namespaces, and unlike program units
they are open-ended. You can keep adding to a package (someone correct
me if I'm wrong), by writing
package acme.widgets {
...
}
several times in a row. As the overview notes, a package has two
namespaces, package-public and package-internal. There's an import
directive for pulling some or all of the public names of a package into
another scope.
/be
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Re: Language Size (was Re: [TLUG]: ECMAScript (Javascript) Version 4 - FALSE ALARM)
I made an attempt to size the ES3 and ES4 grammars by assigning an ES edition number to each production, sorting and counting both concrete and abstract forms. Below are the numbers I came up with. This are very rough, but having implemented parsers for ES3, AS3 and ES4, the ~2x increase in number of productions feels about right. ES3 ES4 --- --- Concrete 238 490 Type Exprs50 Classes Interfaces 23 Patterns 17 Abstract 3377 Methodology: 1/sort grammar productions and AST constructors by version 2/count concrete productions for each version 3/sort grammar productions by AST constructor 4/eliminate duplicate constructors 5/sort AST constructors by version 6/count AST constructors for each version The spreadsheet I used is posted in PDF and XLS formats here: http://ecmascript.org/es4/spec/grammar.pdf http://ecmascript.org/es4/spec/grammar.xls Jd On 10/31/07 3:46 AM, Maciej Stachowiak wrote: On Oct 30, 2007, at 1:23 PM, Maciej Stachowiak wrote: By the way, I think the discussions about language size could benefit from some quantitative data. I think the following comparisons would be interesting: 1) Size of the ES4 grammar relative to the ES3 grammar (say, by count of productions). Excluding the lexical grammar, the E4X syntax rules (which won't be a normative requirement) and regular expression syntax, I count: ECMA-262 3rd Edition: 74 grammar productions ECMAScript 4th edition draft: 197 grammar productions That's a more than 2x increase in surface syntax (2.66x to be more exact). While not completely unreasonable given all the new features, it seems a little high. Before embarking on this exercise I thought that 2x would be a reasonable level of core syntax increase. Part of this may be simply due to better factoring of the grammar, and due to capturing features like auto semicolon insertion, how if is disambiguated, noin contexts, etc in more detail. A lot of the genuinely new stuff just seems to be fallout from the type system. I notice some seemingly duplicate features that will perhaps become more clear on closer reading of the spec. For instance I see all three of namespace, package and unit productions in the grammar. With my limited imagination it's hard to think of how those could be three interestingly different features. 2) Size of the ES4 standard library by count of classes, methods and properties. I'll try to look at this soon, too. I think 4-5x would be about the size that would not raise any red flags for me, given how impoverished the ES3 standard library is. Does anyone else have other ideas for objective metrics of language size? Regards, Maciej ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: [TLUG]: ECMAScript (Javascript) Version 4 - FALSE ALARM
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 ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
RE: [TLUG]: ECMAScript (Javascript) Version 4 - FALSE ALARM
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. -Original Message- From: [EMAIL PROTECTED] on behalf of Neil Mix Sent: Mon 10/29/2007 3:06 PM To: Thomas Reilly Cc: Dave Herman; es4-discuss@mozilla.org; Ric Johnson Subject: Re: [TLUG]: ECMAScript (Javascript) Version 4 - FALSE ALARM What would Adobe and Mozilla possibly have to make a deal concerning? Its probably the case that the head decision makers of Mozilla and the head decision makers at Adobe have never met each other, much less made a deal. I'll play devil's advocate for a moment, and say Tamarin. It goes like this: someone claims Adobe and Mozilla are in cahoots, and that triggers the memory that Adobe open-sourced its AS engine to Mozilla, and then the wheels start turning. It's a lazy thought process, of course, because what's really gained? Did they team up to make sure the spec results in as little modification to Tamarin as possible? So they're teaming up out of laziness? I don't get it either, but you asked. ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: [TLUG]: ECMAScript (Javascript) Version 4 - FALSE ALARM
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 ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: [TLUG]: ECMAScript (Javascript) Version 4 - FALSE ALARM
Ric Johnson wrote: Please note that Microsoft HAS responded on my blog (with a reply from Brendon and myself) http://openajax.com/blog/ 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 ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: [TLUG]: ECMAScript (Javascript) Version 4 - FALSE ALARM
Please note that Microsoft HAS responded on my blog (with a reply from Brendon and myself) http://openajax.com/blog/ 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 On 10/30/2007, Chris Pine [EMAIL PROTECTED] wrote: 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: http://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 ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: [TLUG]: ECMAScript (Javascript) Version 4 - FALSE ALARM
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. ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: [TLUG]: ECMAScript (Javascript) Version 4 - FALSE ALARM
On Oct 30, 2007 10:13 AM, Chris Pine [EMAIL PROTECTED] 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. -- Text by me above is hereby placed in the public domain Cheers, --MarkM ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: [TLUG]: ECMAScript (Javascript) Version 4 - FALSE ALARM
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. 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. ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: [TLUG]: ECMAScript (Javascript) Version 4 - FALSE ALARM
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 -- working too hard to complete our Alpha ;-), but we have both a Java and C VM running the majority of the ES4 language already including most of the big items: classes, packages, units, type annotations and have been using it in some commercial products already. So we are field testing ES4 features as we go. Our all up target memory footprint is 250K for a minimal script. We are currently on target although we are missing some of the runtime library. We have a split compile / VM design so this does not include the compiler footprint. We have found that some of the ES4 features are essential for us to get such a small base footprint. The improved typing greatly enhances early binding and helps allows byte code sizes to be reduced. Now if you have large programs and large object counts -- memory will go up of course. I would STRONGLY urge that those who have concerns about the ES4 spec, engage and try writing some code with ES4. The features blend well and the end result is a nice expressive language that keeps the old ES3 dynamism but adds powerful constructs for safer, more scalable programs. It seems to wear well the more you use it. It also works well incrementally where you can start with ES3 and selectively employ ES4 features as you wish. Michael O'Brien 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. ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
RE: [TLUG]: ECMAScript (Javascript) Version 4 - FALSE ALARM
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. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark Miller Sent: Tuesday, October 30, 2007 10:49 AM To: Chris Pine Cc: zwetan; es4-discuss@mozilla.org Subject: Re: [TLUG]: ECMAScript (Javascript) Version 4 - FALSE ALARM On Oct 30, 2007 10:13 AM, Chris Pine [EMAIL PROTECTED] 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. -- Text by me above is hereby placed in the public domain Cheers, --MarkM ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: [TLUG]: ECMAScript (Javascript) Version 4 - FALSE ALARM
On Monday 29 October 2007 3:05 pm, Ric Johnson wrote: Who, besides Doug Crockford, would be among those several people? I believe some Dojo people were against the new ES4, and I did here two people sitting next to me reflect that (sorry I do not know who they were) Just to be *very* clear, the Dojo community is not monolithic. Opinions of ES4 inside Dojo span the entire gamut, from fully in favor to dead-set against. Dojo, as a project, has no official stance. Regards -- Alex Russell [EMAIL PROTECTED] A99F 8785 F491 D5FD 04D7 ACD9 4158 FFDF 2894 6876 [EMAIL PROTECTED] BE03 E88D EABB 2116 CC49 8259 CF78 E242 59C3 9723 pgpcpZx2yA2Mz.pgp Description: PGP signature ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: [TLUG]: ECMAScript (Javascript) Version 4 - FALSE ALARM
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 http://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 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. ³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? Jd /be ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: [TLUG]: ECMAScript (Javascript) Version 4 - FALSE ALARM
Thank you all for your feedback. Yes, I understand that my bad smell comment may have been less than helpful, though it hardly compares to some of the ad hominem comments in some of the responses. I will spend time reading the new overview paper; and I will post further feedback as I go. In exchange, I suggest that everyone here read Tony Hoare's Turing award lecture: http://www.sli-institute.ac.uk/~bob/hoare.pdf. In the meantime, I should explain what I'm reacting to. The first paragraph of the abstract of this new overview paper lists the following features [with connective text removed]: # classes, interfaces, namespaces, packages, program units, optional type annotations, # optional static type checking and verification, structural types, duck typing, type definitions, # multimethods, parameterized types, getters and setters, meta-level methods, proper tail # calls, iterators, generators, type meta-objects, stack marks. Each of these may individually be good ideas. But languages can die of too many good ideas. Personally, I have my doubts about several of these (multimethods, duck typing, proper tail calls). Several of the others are hard to get right enough to do more harm than good, and few have (parameterized types, meta-level methods, iterators, generators, type meta-objects). The problem is the combination. Language features are rarely as orthogonal as one might hope. The interaction of even a small subset of the features listed above can take decades of many failed attempts to work out well. But even if you have succeeded at integrating together more good ideas into a coherent language design than have many previous brilliant language designers, I have another concern: Standards bodies should not do de-novo design. And they especially should not foist a design as a standard before there's a substantial track record of usage. How many large systems have already been written in this proposed ES4 design? E is a much smaller language than ES3, but it has evolved substantially in ways that surprised me, based on actual experience trying to use the language. [...] Brendan Eich has repeatedly explained why a multiplicity of languages on the web is infeasible, e.g. at the URL Jeff Dyer linked to (http://lambda-the-ultimate.org/node/2504). Are you referring to the post at http://lambda-the-ultimate.org/node/2504#comment-37607? I'll wait for a response before responding further to this point. So obstructing the progress of JS and consequently the open web in the name of preserving the purity of a platonic ideal of JavaScript strikes me as either a mistake of philosophical extremism, a convenient cover for conflicted business interests, or a combination of both. I have now learned ES3 itself quite well. I would not describe it as a platonic ideal of anything. I think ES3 is already too large, and it has many broken features (with, this-capture, pervasive mutability, lack of encapsulation, silent errors, for/in loop dangers, ...). The question we are discussing is which direction constitutes progress. Your response assumes your conclusion. Language vendors and standards committees, constrained by upwards compatibility, can only grow their language. Once a language gets too large, the best that we can hope for is that they grow it slowly, incrementally, and conservatively. Java 1.5 came after Java 1.4, and it adds many features to Java 1.4. All the additional features added are each individually arguably good ideas, and recapitulate some of the elements of ES4's list. Does this imply that Java 1.5 represents progress over Java 1.4? In this case, I am quite familiar with the language both before and after. The process by which 1.5 evolved from 1.4 was much more experience driven and much more incremental than what I see here. Nevertheless, IMO, Java 1.5 is a substantially worse language that Java 1.4. The convenient cover for conflicted business interests comment is the sort of ad hominem nonsense that I hope we can avoid in further discussions. I have known both Doug Crockford and Allan Wirfs-Brock for years before they joined Yahoo and Microsoft respectively. The suggestion that either would act with less than integrity in order to serve their corporate interests, I find ludicrous and offensive. Finally, just to reiterate that the it's a different language charge glosses a critical aspect of the ES4 proposal, namely backwards compatibility. ES4 is not a new language. It is, as the overview describes, a significant evolution of ES3. C++ is approximately backwards compatible with C. With a small number of changes, it could have been precisely backwards compatible. Should we consider C++ to be merely a significant evolution of C? The additions that C++ makes to C are larger than the C language itself. From the list from the ES4 abstract I quote above, I fear this may be true of ES4 vs ES3. -- Text by me above is hereby placed in the public domain Cheers, --MarkM
Re: [TLUG]: ECMAScript (Javascript) Version 4 - FALSE ALARM
On 10/28/07, Mark Miller [EMAIL PROTECTED] 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. -- Robert Sayre I would have written a shorter letter, but I did not have the time. ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: [TLUG]: ECMAScript (Javascript) Version 4 - FALSE ALARM
On 29/10/2007, Robert Sayre [EMAIL PROTECTED] wrote: * Temper tantrums about the name. (there's really nothing to negotiate, aiui) I can understand wanting to change the name for the reason Steve Yegge mentions in How to Ignore Marketing and Become Irrelevant in Two Easy Steps - Both JavaScript and ECMAScript are horrible names. On the other hand they have a considerable mindshare and I think it would be more confusing if the name was changed to something entirely unknown. I don't buy the argument that ES4 shouldn't be named ECMAScript 4 or JavaScript 2 because it's too big a a change to it's predecessor however. ES4 has been developed specifically to be an update to ECMAScript 3/JavaScript 1.x. As long as ES4 doesn't throw away considerable parts of ES3 (which it doesn't) then I can't see how that point is valid. The size of the new language compared to the size of old language isn't important, what's important is the fact it's pretty much entirely additional features that were lacking in the predecessor or added orthogonal mechanisms that makes things possible in the engine that were not possible before. -- David liorean Andersson ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: [TLUG]: ECMAScript (Javascript) Version 4 - FALSE ALARM
On 10/27/07, Scott Elcomb [EMAIL PROTECTED] wrote: -- Forwarded message -- From: Walter Dnes [EMAIL PROTECTED] On Mon, Oct 22, 2007 at 04:04:52PM -0400, Scott Elcomb wrote Not so fast. See the note on Slashdot Firehose at http://slashdot.org/firehose.pl?op=viewid=350409 Since it's not too long, I'll quote it in its entirety... [...] 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. 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. -- Text by me above is hereby placed in the public domain Cheers, --MarkM ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: [TLUG]: ECMAScript (Javascript) Version 4 - FALSE ALARM
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. http://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. Jd On 10/27/07 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. 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 [EMAIL PROTECTED] Date: Oct 27, 2007 3:44 AM Subject: Re: [TLUG]: ECMAScript (Javascript) Version 4 - FALSE ALARM To: [EMAIL PROTECTED] 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=viewid=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 [EMAIL PROTECTED] 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 ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: [TLUG]: ECMAScript (Javascript) Version 4 - FALSE ALARM
On 10/27/07 10:17 AM, Mark Miller wrote: On 10/27/07, Scott Elcomb [EMAIL PROTECTED] wrote: -- Forwarded message -- From: Walter Dnes [EMAIL PROTECTED] On Mon, Oct 22, 2007 at 04:04:52PM -0400, Scott Elcomb wrote Not so fast. See the note on Slashdot Firehose at http://slashdot.org/firehose.pl?op=viewid=350409 Since it's not too long, I'll quote it in its entirety... [...] 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. 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: http://wiki.ecmascript.org/doku.php?id=meetings:meetings 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. Jd ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: [TLUG]: ECMAScript (Javascript) Version 4 - FALSE ALARM
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 http://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. * http://article.gmane.org/gmane.org.user-groups.linux.tolug/36420 Cc'ing Walt Dnes. -- Forwarded message -- From: Walter Dnes [EMAIL PROTECTED] Date: Oct 27, 2007 3:44 AM Subject: Re: [TLUG]: ECMAScript (Javascript) Version 4 - FALSE ALARM To: [EMAIL PROTECTED] 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=viewid=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
Re: [TLUG]: ECMAScript (Javascript) Version 4 - FALSE ALARM
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 (http://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. Dave ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: [TLUG]: ECMAScript (Javascript) Version 4 - FALSE ALARM
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: https://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. :-) /be ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: [TLUG]: ECMAScript (Javascript) Version 4 - FALSE ALARM
On 10/27/07, Brendan Eich [EMAIL PROTECTED] 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: https://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. -- Scott Elcomb http://www.psema4.com/ ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
