Live data from Hacker News

ECMAScript 6 looks promising

kishorelive.com

21–30 of 94 posts

Re: ECMAScript 6 looks promising

#21
post #9

Earlier quoted context omitted.

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

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.

Somehow you have to get those values into the String, though. How do you propose doing it? Seems to me you can either concatenate Strings ("hello "+name) or interpolate ("hello #{name}")? Interpolating actually looks cleaner to me.

Or of course create_string("hello $1", name) or something like that.

Re: ECMAScript 6 looks promising

#22
post #12

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

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.

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

Re: ECMAScript 6 looks promising

#23
post #9

Earlier quoted context omitted.

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.

Every time I try Ruby, this features seems odd, yet I never see much discussion of it. It feels unnatural to me, coming from a python background, and the only real advantage I can see is the fact that you do not have to type `.format(foo")` after the string, or some similar construct. What advantages did I miss? I doubt that the creators of ruby did not put any thought into this, and I'd be interested in their justif…

I don't believe it's the rationale, but it does have a tiny advantage in readability compared to old style format strings, e.g

    "hello $name we welcome you in hour team '$teamName' of ${members.size}"
vs

    "hello %s we welcome you in hour team '%s' of %d" % (name, teamName, members.size)
While, comparing it to modern python's str.format, which would be (i believe please correct me if I'm wrong)

    "hello {name} we welcome you in hour team '{teamName}' of {members_size}".format(name=name, teamName=teamName, members_size=len(members))

...I guess my question would be the opposite: why is that better than string interpolation (which has also been around for decades)?

Re: ECMAScript 6 looks promising

#24
post #3

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…

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

Re: ECMAScript 6 looks promising

#25
post #22
post #12

Earlier quoted context omitted.

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.

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

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

Re: ECMAScript 6 looks promising

#26
post #9

Earlier quoted context omitted.

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

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.

It's not really automatic interpolation. You have to very explicitly place the variable name inside ${var}. I'm puzzled in how you would think this will happen accidentally, or more accidentally than writing "+var+".

I've used Ruby quite a while and never experienced any problems with the very same construct in there.

Re: ECMAScript 6 looks promising

#27
post #3

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…

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

Re: ECMAScript 6 looks promising

#28
post #25
post #22

Earlier quoted context omitted.

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

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

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.

Re: ECMAScript 6 looks promising

#29
post #3

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…

>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…

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

Re: ECMAScript 6 looks promising

#30
post #21
post #9

Earlier quoted context omitted.

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.

Somehow you have to get those values into the String, though. How do you propose doing it? Seems to me you can either concatenate Strings ("hello "+name) or interpolate ("hello #{name}")? Interpolating actually looks cleaner to me. Or of course create_string("hello $1", name) or something like that.

> Interpolating actually looks cleaner to me.

Definitely. It can't be used for i18n though, which is problematic (interpolation usually uses full expressions, so it's essentially a vector of code injection).

> Or of course create_string("hello $1", name) or something like that.

There are already string formatting minilanguages, no need to make up your own: you can use printf's format or C#-style string formats (I think the C# one is rather nice, especially its extensions in Python which allow for implicit positional and named formatting)

Post reply on HN