ECMAScript 6 looks promising

http://kishorelive.com/2011/11/22/ecmascript-6-looks-promising/

by karterk • 15 years ago

153 88 15 years ago

rglullis2• 15 years ago

Except for the inclusion of "let", it is looking like Python with braces.

karterk2• 15 years ago

Yes, and David actually mentioned openly in that talk that they try to borrow good ideas from other languages if possible! There are templates from PHP too :)

rglullis2• 15 years ago

Don't know much about PHP, but the templates also exist in Python.

wulczer2• 15 years ago

Let keyword: good. The function scoping of vars is gruesome.

Default arguments: good. Clearly useful and already used a lot with the if (foo === undefined) foo = 'default' pattern.

Non-strict destructuring: bad. It's neither destructuring-bind nor pattern matching... If I destructure a 3-list to 2 vars, I want it to fail, dammit!

Multi-line strings: good, obviously.

Templating: hello, PHP! I thought we already know better.

List comprehension: useful.

My humble opinion: it's hopeless. A mix of useful and terrible features means it'll still be made out of "the good parts" and the awful rest.

karterk2• 15 years ago

To me this spec itself is a step in the right direction. There has been no major work towards improving JavaScript in a long long time. I left out in my post the part about modules (which will hopefully solve all the crazy 3rd party JS issues), because I have no idea when they will actually get implemented by the browser vendors. But, I am hoping that this will continue to evolve in future, instead of getting stagnated.

DaNmarner• 15 years ago

I don't know much about PHP, what's wrong with it regarding templating?

wulczer2• 15 years ago

Automatic interpolation of variables into string literals is a bad idea IMHO.

Couple that with variable hoisting (function scope) and hilarity can ensue when variables defined further down a function influence the value of another variable that looks like it just contains a string literal.

nailer2• 15 years ago

I think it would be slightly more consistent to re-use the multi-line quite like Python does:

var foo = /* Hello there How are you? */;

But less typing is good too.

hsuresh• 15 years ago

I doubt. /* */ is already used for commenting.

SimHacker• 15 years ago

So does that string literal include the spaces between "/ * [space]" and "Hello", and "you?" and "[space] * /", or not?

By the fact that you included spaces in your example, does that imply it doesn't include the surrounding spaces in the string? Maybe your example implies that spaces are not included, but maybe they are or maybe they aren't, since comments don't require them, but usually have them and look ugly without them.

I think it's a bad idea to use C-style comments as multi line strings, because it's ambiguous and/or ugly because of the surrounding spaces. If the leading and trailing spaces are included in the string, then it looks "/ * [nospace] ugly [nospace] * /", and it drops the surrounding spaces like your example implies, then "/ * [nospace] what does it mean [space] * /" if you omit one or both spaces? Messy and ambiguous.

It looks like something the C++ committee would come up with when they ran out of punctuation characters, and decided to abuse existing syntax instead. Comment overloading, an extension of Generalized Overloading for C++2000: http://www2.research.att.com/~bs/whitespace98.pdf

[I can't format an example of what I mean literally and had to add extra spaces, because of hn's stupid formatting rule: "Text surrounded by asterisks is italicized, if the character after the first asterisk isn't whitespace."]

ataggart• 15 years ago

>If I destructure a 3-list to 2 vars, I want it to fail, dammit!

Why should that fail any more than:

    var a = foo[0];
    var b = foo[1];
    // rest of foo unused

Destructing is just another way to access into a list. There's no notion of completeness here, and there's nothing necessarily erroneous with not referring to all the elements. What would you do if you need just the first 5 elements of a 100-element long list?

That said, if they're going to include destructuring, it'd be nice if they also included a way to bind the tail.

masklinn17• 15 years ago

> What would you do if you need just the first 5 elements of a 100-element long list?

Depending on the language, either you don't or you use a "everything else" operator to an unused variable:

    a, b, *_ = list

You could even alter the syntax slightly to put a "Don't care" placeholder:

    a, b, * = list

same as above but does not require serializing the [2:] array slice.

philjackson3• 15 years ago

They are:

    var [ a, b, ...rest ] = foo

ajuc4• 15 years ago

> What would you do if you need just the first 5 elements of a 100-element long list?

I like Python solution there:

    list = [1,2,3,4,5,6,7,8,9,10]
    a,b,c = list[0:3]

Also when I do

    a,b,c = list[0:4]

I get "ValueError: too many values to unpack" as it should be - you can always catch the exception and ignore it, if your code really don't care.

masklinn17• 15 years ago

> It's neither destructuring-bind nor pattern matching... If I destructure a 3-list to 2 vars, I want it to fail, dammit!

Yeah I agree with that one completely: unless I tell you I don't care for it, you don't get to ignore it.

It's in line with JS's non-strict handling of arguments though (missing args are `undefined`, extra args are in the `arguments` object), which makes it hard to argue against)

> Templating: hello, PHP! I thought we already know better

Meh. Ruby also lets you do that, it's OK. String formatting is a good idea and interpolation is no worse than sprintf-style or C#-style.

firefoxman12• 15 years ago

I guess that's what happens when a language becomes this popular. All the immigrants from other languages start sticking their fingers in and trying to make JS the way they think it should be.

The main issue is that half of these features don't solve any real problem. They should look to libraries like underscore that add features and solve problems that JS currently doesn't. It's almost like they just want to eliminate libraries altogether and have everything work out of the box.

ajuc4• 15 years ago

Eliminating libraries has adventages - it eliminates dependency. When you have to integrate 2 projects using different basic libraries, it's painful.

In one of C++ programs I've worked on, we've had 4 different classes for string used (along with char* of course).

DanielRibeiro• 15 years ago

Nice to see many of CoffeeScript's constructs coming to ECMAScript.

Cushman3• 15 years ago

True-- but it's frustrating that there's so much resistance to the idea of making the syntax prettier and more concise, which is one of the primary benefits of CoffeeScript.

(Almost?) all of these features can be added to JavaScript with libraries-- that's exactly what CoffeeScript demonstrates. The only thing missing is a contemporary syntax.

vidarh3• 15 years ago

The syntax is one of the things that keeps me from using CoffeeScript.

boucher• 15 years ago

I think it will be really sad if we end up with a module system that's incompatible with CommonJS, which is the only such system that has gained any real traction.

starwed• 15 years ago

Do you have reason to think that's likely?

juliennakache• 15 years ago

The most interesting part to me is the "generator function", which basically allows for cooperative scheduling.

This would put an end to spaghetti callbacks when doing blocking I/O operations. Very similar to EM-Synchrony for EventMachine/Ruby and (I guess) Inline Callbacks in Twisted/Python.

This and the new module would be a blast for Node.JS !

wladimir• 15 years ago

and (I guess) Inline Callbacks in Twisted/Python

Python has had real generators (using the yield keyword) for a long time... See http://www.python.org/dev/peps/pep-0255/ .

bitanarch• 15 years ago

Python has been having coroutine based, cooperative scheduled I/O for a long time.. go read about gevent and eventlet.

barumrho• 15 years ago

But, how are we going to migrate? Compile down to the current version and serve two files? I feel like this migration process will take way too long.

lautis• 15 years ago

Either that or wait until last version of IE which doesn't support it has died. Might happen in time for HTML5 becoming W3C recommendation in 2022.

Bootvis• 15 years ago

For some web apps it will probably take long. But with all the developments in browser land there is often more then one reason to develop against the latest anyway. Hopefully this will motivate corporate IT to move faster also.

nkassis• 15 years ago

That's one good thing about using a feature like WebGL :)

By forcing my users to use the latest versions of Firefox and Chrome I get access to a lot of nice new functionality.

philjackson3• 15 years ago

That bears more than a passing resemblance to coffeescript. Great stuff.

jemeshsu• 15 years ago

CoffeeScript is popular and there is Dart. Instead of using another language and translate to JavaScript, what are the hindrances to improve JavaScript so that the "bad parts" are removed? Maybe a 'half-clean' break from existing javaScript? Sorry for my ignorance.

masklinn17• 15 years ago

There's a very high interia, as there are at least 5 major implementations still being developped (MSIE's Chakra, Mozilla's SpiderMonkey, Google's V8, Apple/Webkit's JavaScriptCore and Opera's Carakan).

Work has not stopped, but it's basically about cat-herding, and each player does his own additions. As an example, Mozilla has kept working on core Javascript with "internal" versions:

1.6 added Array Extras and String and Array generics (array extras have since then been adopted by everybody else) as well as E4X (literal XML syntax in JS) and a `for each` loop.

1.7 added generators and iterators, array comprehensions (listcomps), let definitions, statements and expressions and destructuring assignments

1.8 added a function shorthand (function (foo) { return bar; } => function (foo) bar), generator comprehensions (lazy listcomps) and two missing array extras (left and right folds)

1.8.1 and 1.8.5 mostly added ES5 and draft APIs (e.g. the Object.* stuff and the Proxy type)

tikhonj• 15 years ago

You can already remove a bunch of the bad parts via "use strict".

program2• 15 years ago

Using the ` (backquote) character for multiline strings isn't a wise choice (probably inherited from Go) cause it's difficult to reach that character on non-english keyboard layout. In the italian layout it's alt+\ or alt+9 on the Mac but you can't reach it using Windows; you need to press alt+96.

heisenmink• 15 years ago

I just press shift+´ to get `

benjoffe• 15 years ago

What other character would you suggest? At least multi line strings arent super common (nor essential) so extra difficulty isn't a major problem.

program2• 15 years ago

I don't think that there is the need for a new character. The problem here is that JS has automatic semicolon insertion. This:

  var a = "abc
   def";

generate a "unterminated string literal" syntax error cause a semicolon is inserted after abc. Why not using C/C++/ObjC syntax?

  var a = "a very "
   "very long string";

masklinn17• 15 years ago

> What other character would you suggest?

Fixing the language so newlines in strings are legal, Python-style triple quoting or some sort of string modifier prefix (similar to Python's rawstring modifier)

demallien• 15 years ago

Friends don't let friends use layouts other than QWERTY (glares at the AZERTY keyboard her employer gave her that was rapidly replaced with a QWERTY from home).

smosher4• 15 years ago

`let` is good but please, give me `let ... in` too:

    let callback = function(a, b) {
        // ...
    } in
    object.registerCallback(callback);

masklinn17• 15 years ago

I don't know what they've selected for ECMAScript 6, but the `let` keyword as introduced in Firefox 2 has 3 different forms:

* Let definitions are equivalent to `var` but block-scoped, so

    if (x > y) {
      let gamma = 12.7 + y;
      i = gamma * x;
    }

  `gamma` is local to the `if` block and will not leak out. This form can be used to create bindings in `for` as well:

    for ( let i=0 ; i < 10 ; i++ ) {
      console.log(i);
    }

  here, `i` is only visible from the condition, incrementor and body of the `for` statement but not outside

* Let statement, mostly for side-effects, sufficient for what you need:

    let (callback = function (a, b) {
                // ...
            }) {
        object.registerCallback();
    }

* Let expressions, this works like the `let` statement but returns a value, just drop off the braces:

    let foo = let (i=42) doSomethingWith(i)

  will bind the result of `doSomethingWith(42)` to `foo`.

smosher4• 15 years ago

Let statement, mostly for side-effects, sufficient for what you need:

Sadly it's not. JS has some semantic foibles, but I find myself up against syntax more often than I'd like. Every time I write it I'm impressed at how ugly the syntax is vs for such a good language (modulo the standard library.)

The very thing I'm trying to avoid is the use of blocks within parentheses. (Aside: I changed my font to Monaco for JS because of the frequent appearance of `})`, and went to the trouble of fixing it up in Fontforge so gvim et al. would be willing to use it.)

I never want to see this:

    anything(block {
        // ...
    }) <--- this
    ^^____this

but I still want the definition to be short-lived (more for self-documenting purposes than anything else, now that I think of it.) Your last example almost has it, but the parens are right there where I want them gone.

_urga• 15 years ago

64-bit integers and bitwise operations together with default arguments and destructuring would solve just about everything.

Animus7• 15 years ago

I cannot rightly comprehend what problems one must be having if the solution is a wider bit width and variable assignment sugar.

Fargren• 15 years ago

Does anyone know if this will get implemented into ActionScript? I want let so much.

ECMAScript 6 looks promising

Related Stories