If I was not clear before, I would like to thank you for the contribution. I love javascript and look forward to the future.
This does not mean I agree with everything being put in, but that may be more a commnet on my understanding rather than anything about the lanaguage. However, Doug did strike a chord when he said "the ghost of Netscape" Thanks again for your patience On 10/29/2007, "Thomas Reilly" <[EMAIL PROTECTED]> wrote: > >I think I can safely make the "public statement" that if Adobe could >warp space time we would have added more to AS3. As it was we needed to >ship something and we shipped the best language/implementation we could >at the time. Since then we've been working hard to make all our >technologies better as evidenced by our ongoing participation in TG1 and >contributions to Tamarin. > >What would Adobe and Mozilla possibly have to make a "deal" concerning? >Its probably the case that the head decision makers of Mozilla and the >head decision makers at Adobe have never met each other, much less made >a "deal". > >-----Original Message----- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] On Behalf Of Ric Johnson >Sent: Monday, October 29, 2007 1:36 PM >To: Thomas Reilly; Mark Miller; Dave Herman >Cc: [email protected] >Subject: RE: [TLUG]: ECMAScript ("Javascript") Version 4 - FALSE ALARM > >I think the MAIN problem is not technical, but rather political: > >When I went to the Ajax Expereince, several people commented that >1) There was a 'deal' between Adobe and Mozilla >2) There was not consensus on the new features, but they are being >pushed through anyway > >Can Abobe or Mozilla make a public statement to address these? > >Can anyone else comment HOW either party would benfit if this did >happen? > >also can you comment on why there was more than AS3 added to the new >language? > >Thank you! > >On 10/29/2007, "Thomas Reilly" <[EMAIL PROTECTED]> wrote: > >> >>There's seems to be enough sanity in this thread for me to dare to >>participate, good job everyone for avoiding going over the edge ;-) >> >>I just wanted to point out that a sizable subset of ES4 has receieved >>substantial usage via the Flash platform (what we call ActionScript3 >and >>Flex 2). This subset includes classes, interfaces, namespaces, >>packages, optional type checking, and getters and setters. Its >>important to note that AS3 is missing a non-trivial # of ES4 features >>but I think its fair to say it passes for a half way point between what > >>browsers support today and ES4 (if not closer to ES4). >> >>I'm not sure how you measure language success but its very clear that >>AS3/Flex2 has been successful in taking ActionScript to higher level of > >>"programming in the large" based on our customers successes. The >>overwhelming majority of developers prefer AS3 over AS1/2. Sure it >was >>only released into the market 16 months ago but Flash moves fast and >>over %90 of the world has the AS3 runtime and hundreds of thousands of >>developers have our various SDKs (I think that says something, although > >>it certainly doesn't prove anything). There was years of hard work, >>false starts and customer research leading up to that release of >course. >>I think the biggest colloquial point to make is that developers used to > >>static type checking could move comfortably to AS3 whereas before the >>language was too loose/dynamic. To make the point bluntly, Java >>developers hit the ground running with Flex. >> >>Will ES4 be as successful and will AS3 continue to be successful? Who >>knows, there's more at play than language features. We can say that >>real world feedback on AS3 has influenced what Adobe has pushed for in >>ES4 (parameterized types and multi-methods probably top the list). To >>look at JavaScript and ES4 side by side is probably a bit daunting but >>perhaps with AS3 in the middle it looks a little more sane. >> >>I would categorize ES4's evolution as diligent and glacial almost to a >>fault and think that with ActionScript3 and a working RI the spec and >>language will be adequately battle tested to keep it from being a >>failure. Of course we hope and believe it'll be much more. For better > >>or worse, Flash's distribution alone may be a bigger factor than the >>existance or non-existance of any particular language feature (of >>course I can't say when our platform will support ES4) but the proof's >>in pudding which in this case, I think, is what people put in their >HTML. >> >>That said a lot of the ES4 features are new to me and I'd love to hear >>concrete examples about how these features may not work well together >>in practice (as opposed to unsupported claims that this might be the >case). >>Language cohesiveness and implementation feasibility are equally >>relevant. >> >>One concern I have is that compilers will be slow for ES4, I realize >>compilation speed has been a factor in ES4's development (evidenced by >>the word "optional") but in practice I think a lot of folks will want >>those optional features. I don't think ES4 compilers can't be fast but > >>it takes time for compilers and their runtimes to mature and real time >>compilation is important for the web. I guess its a matter of having >>skilled resources on the problem, on one end of the pendulum javac >>seemed to take forever to get fast (remember jikes?) but the mono guys >>seemed to make short work of making mcs fast. Adobe's friends >>(http://www.mtasc.org/) have helped us in this area before, the skills >>are out there. I believe the skills/resources/motivation of the >>engineers has more to do with it than the language design but I can't >>back that belief up. >> >>Cheers and thanks for joining the party... >> >>Tommy >> >>-----Original Message----- >>From: [EMAIL PROTECTED] >>[mailto:[EMAIL PROTECTED] On Behalf Of Mark Miller >>Sent: Sunday, October 28, 2007 1:36 PM >>To: Dave Herman >>Cc: [email protected] >>Subject: Re: [TLUG]: ECMAScript ("Javascript") Version 4 - FALSE ALARM >> >>Thank you all for your feedback. Yes, I understand that my "bad smell" >>comment may have been less than helpful, though it hardly compares to >>some of the ad hominem comments in some of the responses. I will spend >>time reading the new overview paper; and I will post further feedback >>as I go. In exchange, I suggest that everyone here read Tony Hoare's >>Turing award lecture: <http://www.sli-institute.ac.uk/~bob/hoare.pdf>. >> >>In the meantime, I should explain what I'm reacting to. The first >>paragraph of the abstract of this new overview paper lists the >>following features [with connective text removed]: >> >># classes, interfaces, namespaces, packages, program units, optional >>type annotations, # optional static type checking and verification, >>structural types, duck typing, type definitions, # multimethods, >>parameterized types, getters and setters, meta-level methods, proper >>tail # calls, iterators, generators, type meta-objects, stack marks. >> >>Each of these may individually be good ideas. But languages can die of >>too many good ideas. >>Personally, I have my doubts about several of these (multimethods, duck > >>typing, proper tail calls). Several of the others are hard to get right > >>enough to do more harm than good, and few have (parameterized types, >>meta-level methods, iterators, generators, type meta-objects). >>The problem is the combination. Language features are rarely as >>orthogonal as one might hope. The interaction of even a small subset of > >>the features listed above can take decades of many failed attempts to >>work out well. >> >>But even if you have succeeded at integrating together more good ideas >>into a coherent language design than have many previous brilliant >>language designers, I have another concern: Standards bodies should not > >>do de-novo design. And they especially should not foist a design as a >>standard before there's a substantial track record of usage. How many >>large systems have already been written in this proposed ES4 design? E >>is a much smaller language than ES3, but it has evolved substantially >>in ways that surprised me, based on actual experience trying to use the > >>language. >> >> >> >>> [...] Brendan Eich >>> has repeatedly explained why a multiplicity of languages on the web >>> is >> >>> infeasible, e.g. at the URL Jeff Dyer linked to >>> (http://lambda-the-ultimate.org/node/2504). >> >>Are you referring to the post at >><http://lambda-the-ultimate.org/node/2504#comment-37607>? I'll wait for > >>a response before responding further to this point. >> >> >>> So obstructing the progress >>> of JS and consequently the open web in the name of preserving the >>> purity of a "platonic ideal" of JavaScript strikes me as either a >>> mistake of philosophical extremism, a convenient cover for conflicted > >>> business interests, or a combination of both. >> >>I have now learned ES3 itself quite well. I would not describe it as a >>platonic ideal of anything. I think ES3 is already too large, and it >>has many broken features (with, this-capture, pervasive mutability, >>lack of encapsulation, silent errors, for/in loop dangers, ...). >> >>The question we are discussing is which direction constitutes progress. >>Your response assumes your conclusion. Language vendors and standards >>committees, constrained by upwards compatibility, can only grow their >>language. Once a language gets too large, the best that we can hope for > >>is that they grow it slowly, incrementally, and conservatively. >> >>Java 1.5 came after Java 1.4, and it adds many features to Java 1.4. >>All the additional features added are each individually arguably good >>ideas, and recapitulate some of the elements of ES4's list. Does this >>imply that Java 1.5 represents progress over Java 1.4? In this case, I >>am quite familiar with the language both before and after. The process >>by which 1.5 evolved from 1.4 was much more experience driven and much >>more incremental than what I see here. Nevertheless, IMO, Java 1.5 is a > >>substantially worse language that Java 1.4. >> >>The "convenient cover for conflicted business interests" comment is the > >>sort of ad hominem nonsense that I hope we can avoid in further >>discussions. I have known both Doug Crockford and Allan Wirfs-Brock for > >>years before they joined Yahoo and Microsoft respectively. The >>suggestion that either would act with less than integrity in order to >>serve their corporate interests, I find ludicrous and offensive. >> >> >>> Finally, just to reiterate that the "it's a different language" >>> charge >> >>> glosses a critical aspect of the ES4 proposal, namely backwards >>> compatibility. ES4 is not a new language. It is, as the overview >>> describes, a significant evolution of ES3. >> >>C++ is approximately backwards compatible with C. With a small number >>of changes, it could have been precisely backwards compatible. Should >>we consider C++ to be merely a significant evolution of C? The >>additions that C++ makes to C are larger than the C language itself. >>>From the list from the ES4 abstract I quote above, I fear this may be >>true of ES4 vs ES3. >> >>-- >>Text by me above is hereby placed in the public domain >> >> Cheers, >> --MarkM >>_______________________________________________ >>Es4-discuss mailing list >>[email protected] >>https://mail.mozilla.org/listinfo/es4-discuss >>_______________________________________________ >>Es4-discuss mailing list >>[email protected] >>https://mail.mozilla.org/listinfo/es4-discuss >_______________________________________________ >Es4-discuss mailing list >[email protected] >https://mail.mozilla.org/listinfo/es4-discuss >_______________________________________________ >Es4-discuss mailing list >[email protected] >https://mail.mozilla.org/listinfo/es4-discuss _______________________________________________ Es4-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es4-discuss
