

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

======
wulczer
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.

~~~
ataggart
>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.

~~~
ajuc
> 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.

~~~
Volpe
Catch an exception of something that isn't exceptional? isn't that the anti-
case for exception handling?

I don't get why strict restructuring is a bad thing... as long as it's
consistant, it's just a nuance of the language.

Am I missing side effect of this? What are potential pit-falls of this
pattern?

~~~
ajuc
I was arguing that non-strict destructuring is bad, so this code IMHO should
throw exception:

    
    
        a,b,c=[1,2,3,4]
    

The reason for this is - if you assume array has 3 elements, but it has more,
your code will silently ignore the rest. You'll have to write your assertion
every time you destructure, to be sure that destructuring don't ignore data.
The exceptional case IMHO is when you need to ignore data, and so code for
this case should be uglier, not the other way around. You are right that
catching exception for regular code path isn't the best way, but at least
programmer intention is clear then.

You could also do

    
    
         a,b,c = list.slice(0,3);
    

which copies the array, but at least it's clear what it assumes about the
array. And it can be easily modified to get last 3 values, or 3 values from
the middle of list. So no need for 2 idioms depending on which items you want
to get from the array.

------
boucher
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
Do you have reason to think that's likely?

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

~~~
Cushman
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.

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

~~~
jamesra
Because it is badly designed? Or because it is too different from js?

~~~
masklinn
Because it's kind-of a mish-mash, and syntactic elements imported from other
languages (I know) tend to behave differently in subtle ways, usually making
them worse or weird. Also having a single token change so much meaning (fat vs
thin arrow) feels icky and hard to read/notice.

~~~
Cushman
That's a fair perspective, although what you call a "mish-mash" I'd call
borrowing the best syntax for every feature :) The syntax came out of a
community effort over the course of many months, and a lot of thought went
into the decisions that were made. (And of course it's still under
development!)

Since you mentioned the => operator in particular, I'll defend it briefly--
it's a feature JavaScript sorely needs, and in the situations where it's
useful it's a godsend, turning a pile of ugly JS into a single operator. The
thing it describes is a little complex semantically, but in practice it's very
straightforward, and in the cleaner environment of CoffeeScript it stands out
well. It does seem like a small difference, but do you mix up == and -= much?
Same deal. Visually speaking it actually makes a lot of sense: -> indicates a
vanilla, unbound function, while => indicates a bound function whose context
_equals_ the one it's defined in.

I know I'm a bit of a fanboy, but if you do a lot of JavaScript I'd encourage
you to at least give CoffeeScript a second chance over a weekend sometime;
it's the same, normal JS semantics you know and love, but you get to use all
the futuristic shortcuts and clean syntax of a modern scripting language, and
it outputs nice, readable, compliant JavaScript. (Say goodbye to JSLint!)
That's well worth the minimal learning curve, in my opinion of course.

~~~
masklinn
> Since you mentioned the => operator in particular, I'll defend it briefly--
> it's a feature JavaScript sorely needs, and in the situations where it's
> useful it's a godsend, turning a pile of ugly JS into a single operator.

Oh I understand the need for it, my issue is not with the fat arrow in and of
itself, but in the fat arrow _and_ the thin arrow.

> It does seem like a small difference, but do you mix up == and -= much? Same
> deal.

Well...

1\. I rarely if ever use either, and

2\. they're generally used in different contexts, I would never use `-=` as
part of a wider expression (unless I wanted to fuck with the reader of the
code, who is usually me) whereas `==` is not very useful outside of a
conditional expression (or at least as a parameter to something else, like a
function).

The thin and fat arrows, by comparison, are used in the exact same contexts.
This makes them much more error prone.

> That's well worth the minimal learning curve, in my opinion of course.

I don't mind the learning curve, I mind that I don't really like the way the
syntax fits together (or does not). Though, to be fair, I also don't like the
extra tooling or having to debug different code than was written.

~~~
Cushman
> The thin and fat arrows, by comparison, are used in the exact same contexts.
> This makes them much more error prone.

You can say that, but in practice it doesn't really happen. They look somewhat
different, they do somewhat different things. It's programming, ya know?

Not that I'm trying to _make_ you like it or anything-- of course you have the
right to your own aesthetic sensibility.

------
barumrho
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.

~~~
Bootvis
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
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.

------
program
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.

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

~~~
program
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";

~~~
dbattaglia
The only thing about the C syntax version is you still end up with a bunch of
double quotes all over the place. The #1 reason I have for using multi-line
strings currently is when writing full-out SQL or Javascript code inside C#;
using C#'s @-prefixed strings make the whole thing a lot prettier to look at
IMO.

For me personally I'll probably never have to write multi-line JS strings more
than once a year so I don't really care about the feature, but I do agree with
their way of implementing them.

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

~~~
karterk
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
:)

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

~~~
funksta
Python's string formatting is different though– it doesn't automatically have
access to the variables in the current scope. You have to explicitly pass in
the variables that you want to include, which seems to me like a cleaner way
of doing things.

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

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

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

~~~
masklinn
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`.

~~~
smosher
_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.

~~~
masklinn
> The very thing I'm trying to avoid is the use of blocks within parentheses.

That, er, makes no sense at all. Javascript's function uses braces, having an
anonymous function within _anything_ will yield either a brace-and-parens or a
brace-and-comma.

> Your last example almost has it, but the parens are right there where I want
> them gone.

Then there's no point in using javascript, go do something else because trying
to get rid of this will just yield to an idiosyncratic and mostly unusable
coding style.

~~~
smosher
_Then there's no point in using javascript, go do something else_

No need to be rude. Look, I know JS likes to do things in ugly ways. It has
great strength in the consistency of its syntax. That's cool. But by the time
you say the word "just" you're being ignorant.

~~~
masklinn
> No need to be rude.

The statement was not intended to be rude and I'm sorry you took it this way,
it was merely intended to be factual: you seem unhappy with javascript's _core
syntactic elements_ , you should use something else because they're not going
to be changed.

> Look, I know JS likes to do things in ugly ways.

Uh... ok, whatever.

> But by the time you say the word "just" you're being ignorant.

Ignorant of what, of you trying to work around javascript's syntax _in
javascript_ for debatable reasons of personal aesthetics? No, I think I got
that now, I was originally mistaken indeed in that I thought you were looking
for an improvement to the language, not "fixing" an irrelevant syntactic pet
peeve.

~~~
smosher
_The statement was not intended to be rude_

It comes off as a euphemism for much shorter phrase. Perhaps you didn't intend
to be rude, but you failed to be polite.

 _Ignorant of what_

(Exactly.) You've made assumptions and pinned them to me. I'd set you straight
but I don't actually want to continue this conversation. Sorry it didn't work
out.

~~~
masklinn
> Perhaps you didn't intend to be rude, but you failed to be polite.

Considering your messages seem to be about misleading and avoiding spelling
out your issues more than conversing, I had (and have) no reason to go out of
my way to be polite.

> I'd set you straight but I don't actually want to continue this
> conversation.

And now you're plain and simply lying. You never intended to set anything
straight (or you'd have done this in your previous comment instead of going
for the pithy implication) and never intended this to be a discussion.

> Sorry it didn't work out.

It's not a relation, there's no "working out" to do.

------
juliennakache
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
_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/> .

------
jemeshsu
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.

~~~
masklinn
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)

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

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

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

