6 ms·
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
by wulczer 15y 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.
- karterk 15y agoTo 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 15y agoI don't know much about PHP, what's wrong with it regarding templating?
- wulczer 15y agoAutomatic 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.
- lclarkmichalek 15y agoEvery 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.
- telemachos 15y ago>> 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).
- ajuc 15y agoI 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 :)
- telemachos 15y agoI'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.
- riffraff 15y agoI 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)?
- funksta 15y agoDoes 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)?
- lars 15y agoIt's syntactic sugar for string concatenation. The same bugs would happen today if you were concatenating strings. I don't see the problem, honestly.
- Tichy 15y agoSomehow 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.
- masklinn 15y ago> 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)
- nene 15y agoIt'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.
- FuzzyDunlop 15y agoYou 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).
- ootachi 15y agoStrings 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}"`.
- masklinn 15y ago> 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.
- nailer 15y agoI 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 15y agoI doubt. /* */ is already used for commenting.
- MrHamdulay 15y agoThat's the idea. Python uses the same syntax for multi-line strings as for comments.
- kbd 15y agoThis 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.
- masklinn 15y ago> 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
- morsch 15y agoDamn, I just got comfortable with functions being first class constructs, now I have to get used to the idea of comment meta-programming.
- ataggart 15y 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.
- masklinn 15y 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.
- adgar 15y agoRuby 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
- philjackson 15y agoThey are: var [ a, b, ...rest ] = foo
- ajuc 15y 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.
- Volpe 15y ago
- masklinn 15y 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.
- deleted 15y ago[deleted]
- firefoxman1 15y agoI 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.
- ajuc 15y agoEliminating 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).
- firefoxman1 15y agoIt 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.
- deleted 15y ago[deleted]