Implement arrow functions in v8 | Hacker News Reader

Implement arrow functions in v8

code.google.com

44 pointsinglor56 comments

Do we just link to random commits now? I have no idea what arrow functions are or why it would even matter to half the people who visit this site.

edit: after following 4 links I finally found the bug report about it

https://code.google.com/p/v8/issues/detail?id=2700

Then it seems like the perfect opportunity for you to learn something new and stretch your mind a little.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Arrow functions are one of the improvements from JS Harmony (which was ratified last night).

This commit moves them from "behind the experimental flag" to "shipping by default" in Chromium. It's a pretty big deal to people who write JS for a living.

that's what the synopsis of the post should have been, thanks

They are a compact way to write anonymous functions in Javascript, so instead of

    var square = function (a) { return a * a;}

You can write:

    var square = a => a * a;

So basically, a useless hipster fashion lead fluffy syntax change, which mainly makes code harder to read, and makes typos more common.

  // foo takes a function, and a boolean.
  // foo(a=>7, a>=2);

Really? That's easy to read is it? Eugh count me out.

You are trolling, but arrow functions (unlike those defined with the function keyword) also bind this to that of the enclosing scope. The results in more intuitive behavior in most cases and less explicit bindings.

shrug it's still just code. It still does exactly the same thing as previous javascript code. Syntax changes are pretty boring IMHO, and as I said personally, I find this one much harder to read, more prone to errors, typos and confusion.

Yes, but if you write a few thousand of those arrow functions, you will hate the useless function (a) { return b; } stuff, too.

If you're writing a few thousand functions, you're doing something very wrong.

It's like when languages make threads easy to create - and then programmers go away and use threads for everything!

Maybe some verbosity is a good thing because it makes programmers think about whether they really want to do something a few thousand times.

Javascript is a functional language. You _should_ be writing many functions, possibly thousands in a large codebase.

Javascript has first-class functions and anonymous functions, but so do lots of imperative languages, and there are plenty of other reasons to see Javascript as an imperative language. The reason we end up writing many anonymous functions is because we are using interfaces like foo.map(...) instead of interfaces like for-loops which take a block as a body (because Javascript for-loops are unbearably clumsy, e.g. iterating over properties instead of elements).

You seem to keep missing that it has a different effect on scope and therefore you are incorrect in insisting it does "the same thing"

Also, your tone is bad.

You find it harder to read because you're not used to it, that's all. Once you absorb the syntax it'll feel more native, and you'll format it in a fashion that makes it easier for you to absorb at a glance.

At some point things have to stop being called "syntax changes". Just because you can represent the same operation by pressing more keys doesn't mean that it's not useful to add an abstraction on top of it to ease cognitive load, otherwise we'd all be programming with switches.

I think a better argument would have been that adding something that appears to just be a shorthand for writing functions is a potential footgun to language newcomers, but I think that argument is still relatively weak.

Then lets "abstract" your first sentience:

At point have stop called . Just you represent same by more doesn't that not to an on of to cognitive , otherwise all programming switches.

My point is, removing "function" and "return" from the syntax, won't necessary easy cognitive load, at least not for senior JavaScript coders. It will save bandwidth though! :P

Your parent post skimmed over an important detail, it's not just a new syntax, it's new type of anonymous function with a new type of scope. It's more like:

function(arg) {statement;}.bind(this)

Yeah like the others said it binds this to the scope where it was defined. So something like this works as one would expect:

    setTimeout(() => this.someMethod(), 1000);

I've been doing ES6 for several months now. Not once have I mistook `=>` for `>=`. Not once have I made a typo when I wanted an arrow function.

Of course any syntax can be abused in such a way to create ugly code. But if I compare

    [1, 2, 3].map( a => a * a );  // [1, 4, 9]

    [1, 2, 3].map(function(a) { return a * a; });

I prefer the former. It's more concise, and strips off a lot of visual noise, and I think it's more readable (the intent isn't wrapped in lots of boilerplate).

That doesn't mean one can't write horrible code with the arrow form. Of course you can. Furthermore, it's not necessarily something you should use all the time, because it's not completely analogous to a normal `function` because it binds `this` lexically. Which means `function` isn't going away any time soon, especially if you need to bind them dynamically.

In short: use the best (syntactic) tool for the job. There are use cases where the arrow makes sense semantically, and there are cases where it doesn't. Use as appropriate, as one should always do.

Verbosity is not clarity.

    list.map(function(x) { return x * 2; });

verses

    list.map(x => x * 2);

The actual functionality of the first is swallowed in visual noise (function, return). Yes, it's something new to learn for Javascript programmers, but it's useful and makes the meaning of code clearer.

That's not even touching on the this-binding element, which is also incredibly useful in common Javascript code.

Just eliminating the words "function" and "return" doesn't make the code clearer. Anyone competent with Javascript can easily read the first form. The difference in time to read the expression may not even be measurable. If you want to argue that it makes the code neater that's fine, but the meaning is not made clearer by the substitution of sigils for words.

As has been pointed out though, that is not the primary thing that arrow functions give you. They're really there to avoid having to manually bind functions in order to maintain execution context or use the old `var self = this; function(){/.../}` workaround.

> Anyone competent with Javascript can easily read the first form

And anyone competent with any language implementing map can easily read:

    users.map(user => user.name);

...without having to do any "skimming over" the noise. It's not a big difference, you're right, but it's the kind of little thing that, when you let it build up over time, gives you the "write-everything-in-triplicate" feel of Java 6.

Further, you have to be intimately familiar with Javascript to understand why this is necessary:

    function fetchUserData(){
        var self = this;
        userService.fetchAllUsers()
                   .then(function(fetchedUsers){ self.users = fetchedUsers; });
    }

or even this:

    function fetchUserData(){
        userService.fetchAllUsers()
                   .then(function(fetchedUsers){ this.users = fetchedUsers; }.bind(this));
    }

as opposed to simply writing:

    function fetchUserData(){
        userService.fetchAllUsers()
                   .then(fetchedUsers => this.users = fetchedUsers);
    }

Did you know you can do this!?

  someObject.foo = function() {
    someObject.bar = 123;
  }

  function Foo() {
    var Foo = this;
    Foo.bar = 456;
  }

Pro tip: Always do asynchronous operations Before presenting the object to the program state. Or you will see "undefined" bugs in production!

Actually that code example is hard to read because your variables are called 'foo' and 'a' and you've chosen not to include white space around your operators.

The lambda function is a foundational construct in computer science (1936), and it is often written using an arrow. Hipster fluff it is not.

Here are some fun counter-examples

  let sqr = x => Math.pow(x, 2)

  let property = name => obj => obj[name]

  let distance = p1 => p2 => Math.sqrt(sqr(p2.x - p1.x) + sqr(p2.y - p1.y))

  let byComparing = f => (x, y) => {
    let fx = f(x), fy = f(y)
    fx < fy ? -1 : fx > fy ? 1 : 0
  }
  
  let points = [{x: 1, y: 2}, ...]
  
  let byX = points.slice().sort(byComparing(property('x'))
  
  let byStartDistance = points.slice().sort(byComparing(distance({x: 0, y: 0}))

That's indeed pretty fun. In practice however this is much simpler:

    let sqr = x => Math.pow(x, 2)

    let distance = (p1, p2) => Math.sqrt(sqr(p2.x - p1.x) + sqr(p2.y - p1.y))

    const zero = Object.freeze({x: 0, y: 0})

    let byX = points.slice().sort((p1, p2) => p1.x - p2.x)

    let byStartDistance = points.slice
        .sort((p1, p2) => distance(p1, zero) - distance(p2, zero))

It's not nearly as composable, sure, but I think almost everyone would understand it much faster. The curried `distance` would also be a bit annoying to reuse in other contexts where you'd have to write `distance(p1)(p2)` instead of the idiomatic (at least now; idioms can change) `distance(p1, p2)`.

That said, the arrow function is a massive win in both examples. I've been using it for a while and never had any issue mistaking it with <= or >=. The linter would probably catch it anyway.

The syntax isn't new, and people haven't had issues with it in other languages.

Using arrow functions also lexically binds the this value in the anonymous function, an important change for many.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Your link goes to the same page as this post. Was it changed at some point?

must have, because it was going directly to the commit which didn't have any useful information.

I'm glad it's finally arriving, it been working in Firefox for quite a long time and I'm happy to see v8 implementing this ! Arrow functions are so much nicer to read and use.

  a=>b<=7
  a>=b<=7

Can you not see the typos possible with this? The less characters you use for something, the more error prone. There's a reason we don't write in regular expression syntax.

Maybe I'm just getting old!

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.

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.

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.

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

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.

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

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.

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.

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.

Do the stack traces for native arrow functions show up in the stack trace as anonymous functions or is only the parent function registered in the stack trace.

Now read the blog post about it! Andy Wingo is a great compiler hacker and he writes about a lot of things that he works on. http://wingolog.org/archives/2015/06/18/arrow-functions-comi...

Totally agree. Wingolog is an amazing blog and anyone curious about compilers and v8 in general should check it out.

Hmm, I get a syntax error from the puzzle in Firefox.

Anyone have any idea when destructuring assignment is going to make it into v8?

That is one of the features my colleagues most cite as justification for using babel.js (I wouldn't mind destructuring assigment either). I would love to be able to avoid transpilation since it adds overhead from making out our toolchain more complex and makes debugging more difficult because stack traces and line numbers don't necessarily match up.

On the front end you can get babel to work with sourcemaps fairly easily depending on what build tool you use.

It's in the works: https://code.google.com/p/v8/issues/detail?id=811

You can tell by the number of CLs that a lot of work has been done already but there are a few more still in progress. It's probably still a few weeks out.

Disclaimer: I don't speak for the V8 team, I'm just an interested onlooker.

It has been reverted[1] now. History repeats itself.

[1] - https://code.google.com/p/v8/issues/detail?id=2700#c47

If you use an anonymous function instead of a named function you'll probably end up writing a comment to clarify ... :P

Sometimes the code explains itself though!?

  allowed = members.filter(member => member.age >= ageLimit);

Reply on news.ycombinator.com