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: Implementor Question
Brendan Eich wrote: But again, two engines don't cut it, for footprint and memory reasons. And two engines are intentionally unnecessary by the design of ES4. (Catching up on this thread...) An additional technical aspect of the language, for newcomers who may not have noticed it: It is also quite intentionally unnecessary in the ES4 design to use anything like an AOT-compiler, static typechecker, or fancy early-binding toolchain. It's designed to correctly work with last-minute checking in a lazy, lightweight, dynamic implementation. This was a strong technical requirement made by several committee members during 2006 (Opera and Microsoft in particular, iirc), and the committee has respected and pursued this goal. Nearly a dozen alternative semantics were proposed and hashed out by our visiting experts in type theory, in order to overcome member dissatisfaction with adopting disjoint AS3-like tilde and bang modes with (from what I understand) somewhat differing semantics. -Graydon ___ 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: Number handling
On Oct 30, 2007, at 12:55 PM, Yehuda Katz wrote:
After playing with the ES4 RI yesterday, my biggest concern comes
from the handling of various number types as compared to other types:
* Literal numbers become ints, rather than Numbers. While ES4 is
still compatible with ES3 via some very strange use of the
constructor property, doing something like: var x:Number; x = 7;
throws an error.
As noted, an RI bug (apologies again). The ES4 proposal calls for
interconversion among the types in AnyNumber.
* ints are coercive by default. So function foo(x:int) { return
x }; foo(null) returns 0, while function foo(x:Number) { return
x }; foo(null) returns null. In effect function foo(x:int) { return
x } is identical to function foo(x:*) { return new int(x) }
More RI bugs. See http://bugs.ecmascript.org/ticket/113.
* This is the same for all primitives like double.
When fixed (some of the problem has been fixed already), only for all
members of AnyNumber. Current RI:
$ make repl
perl bin/repl-with-readline.pl
var i:int = 3.14
var j:double = 7
var k:int = moo
[locn] builtins/Error.es:86:55-86.55
[stack] [init k()]
**ERROR** EvalError: uncaught exception: TypeError: incompatible
types w/o conversion: val=moo type=[ns public '__ES4__']::string
wanted=[ns public '__ES4__']::int (near builtins/Error.es:86:55-86.55)
var l:double = oink
[stack] [init k() | init l()]
**ERROR** EvalError: uncaught exception: TypeError: incompatible
types w/o conversion: val=oink type=[ns public '__ES4__']::string
wanted=[ns public '__ES4__']::double (near builtins/Error.es:
86:55-86.55)
Of course, it's possible that some of this is just a failing in the
reference implementation, but looking through the available
materials leads me to believe that it's not *all* RI-related.
It is all RI-related, sorry again. The proposals and especially the
overview are clearer about interconversion only among AnyNumber
members. And ticket 113 is there to remind us.
/be
___
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: Es4-discuss Digest, Vol 8, Issue 44
Doug, Yes, I think the time has come to table the ES3+ materials. It has been discussed on and off since April. Do you have something that describes this proposal in a material way? How can people evaluate ES4 vs ES3+ if ES3+ is unknown and unspecified? Michael Yehuda Katz wrote: Doug, What specifically would you do in ES3+ to improve this situation? -- Yehuda On 10/30/07, Douglas Crockford [EMAIL PROTECTED] wrote: Brenden is also correct:If the working group voted and the current proposal won - it is better to have a stronger, more secure language. Sure they can argue it is bloated, but SO WHAT? The proposal is not a more secure language. It does nothing to address ECMAScript's biggestdesign flaw: the insecurity caused its dependence on a global object. XSS attacks are a direct consequence of this flaw. By making the language more complex, this problem becomes even harder to reason about and fix. I have been bringing this up since my first day in the working group. This is not a concern that is being sprung at the last minute. The working group hasn't voted. The proposal has not won. We have agreed to disagree, developing two competing proposals in the same working group. I am pursuing with Microsoft a counter proposal for a simpler, reliable remedy to real problems. My position isn't that _javascript_ doesn't need fixing. I think we need to be more selective in how we fix it. Bloat, in my view, is not good design. ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss -- Yehuda Katz Web Developer | Procore Technologies (ph)718.877.1325 ___ 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
