Hacker News Reader

Comment by wulczer | Hacker News Reader

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.

View on HN

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

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.

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

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

Ruby unfortunately has non-strict destructuring, but it also has LHS splatting:

a, *, c = list

And people often use _ as a placeholder when not using splatting:

a, _, _, c, d = list

They are:

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

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

FWIW, Python 3 improves case 1 to:

    a, b, c, *_ = list

better, you can put the slice at at any point of the left hand, so if you want the first and last elements of your list (and want to ignore everything else) you can write:

    a, *_, b = list

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?

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.

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.

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

>> I doubt that the creators of ruby did not put any thought into this, and I'd be interested in their justification.

I don't know what Matz's thinking was, but it may just be that Ruby owes a great deal to Perl. Interpolation in double-quoted strings is present in Perl (and used constantly).

I think the bad part of string interpolation is that it encourages to use it constantly, in place, instead of extracting it to method.

Gluing strings together is the weak point of application, and should be hard to do, to encourage people to wrap it in functions, that can also validate input, escape what needs to be escaped, etc.

Maybe that's my "discipline and bodage" part talking :)

I'm a very small-scale, amateur programmer, but that sounds like over-engineering to me. Getting variable values into strings is often necessary. A programming language shouldn't make something common hard, just to enforce a particular view of best practices. Note: I'm not saying that "make it a method" is a bad idea - in general or in the case of a specific project or a specific size of codebase. But I don't like the idea of the language enforcing such a restriction.

Having said that, my first language was Perl, and I'm still a fan of TMTOWTDI and making common things easy.

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}"

    "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)?

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

these are good reasons for having a string templating system in a library, but I was referring to the 90% use case of having a script that outputs something it computes.

The things don't seem mutually exclusive to me.

> The things don't seem mutually exclusive to me.

Sure but now you have two very different ways to format your strings and language users need to realize they should be using the one they're not used to for these specific tasks, even though there's pretty much nothing helping make them realize it.

That significantly increases the user's cognitive load, and the risks of misusing APIs unless your language is able to express (and safegard against) the danger of string interpolation in specific contexts.

Does anyone know what the rationale was for choosing this instead of printf or python3-style interpolation (where you explicitly specify the variables to be interpolated)?

It's syntactic sugar for string concatenation. The same bugs would happen today if you were concatenating strings. I don't see the problem, honestly.

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)

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.

You can also get away with doing just "$var", though, which is the problem. We encountered a strange bug the other day where having a string containing "$3" meant it never appeared on the page after (with it being converted to null).

Strings with interpolation look different in ES6. They don't just look like string literals. You can easily see where the variable substitutions happen.

Also, I don't know what your argument about PHP is all about. I don't agree with the idea that string interpolation is going to lead to people writing code vulnerable to SQL injection, for example. You can just as easily write "select * from foo where name=\"" + name + "\"" as `select * from foo where name="${name}"`.

> You can just as easily write

No you can't. You've got 8% more character and 2 switches between string context and expression context. It does not "flow" it's something which is forced on the user by limitations of the language.

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.

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

It does have some advantages, but the author of a library creates a library to do a specific thing and to do it well. When it gets added to the language, as we've seen with the horrible module proposal, lots of people all disagree on how it should be implemented so you end up with a much worse implementation than if you just let individuals create the feature how they think is best.

With libraries, you are free to switch to other ones if you don't like the way it does a specific thing. Don't like CommonJS? Don't use browserify, and instead try RequireJS. Don't like how Prototype extends the prototype of objects? Try jQuery.

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.

This is completely wrong. Triple quotes in Python indicate a string. It happens to be able to be used for a multi-line comment because it officially leaves no artifact in the AST if it's not assigned to anything (can't find the documentation for this atm).

/ * ... * / is a comment in Javascript. Changing it to mean multi-line string is a terrible idea.

This list of changes to Javascript borrows so much from Python I'm surprised they didn't also borrow Python's multi-line string syntax.

> Python uses the same syntax for multi-line strings as for comments.

No it does not. Triple-quoted strings are still strings, all comments in Python are prefixed with `#`.

There are two situations where triple quoted strings are used as "comments":

* Multiline comments for lazy people, as Python has no multiline comment syntax

* docstrings. As the name indicate, they're strings, they're not comments and should not be confused by more ad-hoc systems such as javadoc comments. Python lets you write `help(name)` and get the docstring associated with the object

Damn, I just got comfortable with functions being first class constructs, now I have to get used to the idea of comment meta-programming.

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

Sorry, I read the part about HN making it difficult to format your post, but I still don't quite get your point. I think it's pretty simple what was proposed: everything between the stars is included.

Reply on news.ycombinator.com