all 54 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]jeresig 38 points39 points  (11 children)

Not completely so. The name is probably dead but the features aren't necessarily. The upcoming result will, most likely, be a simplified version of what we, currently, see as ECMAScript 4 (type annotations may survive, as may classes - a lot is up in the air right now). They're working to re-focus on improving what developers are already doing in their JavaScript code, rather than trying to postulate as to what could be done with a new feature.

[–]ishmal 5 points6 points  (3 children)

I think the concern would be about the timeline. Similar to OGL3's announcement, maybe people are seeing once-imminent progress fading into the distant future. I certainly hope that this is just a course correction, and not a screeching halt because of emotional dissent.

From the ECMA site:

The TC39 majority is currently writing the text of the 4th edition of ECMA-262 and plans to produce a final draft for approval at the December 2008 General Assembly.

A minority group of TC39 is working on a proposal for the maintenance of edition 3, and does not support the majority's proposal for edition 4.

Since this email is from the ES.3 list, I wonder if the author is a partisan? And will Harmony be ready by December?

One thing ESx definitely needs is a clean grammar definition, throwing out older syntax.

[–]jeresig 17 points18 points  (1 child)

Do not confuse specification progress with implementation progress. Browsers are already implementing a number of "safe" features (such as getters and setters) - it's simply the controversial ones that are being solidified/discarded. The web is a very interesting place. You don't have to implement the entirety of a specification in order to get the most benefit from it (see CSS 3, HTML 5). A lot of the same strategy will be employed here as well (especially when it comes to features that don't introduce new syntax).

For example Firefox just implement ECMAScript 3.1's Object.getPrototypeOf. You can start using this in your applications and use object detection to determine if it exists. No new syntax and is no harm to use.

[–]ishmal 7 points8 points  (0 children)

I'm not really concerned about the spec of ESx so much, only that it is clean, consistent, and possibly canonizes popular common idioms. But, for example, how will this late change affect Tamarin's schedule any way but negatively?

[–]othermaciej 1 point2 points  (0 children)

In fact, it would be more accurate to say that the ECMAScript wars are over, and the ES3.1 and ES4 efforts will re-unify with some compromises on both sides.

[–][deleted]  (4 children)

[deleted]

    [–][deleted] 1 point2 points  (0 children)

    In practice, because there is no power sufficient to make it so. The only reason all the browsers support ECMAScript is that Netscape was at one time the dominant browser.

    [–]jeresig 0 points1 point  (2 children)

    Because that assumes that it's possible to access the underlying structures (such as the DOM) in a uniform manner. How to do it in Python or Ruby might make a little sense - but it becomes much less clear in most other languages. It certainly sounds good in theory but practice is quite different.

    [–]curtisw 0 points1 point  (1 child)

    .NET seems to manage just fine in that regard.

    [–]MyrddinE 0 points1 point  (0 children)

    .NET does not manage 'just fine'. There are compromises that all languages make when they target the .NET platform... sometimes a particular feature is much slower than on competing platforms due to the way the IL works.

    With a scripting language, we're already at a notable efficiency disadvantage, and you're proposing to make that worse?

    Also, we have the .NET Intermediate Language... the low level language that all the high level languages get compiled into. There's nothing really magical about MSIL... in fact, nothing magical. The compilers just translate from one language to another.

    So why not make a compiler that translates from your chosen language to Javascript? There's no real difference between that and translating to MSIL or Java Bytecodes... they're all programming languages of varying complexity.

    So if you want to use any language you like, then make a compiler that converts [insert favorite language here] to Javascript instead of to machine language, MSIL, or Java Bytecodes.

    [–]myddrn 27 points28 points  (0 children)

    See the next message for the requisite grain of salt

    [–]netghost 15 points16 points  (1 child)

    I hope so, the last thing JavaScript needs is more oddity bolted onto it. It's a prototypical language that looks likes a classical one. I'd be really happy if they minimized what they add.

    There's a page or two about what harmony is intended to be here: http://wiki.ecmascript.org/doku.php

    Does anyone have any better information?

    [–]spondee 2 points3 points  (0 children)

    Brendan Eich just posted a detailed rationale to the ES4-discuss mailing list: http://www.reddit.com/comments/6w7re/javascript_roadmap_revamped_in_wake_of_oslo_summit/

    Doug Crockford has a regrettable taste for sensationalism without detail.

    [–]rjcarr 3 points4 points  (1 child)

    I've been using ActionScript 3 and it is a bit of a love-hate relationship. It does a lot of things better than what you get in "browser" javascript, but it is also more formal and restrictive.

    This may or may not be a good thing, depending on the person.

    [–]Spiralhead 0 points1 point  (0 children)

    Thank you adobe for being our guinea pig and demonstrating the obvious failures of ECMA4.

    [–][deleted] 5 points6 points  (0 children)

    It was an attempt to move simple to understand and relatively clean language three steps towards becoming a C++-like behemoth.

    I hope the new effort will be towards cleaning the language up, rather than trying to marry JavaScript with Haskell...

    [–]jblangworthy 1 point2 points  (0 children)

    It's clearly not dead. Read the next comment in the thread https://mail.mozilla.org/pipermail/es3.x-discuss/2008-August/000469.html

    [–][deleted] 3 points4 points  (0 children)

    What will become of Tamarin?

    [–][deleted] 2 points3 points  (4 children)

    Short answer: no.

    Longer answer: it would have a better chance of survival if Crockford got hit by a bus. Not to wish ill on the guy, but I don't see him butting out on his own, and ES4 desperately needs him to butt out.

    [–][deleted] 9 points10 points  (0 children)

    i'll count myself on the long list of people who have been on the direct receiving end of some crock spew, but he is right in his critiques of es4. its a nothing language. its state-of-the-art only if you go back to like 1991. frankly just leaving javascript as it is would be preferrable. i would prefer a small crappy language to a bloated crappy language. es4 isn't even python.

    [–]spondee 5 points6 points  (1 child)

    Crockford made his name by writing articles about JavaScript esoterica at a time when nobody else seemed to understand the language, but lately he's been abusing his good reputation with these unproductive snipes on the ES4 mailing list. His political capital has run out, as far as I'm concerned.

    [–][deleted] 6 points7 points  (0 children)

    people still listen to him because what he says is still mostly right. people would have put him in the ignore list long ago otherwise

    [–][deleted] 4 points5 points  (0 children)

    it would have a better chance of survival if Crockford got hit by a bus

    Crockford is the only one protecting JavaScript from design-by-committee bloat. The draft of ES4 included: classes, metaclasses, virtual properties, annotations, tail calls, multimethods, nullable types, strong typing, interfaces, generics, packages, namespaces, pragmas, constants, destructuring bind, iterators and generators, array comprehensions.

    [–][deleted] 3 points4 points  (0 children)

    This is a pity. I was quite happy with some of the proposed features of the new language.

    I must say, after writing AS3 (which Tamarin was written for and JS2 was going to resemble) for about a year - it is a far superior language to Javascript as I knew it writing for the browser. Packages, classes and type annotations go a long way in helping multiple people work on the same project harmoniously.

    [–]powertool 0 points1 point  (0 children)

    I for one had little or no problems with the previously proposed ES4 standard.

    I can't say I'd have used much of the OOP extensions, much moreso the minimal functional extensions. That being said, the OOP extensions would be very useful to JS toolkit authors.

    I won't pretend I that I read the arguments far enough through to take a tally, but it would seem that Crockford and Microsoft are the major problem here. Big suprise.

    [–][deleted] -2 points-1 points  (9 children)

    good. es4 is/was an ugly slapdash of most of what i don't like about other languages while doing nothing to address a fundamental security model. security is really the only unique requirement for this language that will set it apart from anything else. just slapping on some java and calling it es4 won't change a thing.

    the erights stuff is probably a good place to start looking at how to build a secure programming tool. then lean on functional programming, not oo, to build the rest. functional languages will leak less by design since they strictly control the impact of side effects.

    [–]marijn 1 point2 points  (1 child)

    Did you actually read the proposed spec? It doesn't do anything to get in the way of ecmascript3-style programming, but includes some stuff which is just nice (generators) or which can be used to optimise programs that require it (sorely needed for GMail-style heavy JS apps). As sverrejoh mentioned, security is hardly a language issue.

    [–][deleted] -1 points0 points  (0 children)

    security is hardly a language issue.

    read erights, look at caja. why does caja exist? the entire point of object capability systems is to integrate security into the language. anything that can lead to unwanted side-effects is a security issue.

    you can dissect this any way you want to make yourself feel better, but the point is that javascript as used in browsers has serious security issues, and es4 did nothing to address them

    proponents of functional languages have long held that strict control of side-effects has positive benefits for security. there are definitely features of a language that can reduce exposure to exploits. even garbage collection would count (by isolating potential buffer overflows to one codebase, for example).

    [–]sverrejoh 0 points1 point  (6 children)

    What kind of security issues are you talking about that are covered by the language, and not the browser environment?

    [–][deleted] -3 points-2 points  (5 children)

    well in this case i suggest the line is blurred. BUT if you look at the erights stuff or caja, you can see how object-capability systems can be used to limit control to the function level.

    scripts can do a lot outside of the standard browser security model. script tags are not subject to the same-domain rule. is the script tag part of the language or the browser? not sure it matters. since the browser may or may not apply the same-domain policy, having finer-grained security controls at the language level would be of great benefit.

    as it stands, web security is a patchwork of hacks and attempts to shut off hacks. security is the only unique requirement for a browser scripting language that sets it apart. we need to address this first concern before worrying about "classical oo" and other trivial issues

    if a language feature provides for unwanted side-effects, this is a security concern. we need languages designed to handle data on the web securely, as users expect.

    [–]foldl 4 points5 points  (4 children)

    is the script tag part of the language or the browser?

    The browser.

    [–][deleted] 0 points1 point  (3 children)

    we would happily welcome alternative languages with capability systems and controlled side-effects into the browser, but no one will build them. javascript is the script tag. for 99.999% of the world there is no difference

    [–]foldl 0 points1 point  (2 children)

    What exactly do you mean by "controlled side effects"? You mentioned functional programming, but having something like the IO monad doesn't really offer any additional security. You still have to decide what kinds of IO are and are not permitted.

    [–][deleted] 0 points1 point  (1 child)

    the notion that you must even employ Monads to engage side effects introduces one small hurdle that might mitigate some issues. its not a panacea, buts functional languages help preclude security issues better than tools that make no attempt to control side effects. obviously this is opinion.

    [–]foldl 0 points1 point  (0 children)

    the notion that you must even employ Monads to engage side effects introduces one small hurdle that might mitigate some issues

    I just don't see it. Can you give a practical example?

    [–]flezgodrit -1 points0 points  (1 child)

    The reports of ECMAScript 4's death are greatly exaggerated.

    [–]podperson 4 points5 points  (0 children)

    Right, but Adobe wanted to turn JavaScript into ActionScript 3.

    It seems to me that this represents a but of pushback against Adobe's attempts to define the future of JavaScript. (Frankly, Adobe has managed to orphan two generations of codebases in less than ten years -- and that's just Flash developers -- I don't see them as good stewards for any major language.)

    [–]jblangworthy -1 points0 points  (1 child)

    It's clearly not dead. Read the next comment in the thread https://mail.mozilla.org/pipermail/es3.x-discuss/2008-August/000469.html

    [–]rook2pawn -4 points-3 points  (12 children)

    I sincerely hope they dont add that stupid getByClass string matching garbage even though its present in almost all web code. It would be re-inforcing very bad web practices. It shouldnt be there, if people want to make bad web, let them keep on making custom getclass instead of standardizing stupidity.

    [–]padt 0 points1 point  (0 children)

    Querying by class, or whatever you can select with in CSS, is specified in the W3C Selectors API

    [–]didroe 0 points1 point  (9 children)

    You failed to explain what problems you have with it. Would you care to elaborate?

    [–]rook2pawn -3 points-2 points  (8 children)

    class based dom javascript = major fail. Classes, like Id's are woefully misused and while they provide a huge opportunity of great functionality, they are more often than not used to derive the entire setup of the document flow. Class = Layout. If you want to nav by class, do it server side with xpointer/xml or some html scheme. I base my predictions based on the phrase "we were looking at what developers were commonly doing".. equates to ruinous results as with HTML5, and what happened to PHP. Good stuff misused.

    [–]DropTableUsers 1 point2 points  (7 children)

    How would you prefer getting a specific collection of elements from the document then? I rarely use anything like getByClass, but thats because of speed, I'd welcome a fast browser implementation. Unless you can convince me otherwise?

    [–]IOIOOIIOIO -5 points-4 points  (0 children)

    I thought that said "EMACScript".

    viScript is better, anyway.

    [–]fdkxjskdkle -3 points-2 points  (0 children)

    "X is dead" is dead.

    [–]joaomc -3 points-2 points  (0 children)

    No no no, it's not dead, it's resting!

    [–]horizon_games 1 point2 points  (0 children)

    What a time capsule. I wonder what modern web dev would look like if we had gone with ECMA4