Who on earth would really write that? Surely you'd use the optional braces to make it clearer:

    a => { return b <= 7; }

Sure you can write it without that, but only if you want to write willfully unclear code to annoy people, like writing an entire function body on one line. Just because you can do that doesn't mean that functions are inherently unclear.

More who on earth would really write a function that took a named argument, ignored it, and compared a value in the outer scope.

All of the examples that look confusing are artificially simple and doing things you wouldn't normally try to do.

Well, anybody who wants to use lambdas I'd imagine.

If you're going to write it out, you might as well just add the `function` keyword for clarity because you're not saving a ton of keystrokes.

    function(a) { return b <= 7; }

Just make it a => (a <= 7), that is perfectly fine for me. (I replaced the b with an a, otherwise it looks pretty pointless or maybe a strange closure hack.)

Because writing:

    var self = this;
    foo(function(x) {
      return x + self.y;
    });

rather than:

    foo(x => x + this.y)

is so much less error-prone?

Think about what would happen if you typo a single character in each example.

If you miswrite "function" as "fnuction", you'll easily, quickly find out.

If you miswrite => as >= it might take ages to track it down.

That's why you use static type checkers.

If the function `foo` is defined as taking a function as its first argument (or even more precisely, a function which takes a number and returns a number), and you try to give it a boolean, then the static type checker will yell at you, and you'll just as easily find out as that fnuction typo.

Spend a half decade writing Perl and you'll develop an eye for minute details like that.

People aren't kidding when they say Perl looks like line noise, but you get used to it and can find your way through even a dizzying regular expression with relative ease over time.

Yes, $s=~s+s+S+s+$s is valid Perl.

You can get used to it, but if it takes 5 years to get reliable at parsing line noise then that many more programmers are struggling with it at any given time. Why shouldn't languages try to help rather than hinder for 5 years?

C++, by way of example, is extremely complicated and wickedly unforgiving. JavaScript, even at its most surreal, is nowhere near that.

Suggesting that things like => are "too confusing" for JavaScript is to suggest that people that write JavaScript are too dumb to handle it. Is that what you're implying here?

Some programmers write in one language, but many write in several. Having the same shorthand available in JavaScript as in C# is a big deal, it makes things feel better. Being able to apply what you've learned in one domain directly to another is more efficient than having some ridiculously quirky JavaScript-only way of doing something.

That some people will abuse it or be confused is a problem that can be overcome with a little bit of learning. It's not a big deal.

What the heck is the second one supposed to mean? At first it looks a bit like low <= x <= high but with one comparison operator in the wrong direction. I guess it will first compare a and b evaluating to a boolean value, then implicitly convert this result to an integer and finally compare that to 7 again yielding a boolean value. If you write code like that confusion with the arrow notation is one of your smaller problems.

EDIT: Now I got your point - you could accidentally assign a boolean value to a variable when you intended to create a function. One word - compile time type checking. Okay, four, Übersetzungszeittypprüfung in German.

This is a very wrong way of reasoning about probability. The chance that a coin will at some point land on heads does not decrease with the number of flips.

mmmm, I haven't considered this case... I personally preferred the Coffeescript version like this: a->b<=7 which even without spaces is clearer but maybe they had something incompatible with it.