ECMAScript 6 looks promising • Hacker News Board

Re: ECMAScript 6 looks promising

#31

Post by masklinn » Thu, Nov 24, 2011, 5:44 PM UTC

riffraff wrote: post #23

lclarkmichalek wrote: post #13

Earlier quoted context omitted.

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…

> why is that better than string interpolation (which has also been around for decades)?

For my money, you can't use string interpolation for i18n alongside a semi-arbitrary access site (e.g. Transifex or Launchpad's Rosetta) and it's riskier for logging (for performance-related reasons, as it forces an eager interpolation where the logging API can provide for lazy formatting)

Re: ECMAScript 6 looks promising

#32

Post by hsuresh » Thu, Nov 24, 2011, 5:55 PM UTC

nailer wrote: post #17

wulczer wrote: 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…

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.

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

Re: ECMAScript 6 looks promising

#33

Post by philjackson » Thu, Nov 24, 2011, 5:55 PM UTC

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

Re: ECMAScript 6 looks promising

#34

Post by MrHamdulay » Thu, Nov 24, 2011, 6:07 PM UTC

hsuresh wrote: post #32

nailer wrote: post #17

Earlier quoted context omitted.

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.

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

That's the idea. Python uses the same syntax for multi-line strings as for comments.

Re: ECMAScript 6 looks promising

#35

Post by [deleted] » Thu, Nov 24, 2011, 6:08 PM UTC

wulczer wrote: 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…

[deleted]

Re: ECMAScript 6 looks promising

#36

Post by lautis » Thu, Nov 24, 2011, 6:12 PM UTC

barumrho wrote: post #15

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.

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.

Re: ECMAScript 6 looks promising

#37

Post by firefoxman1 » Thu, Nov 24, 2011, 6:15 PM UTC

wulczer wrote: 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…

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.

Re: ECMAScript 6 looks promising

#38

Post by [deleted] » Thu, Nov 24, 2011, 6:15 PM UTC

wulczer wrote: 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…

[deleted]

Re: ECMAScript 6 looks promising

#39

Post by jemeshsu » Thu, Nov 24, 2011, 6:19 PM UTC

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.

Re: ECMAScript 6 looks promising

#40

Post by SimHacker » Thu, Nov 24, 2011, 6:28 PM UTC

nailer wrote: post #17

wulczer wrote: 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…

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.

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