51–60 of 94 posts
let callback = function(a, b) {
// ...
} in
object.registerCallback(callback);Earlier quoted context omitted.
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)
The things don't seem mutually exclusive to me.
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
> 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.
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.
Earlier quoted context omitted.
>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? 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.
a, b, c, *_ = list
a, *_, b = listEarlier quoted context omitted.
I doubt. /* */ is already used for commenting.
That's the idea. 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
`let` is good but please, give me `let ... in` too: let callback = function(a, b) { // ... } in object.registerCallback(callback);
* 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 let (callback = function (a, b) {
// ...
}) {
object.registerCallback();
}
let foo = let (i=42) doSomethingWith(i)
will bind the result of `doSomethingWith(42)` to `foo`.Earlier quoted context omitted.
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 elimin…
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).
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.
Earlier quoted context omitted.
>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.
a, *, c = list
And people often use _ as a placeholder when not using splatting:
a, _, _, c, d = list
Earlier quoted context omitted.
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.
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…
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.