
Douglas Crockford on Fat Arrow Functions in JavaScript - jashkenas
http://www.yuiblog.com/blog/2012/03/30/what-is-the-meaning-of-this
======
Osiris
The proposed function syntax looks exactly like C# lambda functions. Even the
(this, x) => {} format is similar to how C# extension methods work. Extension
methods require "this" to be the first parameter and define what objects the
method can act on.

It's really interesting to see that bleed over from a completely different
type of language.

~~~
masklinn
In Javascript it wouldn't be an extension method though, but a function with a
dynamically bound `this` (similar to current function behavior)

~~~
Osiris
Right. I just meant to point out the syntax similarities.

------
jashkenas
Just realized that Crockford didn't link to it in his post. Here's the full
proposal that Brendan Eich added to the ES Wiki:
[http://wiki.ecmascript.org/doku.php?id=strawman:arrow_functi...](http://wiki.ecmascript.org/doku.php?id=strawman:arrow_function_syntax)

~~~
robocat
The part I found interesting was:

"However, we don’t want CoffeeScript’s ->, it’s confusing to have two arrows
and dynamic this binding is an oft-fired footgun."

~~~
jashkenas
It looks like Eich's original pitch was for both => (lexical this) and ->
(dynamic this), but the latter was cut for political reasons.

Out-of-band info from here:

<https://twitter.com/brendaneich/status/186156717506166784>

<https://twitter.com/brendaneich/status/186160406300082176>

<https://twitter.com/brendaneich/status/186162306521120770>

<https://twitter.com/brendaneich/status/186162532367601666>

~~~
robocat
Thanks. Interesting!

------
reginaldo
_The new functions do not have names, so you will need to use the old
functions to write self-recursive functions._

Or you can use the Y Combinator for extra fun...

[https://secure.wikimedia.org/wikipedia/en/wiki/YCombinator#E...](https://secure.wikimedia.org/wikipedia/en/wiki/YCombinator#Example_in_JavaScript)

~~~
danbmil99
Can't you assign the function to a var and invoke that in the function body,
like in Coffeescript? Otherwise I'm missing something.

------
justinvoss
Looks really similar to Coffeescript. Is it safe to say that this new
Javascript feature is a direct result of Coffeescript's influence? I hope so:
Javascript is full of little horrors like the 'this' keyword, and it seems
like it took a whole new language to convince people that it needs fixing.

~~~
voidfiles
I think its absolutely because of languages like coffee script that JavaScript
is changing, but don't take my word for it. You can find statments from
standards makers to the same effect.

~~~
CJefferson
Really? I'd really like to see some references to that.

These kinds of changes have been floating around for javascript since long
before coffeescript.

~~~
voidfiles
This is a great talk to watch about the development of JS. It's been a while
since I watched it, but the point I was making, and the point I gleaned from
this talk, is that new ideas need a test bed, and according to Eich
Coffeescript is one of those places where new ideas are tested, and derived
from.

<http://vimeo.com/27911873>

<http://brendaneich.com/2011/08/my-txjs-talk-twitter-remix/>

------
gfodor
At this point it feels like the next version of Javascript should just
standardize CoffeeScript syntax and add a few much needed features
CoffeeScript can't currently do because of JS limitations.

------
ef4
Fat arrows are one of the selling points for CoffeeScript, if you don't want
to wait for ECMA6.

~~~
TazeTSchnitzel
Doesn't fix the inefficiencies.

~~~
snprbob86
Recent versions of CoffeeScript greatly improved compilation of fat arrows.

This:

    
    
        x = (a) =>
          y = (b) =>
            z = (c) =>
              @q * a * b * c
    

Becomes this:

    
    
        var x,
          _this = this;
    
        x = function(a) {
          var y;
          return y = function(b) {
            var z;
            return z = function(c) {
              return _this.q * a * b * c;
            };
          };
        };
    

Instead of this:

    
    
        var x;
        var __bind = function(fn, me){ return function(){ return fn.apply(me, arguments); }; };
        x = __bind(function(a) {
          var y;
          return y = __bind(function(b) {
            var z;
            return z = __bind(function(c) {
              return this.q * a * b * c;
            }, this);
          }, this);
        }, this);

~~~
starwed
Taze is (presumably) talking about the inherent inefficiency of all those
functions having prototypes.

(You know, the thing that was mentioned in the linked article?)

------
Swizec
Can't wait for this to happen and gain widespread browser support so I can
actually use it.

JavaScript is a beautiful language trapped in a lame syntax, peppered with
poor semantic choices based on what was considered "just the way it is" back
then.

~~~
voidfiles
If its that important you could just use Coffescript while you wait.

~~~
SideburnsOfDoom
There are things about coffeescript that I just don't think are good ideas,
like "unless" or "if" at the end. The person reading the code will think "Ok,
now I'm doing x ... oh wait I'm not". the flow of it is just backwards.

The "myFunction(item) for item in array" syntax also seems wrong way around.
You use "item" before you say what it is.

I'm not an expert. These are just initial impressions, but coffeescript seems
to have some good ideas, but tries to do too much. It would be interesting to
see what thought process went into deciding to include certain constructs. Was
it just an experiment? Are there reasons that might persuade me?

Ultimately the better JavaScript is also going to be JavaScript.

~~~
jashkenas

        > It would be interesting to see what thought process 
        > went into deciding to include certain constructs. 
    

Happy to oblige. There's plenty of reading material and conversations about
most language decisions available here:

[https://github.com/jashkenas/coffee-
script/issues?direction=...](https://github.com/jashkenas/coffee-
script/issues?direction=desc&labels=change%2Cenhancement&page=25&sort=created&state=closed)

As to the existence of (optional) postfix "unless" and "if" -- does it also
sound backwards to you when someone says:

    
    
        "Call your mother if it's her birthday."
    

... in English? If that doesn't sound so crazy, then consider the
CoffeeScript:

    
    
        call mom if mom.birthday.isToday()
    

It's a little thing, that hopefully you can take advantage of to make short
conditionals more readable then the JSLint-style JavaScript:

    
    
        if (mom.birthday.isToday()) { call(mom); }

~~~
SideburnsOfDoom
Does a language need three ways to say "if x do y" ? or maybe there's an
"unless !x do y" construct and it's 4 ways.

This to me looks like going out of your way to have lots of ways to do the
same thing. I never cared for it in PERL either.

The argument that "it reads like English" is not one that I like much - The
history of making programming languages read like English is a long succession
of dead ends. Programming languages work more like formal maths proofs than
they do like English prose. Rather make the language readable on its own
terms.

~~~
knowtheory
> _The history of making programming languages read like English is a long
> succession of dead ends._

There certainly have been notable failures, such as Applescript, but I find it
hard to dismiss Coffeescript, Ruby, SQL and FORTRAN which have all been quite
popular.

~~~
SideburnsOfDoom
I like SQL, not for the english-ish keywords, but for the strong mathematical
underpinnings.

You left out a notable example of Cobol - Which would you rather read: "Add 1
to someValue Giving someValue", or "someValue++" ?

------
jenius
Holy shit something that has been around for a while and works in all browsers
now with coffeescript is now something we may be able to use with regular
javascript in like 10 years! What's next, a for loop? Am i pushing it too far?

(flame prevention: this is kind of a joke. i understand that it actually is
pushing towards a better language, it's just such a slow and painful process
compared with just using coffeescript)

------
huskyr
It's nice that somebody like Crockford writes an article like this, telling us
how to actually use the new syntax. The original ES Wiki article is probably
great for browser vendors but i didn't quite get it the first time i read it.

------
cormacrelf
It sounds like people will prefer the (a,b) => {} syntax over function (a,b)
{} simply because it's more concise and looks better, not because of its
usefulness.

~~~
darklajid
Sometimes concise is (arguably, of course) better.

Whenever I pass a simple and short function, for example as a predicate to
grep/filter or as a tiny implementation for map/reduce I feel that "function"
is half of what I type - and distracting. Worse, explicitly "return"ing adds
more noise.

Most of my anonymous functions are really, really small. If they are usually
on the level of "d % 2 == 0" or "d.slice(42)" then removing the overhead of
"function (d) { return" seems a good idea. Not a huge deal, but nice
nevertheless.

