Re: Es4-discuss Digest, Vol 8, Issue 44
|
View:
New views
20 Messages
—
Rating Filter:
Alert me
|
| < Prev | 1 - 2 | Next > |
 |
|
|
|
Re: Es4-discuss Digest, Vol 8, Issue 44
by wycats
::
Rate this Message:
Doug,
I appreciated your comments at the end of the debate about people reading the white-paper. It was very courteous. That said, you did imply that the WG was split, by mentioning two members in support and two opposed.
Your comments to me after the presentation about back-compatibility were interesting, and I think any concerns about successful implementations of the back-compatibility (for instance, their implementations vis a vis the browsers' DOM implementations) are the most interesting part of the debate, and the part getting very little play. In effect, if ES4 implementations are successfully able to run ES3 code, the major concern that people have is fairly moot. So if there are factual reasons to suspect that ES4 implementations will fail to successfully support ES3, we should be talking about them, front and center.
Thanks again! -- Yehuda
On 10/30/07, Douglas Crockford
<douglas@...> wrote: > Doug Crockford made some statements about TG1 members and motives. -- Yehuda Katz Web Developer | Procore Technologies (ph) 718.877.1325 _______________________________________________ Es4-discuss mailing list Es4-discuss@... https://mail.mozilla.org/listinfo/es4-discuss |
|
|
Re: Es4-discuss Digest, Vol 8, Issue 44
by Robert Sayre-2
::
Rate this Message:
On 10/30/07, Douglas Crockford <douglas@...> wrote:
> > It has serious consequences that should be discussed. Well, it looks like there are two years of meeting minutes on the wiki. Do the details of these consequences appear anywhere in the minutes? If not, now is the time to get very specific, or get out of the way. -- Robert Sayre "I would have written a shorter letter, but I did not have the time." _______________________________________________ Es4-discuss mailing list Es4-discuss@... https://mail.mozilla.org/listinfo/es4-discuss |
|
|
Re: Es4-discuss Digest, Vol 8, Issue 44
by wycats
::
Rate this Message:
There's a difference between meeting minutes of the WG and the discussions that need to occur now in the development community. If ES4 is to succeed, a chunk of the development community needs to get behind it (and at least not be actively opposed to it). The insider baseball that's been occurring for the last two years is not particularly useful to the development community (no, I am not going back to read two years worth of minutes). It would be extremely helpful to get a coherent set of the concerns about ES4 (Doug's "consequences") so that interested parties outside of the WG can get a sense of what's going on technically.
I would specifically like to hear a realistic technical scenario where the implementation of ES4 produces serious complications in the open web. -- Yehuda
On 10/30/07, Robert Sayre <sayrer@...> wrote: On 10/30/07, Douglas Crockford <douglas@...> wrote: -- Yehuda Katz Web Developer | Procore Technologies (ph) 718.877.1325 _______________________________________________ Es4-discuss mailing list Es4-discuss@... https://mail.mozilla.org/listinfo/es4-discuss |
|
|
Re: Es4-discuss Digest, Vol 8, Issue 44
by Brendan Eich-2
::
Rate this Message:
On Oct 30, 2007, at 3:09 PM, Douglas Crockford wrote:
Yeah, you have said little on this list, but somewhat more at that panel at TAE Boston. I wasn't there, but multiple people who were (some on this list) attributed statements or words to you. Perhaps they misquoted. * The anonymous slashdot firehose post, which said "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." John Resig confirmed that the "concerned ECMAScript4 member" was you. * Kris Gray: "Crockford - Adobe, Mozilla, Yahoo and Microsoft. The first t[w]o support it, the later two oppose it." * Ric Johnson: "However, Doug did strike a chord when he said 'the ghost of Netscape'". Was Ric quoting you accurately, and if so, what did you mean? * Ric Johnson again: "There are A LOT of accusations of backroom deals being made" Whatever your exact words, what you did actually say raised the question of motive. People want to know the "why" when told the scary "what". Is there some back-room deal? Is there misconduct according to Ecma rules? And so on. Naming two (of four or six) companies working on ES4 is bound to cause speculation. But for the record, I have no reliable eyewitness quoting you as saying "motive". The word may never have crossed your lips. However, from the above, it seems clear that you did publicly call out Adobe and Mozilla as potentially misrepresenting ES4's status in Ecma, or the lack of consensus in TG1, or both. You apparently mentioned Opera too, but somehow left the distinct impression with multiple listeners that TG1 was split down the middle: Adobe and Mozilla vs. Microsoft and Yahoo!. These impressions immediately beg questions of motive. I think you can see that. /be _______________________________________________ Es4-discuss mailing list Es4-discuss@... https://mail.mozilla.org/listinfo/es4-discuss |
|
|
Re: Es4-discuss Digest, Vol 8, Issue 44
by Ric Johnson
::
Rate this Message:
Thank you all for keeping this thread alive, despite all the flamz,
I still am missing something. If someone could somehow prove that ES4 is flawed, do we have actually have a chance to fix it before it is burned over my childhood memories? How do we do that? Do I need to draw up a diagram comparing similar systems and show failure rates mathematically and then mail it to Al Gore? The problem with this debate is that I could argue both sides: I work as a .Net dev by day (mostly), and I promote Open Source in my free time. I use IE6, IE7, Firefox 2, Opera and Safari. Doug is correct: as a product manager, it is bad to add more features: it increases our risks with reduced ROI 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? I know! I know! What if I set up some sort of webpage (with Ajax!) that asks people to VOTE on the current spec? What would be the rules? 1) Validating identity to prevent double votes a) Classify employer and prove they did not force your vote 2) Do we need technical questions to verify understanding? 3) Should there be a line item veto? The idea is silly, but I wonder: who would honor it? I believe I heard quite a few declarations from Mozilla/ Adobe/ Opera here. I would like to hear a statement from Yahoo and Microsoft Doug: If 99% of technical users said they wanted ALL of the features, would you accept it? What is your threshold? One more thing: Can you make a statement to the effect that Yahoo does not have any 'deal' with Microsoft to hinder this process? I am sorry to point to you, but I really do not expect an answer from MS, considering the past. To put another face on it, it seems to me we are being unfair. If Opera put in a new feature in their browser, I assume most people would just believe it was their business. BUT if Microsoft decides to put a direct interpreter for .net in IE8 and CALL it JavaScript (or jScript), we would ALL cry foul. Is ES4 the new OOXML? In effect, some major players are getting together to force a standard that the others do not agree on. Then again, if Microsoft simply did not implement Javscript2, would the other vendors be happy? As a software engineer, I welcome most of the proposed changes. BUT, as a web developer, I feel I am forced to take Doug's view: even there was only ONE change between browsers, I would have to have special code to handle ALL cases. And the sad thing is that it WILL happen. I am willing to bet up to $100,000 - any takers? If you think the Ajax libraries are complex now, just wait. And if anyone is interested in the web, but did nothing about this now, we will all loose. SHAMELESS PLUG: We are all talking about the 'Open Web'; I feel so strongly about this, I donated OpenAjax.Org to the Alliance in order to promote the largest collaboration in history. I was _overjoyed_ when Microsoft AND Google joined. Now I realize they can not solve all the problems in the current context. If ANYONE can implement the OpenAjax hub with all libraries and a back end infrastructure to support developers, they have my permission to use OpenAjax.Com for FREE as part of OpenDomain. Any takers? Ric Johnson _______________________________________________ Es4-discuss mailing list Es4-discuss@... https://mail.mozilla.org/listinfo/es4-discuss |
|
|
Re: Es4-discuss Digest, Vol 8, Issue 44
by Ric Johnson
::
Rate this Message:
>* Ric Johnson: "However, Doug did strike a chord when he said 'the
>ghost of Netscape'". > >Was Ric quoting you accurately, and if so, what did you mean? I stand by this one. > >* Ric Johnson again: "There are A LOT of accusations of backroom >deals being made" However, it was NOT Doug that claimed any backroom deals. I have it written in my notes in several places, but do not know whom. I was sufficiently disturbed by the claim, I highlighted it to make sure I posted it. Can anyone claim this quote? I am not a professional reporter. I am just knurd who blogs about my passions. _______________________________________________ Es4-discuss mailing list Es4-discuss@... https://mail.mozilla.org/listinfo/es4-discuss |
|
|
Re: Es4-discuss Digest, Vol 8, Issue 44
by Brendan Eich-2
::
Rate this Message:
On Oct 30, 2007, at 3:59 PM, Yehuda Katz wrote:
> I would specifically like to hear a realistic technical scenario > where the implementation of ES4 produces serious complications in > the open web. Me too. Here's one analysis of how ES4 might break existing scripts: * New keywords and syntax hanging off them. Already addressed by not opening the __ES4__ namespace without opt-in version selection, e.g. by <script type="application/ecmascript;version=4">. See the versioning proposal at http://wiki.ecmascript.org/doku.php?id=proposals:versioning * Intentional incompatibilities. Today we knocked down three proposed such changes: http://bugs.ecmascript.org/ticket/241 http://bugs.ecmascript.org/ticket/250 http://bugs.ecmascript.org/ticket/251 * Unintended incompatibilities: these have to be addressed by testing the reference implementation, other implementations, and the spec- language (run by one's brain). This is an auditing procedure, QA. Often coverage is a problem, but we have had good experiences with fuzz-testing JS and intend to fuzz the RI. Hope this helps. /be _______________________________________________ Es4-discuss mailing list Es4-discuss@... https://mail.mozilla.org/listinfo/es4-discuss |
|
|
Re: Es4-discuss Digest, Vol 8, Issue 44
by Douglas Crockford
::
Rate this Message:
> 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 biggest design 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@... https://mail.mozilla.org/listinfo/es4-discuss |
|
|
Re: Es4-discuss Digest, Vol 8, Issue 44
by wycats
::
Rate this Message:
Doug,
What specifically would you do in ES3+ to improve this situation? -- Yehuda
On 10/30/07, Douglas Crockford <douglas@...> wrote: > Brenden is also correct: If the working group voted and -- Yehuda Katz Web Developer | Procore Technologies (ph) 718.877.1325 _______________________________________________ Es4-discuss mailing list Es4-discuss@... https://mail.mozilla.org/listinfo/es4-discuss |
|
|
Re: Es4-discuss Digest, Vol 8, Issue 44
by Michael O'Brien-4
::
Rate this Message:
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, _______________________________________________ Es4-discuss mailing list Es4-discuss@... https://mail.mozilla.org/listinfo/es4-discuss |
|
|
Re: Es4-discuss Digest, Vol 8, Issue 44
by Ric Johnson
::
Rate this Message:
Douglas,
Thank you! I asked for a clear message, and you gave me one! Don't we need the global object to be compatible? Can you point to a suggestion of what use mere mortals may do to influence the proposals? (Other than this on this list) We may all agree that 'bloat' is bad. We might not all say that ES4 is bloated. Do you want to use EcmaScript.Net as a place for your counter proposal (yet another OpenDomain - when I am passionate about an idea, I go all the way) Politics is the art of compromise: let us DIFF your proposal with ES4 and negotiate adding at least half the new features. Can you agree to that? Will Microsoft put up a bond they will deliver the same on a fixed date? What would be in that pool of features you WOULD accept? What would be the features Mozilla would accept dropping? Thank you for your reply, but I see we missed one important question: Can you please make a statement to the effect that, to your knowledge Yahoo and Microsoft do not have a 'deal' to impede Javascript2 based on financial terms? Thanks again Ric On 10/31/2007, "Douglas Crockford" <douglas@...> 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 biggest design 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@... >https://mail.mozilla.org/listinfo/es4-discuss Es4-discuss mailing list Es4-discuss@... https://mail.mozilla.org/listinfo/es4-discuss |
|
|
Re: Es4-discuss Digest, Vol 8, Issue 44
by Ric Johnson
::
Rate this Message:
On 10/31/2007, "Brendan Eich" <brendan@...> wrote:
>On Oct 30, 2007, at 3:59 PM, Yehuda Katz wrote: > >> I would specifically like to hear a realistic technical scenario >> where the implementation of ES4 produces serious complications in >> the open web. > >Me too. Here's one analysis of how ES4 might break existing scripts: > >* New keywords and syntax hanging off them. Already addressed by not >opening the __ES4__ namespace without opt-in version selection, e.g. >by <script type="application/ecmascript;version=4">. See the >versioning proposal at > >http://wiki.ecmascript.org/doku.php?id=proposals:versioning Brendan, I know that a version string may help us avoid incompatibilities, however I am also cognizant that this may serve the purpose of fragmenting the language. Look at what happened with VbScript. If we open the door to the version string, then Microsoft could add their own interpretation. I went through the pain of trying this with earlier JavaScript, and it never worked. It is not standard practice just to use the <script> tag 'plain' Ric _______________________________________________ Es4-discuss mailing list Es4-discuss@... https://mail.mozilla.org/listinfo/es4-discuss |
|
|
Re: Es4-discuss Digest, Vol 8, Issue 44
by Graydon Hoare-3
::
Rate this Message:
Douglas Crockford wrote:
> The proposal is not a more secure language. It does nothing to address ECMAScript's biggest design 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. It is true that you brought this up on the first day you came to the meetings. I said then, and I say again now, that I think we will actually be putting ES4 programmers in a better position wrt. safety than ES3 programmers. I wonder if the following two basic facts about the ES4 environment are clear. I've brought them up in the past but you usually dismiss them rather than saying why exactly they don't help: - fixtures in ES4 are early-bindable, non-overridable and (in cases of methods, types, classes, and other sorts of constants) non-replaceable. Intercepting control from a script that uses fixture names by mutating some part of the global object or prototypes is *not possible* in this design. - 'use namespace intrinsic' at the top of an ES3 file, then publishing it under the ES4 mime type, should be enough to accomplish this in many cases. All the multiname references that would previously hit the prototype chains and/or global.foo bindings become fixture references that XSS code cannot intercept. Even if they don't early-bind due to the absence of type annotations on slots, the multinames wait around until runtime and the fixtures *mask* the public names / prototype chains. Do they not help with some of the XSS scenarios? I imagine that they would, but have not nearly the depth of experience with XSS problems. -Graydon _______________________________________________ Es4-discuss mailing list Es4-discuss@... https://mail.mozilla.org/listinfo/es4-discuss |
|
|
Re: Es4-discuss Digest, Vol 8, Issue 44
by Brendan Eich-2
::
Rate this Message:
On Oct 30, 2007, at 5:03 PM, Douglas Crockford wrote:
Breaking the global object's mutability without opt-in from new code would break the web, so I'm surprised you are complaining about it. We've seen each other in TG1 meetings since July 2006, but no one including you has come up with a proposal to solve this problem compatibly, except by doing exactly what we have done: adding features in ES4 that developers can use to control visibility and mutation. The very features you oppose. ES4 provides const, fixed typename bindings, lexical scope (let), program units, and optional static type checking -- all of which *do* make ES4 code easier to analyze and instrument to enforce security properties.
ES4 is easier to reason about automatically. It's ironic that you invoke reason. Reasoning about code should not be done by humans only. Reason => logic => proof => proof system <=> type system, as I wrote at ajaxian.com in a comment recently. Your own words invoke the Curry-Howard correspondence, which requires a type system that supports static analysis, as well as unambiguous name binding. ES4 directly supports type checking and unambiguous name binding. Yet you seem to oppose all of ES4, especially the type system. That seems contradictory.
I don't think you suggested anything not recorded in some way there. If you mean that the item under "Yahoo!s position" about security promises motivating Yahoo! to entertain a new and incompatible language, that claim led nowhere. Mainly because unlike Yahoo!, browser vendors and web developers in general will not tolerate incompatibilities for "Security" -- but also (more important) because no one has a convincing solution for capital-S Security, other than adding features to ES3 that users can choose to control mutability and more conveniently and efficiently hide names. The eval discussion recorded in those minutes did lead to a decision by the group not to support a sandbox optional argument to eval. It also apparently led to that es3.1 String.prototype.eval idea, which you have not proposed for ES4. Too bad, but perhaps we'll be able to include it in anyway.
Who could argue with that? Since backward compatibility matters a lot to us, both to conserve working code so some of it can be gradually migrated to ES4, and to minimize code footprint for a common ES3/ES4 implementation on small devices (you've heard both of these points since the July 2006 meeting), we have indeed made some additive changes -- 'let' in addition to 'var', for example. We've even prototyped some of these in Firefox, to prove they didn't break anything (with opt-in keywords) and did not exact a big code footprint cost (they did not). This approach shows serious concern for compatibility, but in spite of it, we still get "break the web" FUD. Yet our "compatibility through opt-in additions" approach also makes it all too easy for someone arguing casually to accuse ES4 of being bloated. Catch-22. Taking the high road here does nothing but pat yourself on the back, and for work not visible to anyone except you and Microsoft (and some Ajax developers who got advance copies? That "ES4 will break the web" covert blog-spin campaign leaked, BTW). What good does it do to posture against bloat when your alternative proposal is hidden? I'm assuming there is an alternative proposal beyond some JScript documents. Look, I can take a different high road and mimic your arguing style: "Everyone familiar with the uses of closures in JS (for information hiding), something you've championed, who has run into closure-induced leaks and the larger object population costs of too many closures, will say your proposal is the opposite of bloated: stunted, insufficient, inefficient." Doesn't feel very good to be on the receiving end, does it? I didn't have to do any work to demonstrate my claims. I didn't even have to state problems precisely. It would be great if you could start, after over a year of involvement in TG1, and a while in es4-discuss, to communicate better. I'm glad to have as many words as you've sent today, even with the bloat remark, given how few specific and actionable words you've uttered to TG1. But the bloat accusations and superior-sounding claims to be selective need to stop. Everyone working on TG1 has been selective by some criteria. No one wants bloat. For us to get anywhere and avoid a fork, this kind of rhetoric has to stop. /be _______________________________________________ Es4-discuss mailing list Es4-discuss@... https://mail.mozilla.org/listinfo/es4-discuss |
|
|
Re: Es4-discuss Digest, Vol 8, Issue 44
by liorean
::
Rate this Message:
On 31/10/2007, Ric Johnson <Cedric@...> wrote:
> I still am missing something. If someone could somehow prove that ES4 is > flawed, do we have actually have a chance to fix it before it is burned > over my childhood memories? How do we do that? Do I need to draw up a > diagram comparing similar systems and show failure rates mathematically > and then mail it to Al Gore? There's features broken and there's language broken. I'd argue that the ES3 regex model is broken, that ES4 could and should fix it*, and that it won't hurt live code to do so but will help making regex in ES make sense. But on the other hand, ES3 has an unambiguous spec on this point, and Opera and Mozilla both seem to implement it as specified. Not fixing it right now would not really hurt the language, the language isn't broken by this feature being broken, except for making it harder to fix in the future (and possibly harder to add new features such as conditionals and lookbehinds). So language not broken, only less useful that it could be. I've yet to see any single argument with technical merit that the language is broken - I've seen broken features, mostly broken since ES3 that can't be fixed without breaking backwards compatibility, but nothing that breaks the language. The argument about ES4 additions size > ES3 size is the only one that seems to have any merit whatsoever, and that only in the way of being somewhat limiting on limited power devices such as mobile phones, where the compiler and vm size must be kept low. > To put another face on it, it seems to me we are being unfair. If Opera > put in a new feature in their browser, I assume most people would just > believe it was their business. BUT if Microsoft decides to put a direct > interpreter for .net in IE8 and CALL it JavaScript (or jScript), we > would ALL cry foul. Is ES4 the new OOXML? In effect, some major > players are getting together to force a standard that the others do not > agree on. Then again, if Microsoft simply did not implement Javscript2, > would the other vendors be happy? I think there'd be considerably more happiness if Microsoft provided a .NET based ECMAScript 4 compliant JScript version in IE8/9, whether based on JScript.NET or as a DLR runtime, than if they didn't provide an ECMAScript 4 engine at all by IE9. Even a COM/IDispatchEx version would be welcomed over not having an ECMAScript 4 engine at all. Sure, we have an effort to get a Tamarin version to hook into IE by COM/IDispatchEx. Who will distribute it (pretty sure Microsoft will not), can it reach enough users to matter? Can the distributor be trusted in corporate environments? Can it be compatible enough with legacy JScript to be used as an all-out replacement? Actually, I'd be more comfortable with an ECMAScript 4 engine based on .NET in IE than I would be with even a Microsoft backed Tamarin engine. I think the more interoperable implementations on different virtual machines the better, and ECMAScript 4 on .NET opens up for single language client and server side code, which I think many developers would like. (Most of them just don't want the single language to be JavaScript...) <offtopic> * I've had the argument before, the idea is simply summed up as: - Backreferences to capturing submatches that have not participated or that failed to match should fail. (In ES3 these succeed at matching the empty string.) - A capturing submatch should be reset only next time it participates in a match. (Instead of each time the containing group is repeated, as ES3 states.) - Backreferences to repeated submatches must always reference the value of the submatch last time it participated and matched. (IE/JScript uses the first match always, even if there are later matches. One example trick that doesn't work in ES3 but works in other regex implementations is this pattern used for conditionals: (?=(a)()|())\1?b(?:\2c|\3d) However, this fails in the ES3 model since all of \1, \2 and \3 will always match the empty string, instead of either both \1 and \2 failing or \3 failing. </offtopic> -- David "liorean" Andersson _______________________________________________ Es4-discuss mailing list Es4-discuss@... https://mail.mozilla.org/listinfo/es4-discuss |
|
|
Re: Es4-discuss Digest, Vol 8, Issue 44
by Brendan Eich-2
::
Rate this Message:
On Oct 30, 2007, at 5:36 PM, Ric Johnson wrote:
> On 10/31/2007, "Brendan Eich" <brendan@...> wrote: > >> http://wiki.ecmascript.org/doku.php?id=proposals:versioning > > Brendan, > > I know that a version string may help us avoid incompatibilities, > however > I am also cognizant that this may serve the purpose of fragmenting the > language. Look at what happened with VbScript. VBScript is full of lessons to avoid, but don't borrow trouble. The opt-in versioning for ES4 required only to use new keywords that were not reserved by ES3, or even if listed among ES3's future reserved keywords, were not reserved by IE. > If we open the door to > the version string, then Microsoft could add their own interpretation. The standard for ES4, as proposed at that versioning wiki page above, mandates what implementations must do when interpreting certain values of the version parameter named by RFC 4329. We really can't stop anyone from adding interpretations allowed by the RFC, unless we mandate that no other values are recognized unless codified by future Editions of ECMAScript. Would that address your concern? Even that kind of injunction is just words on paper. Microsoft or anyone else could ignore it. I mean, it's not as if JScript does not deviate from ES3 in obvious (and easily fixed) ways. > I went through the pain of trying this with earlier JavaScript, and it > never worked. It is not standard practice just to use the <script> > tag > 'plain' Sure, but you have now argued in a circle. If the script tag handler, upon seeing <script> (no type or version selected), invokes the ECMAScript implementation so that it understands new ES4 keywords, then the browser behaves incompatibly from today's browsers, and you've just broken the web. /be _______________________________________________ Es4-discuss mailing list Es4-discuss@... https://mail.mozilla.org/listinfo/es4-discuss |
|
|
Re: Es4-discuss Digest, Vol 8, Issue 44
by Ric Johnson
::
Rate this Message:
On 10/31/2007, "Brendan Eich" <brendan@...> wrote:
> >Sure, but you have now argued in a circle. If the script tag handler, >upon seeing <script> (no type or version selected), invokes the >ECMAScript implementation so that it understands new ES4 keywords, >then the browser behaves incompatibly from today's browsers, and >you've just broken the web. > I did not say I had a solution - just that, to me, adding a version would accomplish Doug's goal of 'just name it another language' This is what I KNOW: Mozilla/Opera/Adobe will get it right - or die. There will bugs in the implementation There will be different interpretations of the spec Time is the killer: ES4 needs to be out NOW to help Ajax compete with richer solutions, but has to be mature. Also, different vendors will have different schedules. Microsoft HAS contrived to obstruct similar proceedings in the past This is my opinion: Douglas is a nice guy, and really smart. I assume he is just passionate about JavaScript and is not participating in any conspiracy. I am a bit overwhelmed by the new spec, but I assume you know what you are doing. I do not work for Microsoft, but use their tools on a daily basis. It is in my interest to make a true 'Open Web' that includes them. We can not force them to implement any specific feature. Here my critical point: The technical discussion is MOOT. Microsoft plays this game way to well. The ONLY way to win is not to play: We need to make JavaScript2 so well that they have no choice but to copy it. We need EVERY other vendor on board to make it the same across the board and we need to release it all together on the same day with several working implementations and tutorials. We need OpenAjax to solve the problems before ES4 gets here and to provide a migration path, We need a master plan to achieve success against Microsoft's Stonewall defense: may I suggest a fianchetto of one of the bishops? Thanks for reading yet another lengthy post! (No I do not get paid by the word!) Ric P.S. Allen Wirfs-Brock from Microsoft did make an important post on my blog: http://openajax.com/blog/2007/10/29/god-bless-scoble/#comments _______________________________________________ Es4-discuss mailing list Es4-discuss@... https://mail.mozilla.org/listinfo/es4-discuss |
|
|
Re: Es4-discuss Digest, Vol 8, Issue 44
by Brendan Eich-2
::
Rate this Message:
On Oct 30, 2007, at 7:02 PM, Ric Johnson wrote:
> On 10/31/2007, "Brendan Eich" <brendan@...> wrote: > >> Sure, but you have now argued in a circle. If the script tag handler, >> upon seeing <script> (no type or version selected), invokes the >> ECMAScript implementation so that it understands new ES4 keywords, >> then the browser behaves incompatibly from today's browsers, and >> you've just broken the web. >> > > I did not say I had a solution - just that, to me, adding a version > would > accomplish Doug's goal of 'just name it another language' No, I'm sorry -- "another language" and a "new version of an existing language" are not the same thing. Or do you think ES3 is another language from ES2, which came before it? ES3 added new syntax not in ES2 (likewise ES2 to ES1). The world has been through JS evolution before. We'll get through another round. /be _______________________________________________ Es4-discuss mailing list Es4-discuss@... https://mail.mozilla.org/listinfo/es4-discuss |
|
|
Re: Es4-discuss Digest, Vol 8, Issue 44
by Neil Mix
::
Rate this Message:
On Oct 30, 2007, at 6:45 PM, Ric Johnson wrote: > Doug is correct: as a product manager, it is bad to add more > features: it > increases our risks with reduced ROI I sympathize with the concern behind this statement, but I would argue its analysis is incomplete on the following grounds: 1) Programming language design is very much different from consumer product design 2) The risks of adding feature always needs to be carefully balanced against the risk of *not* adding them Programming language design is historical in focus; stick to what has worked in the past, avoid things that have not. Innovation in language design is glacial compared to consumer product design. Languages that experiment in features without historical precedent do so at their own risk. By comparison, consumer product design seeks to specifically do things that have not been done before, and to avoid that which is well-known and "mundane". Brendan has mentioned this, but it's worth repeating: there is nothing "new" in the ES4 design. All of the features mentioned have appeared previously in well-known languages. The features have been fully researched, implemented and deployed in production systems, and withstood the test of time. I'm a product guy, not a PLT guy, so when I first started reading the ES4 proposals, I was just as worried about scope and feature creep. Having now spent a year or so absorbing the content and learning about this || much about PLT, it's sunk in that the proposal is not as big as it looks. (And this doesn't account for the fact that ES4 will be the most precise specification of ECMAScript yet, with a reference implementation no less!) When concerned about "bloat", there are specific problems one worries about: - backward compatibility: ES4 is backward compatible, choosing only to add to the language. If one is still scared by this, then one must consider, what number of features would be "safe"? If you have an API with 5 methods and you add 10 more, but you're worried about backward compatibility, what's the difference between 1 new method and 10 new methods? Why is the greater number of methods inherently a bigger risk to backward compatibility? - size of implementation: while I consider this a valid fear, I must also point out that several of the TG1 members are incredibly experienced in building JS interpreters for embedded systems. And those members are in favor of ES4. I, JS hacker, cannot claim knowledge enough to undermine their domain expertise. If other experts in the field were concerned about this, that would be another story. But thus far I have not seen any such objectors. - time to completion: again, I must defer to the expert language implementors of TG1. The only remaining claim to featuritis is that developers will find the new language unwieldy and hard to use. Valid concern, but how can any developer claim this without actually having tried the language? As I said above, you can find all these features in other well-known languages, and they've worked well. Historical precedent is on the side of ES4 on this one. On a more personal note: I've spent the past 3 years building a JS application from scratch; I've watched the application grow from programming-in-the-small to programming-in-the-large, growing along side a startup whose product has grown successful and accumulated users and features at a rapid pace. I used to scoff at strong data- typing -- who needs it when you've got good tests? These days I'm not laughing. *Every* feature in ES4 would be a great help in scaling this application out. If asked to name a "least useful feature," I wouldn't name any. The feature set feels right. So is the large feature set of ES4 risky? I don't believe so, but even more importantly, so what? We're drowning out here (though not all of us realize it). Without these features, JS apps are doomed to scale (of codebase) limitations that will fundamentally inhibit the growth of web-based applications. The "play it safe" strategy is penny-wise and pound-foolish. When I hear concerns that ES4 will "break the web," I can't help but think of how many times I've heard that the web is already broken! The risks of *not* adopting the ES4 surely must factor into this calculus, too. -Neil _______________________________________________ Es4-discuss mailing list Es4-discuss@... https://mail.mozilla.org/listinfo/es4-discuss |
| < Prev | 1 - 2 | Next > |
| Free embeddable forum powered by Nabble | Forum Help |
