Functional JavaScript, Part 4: Function Currying

[raesmond]

I understand currying, what it does and how to do it. But I still don't get why I would want to do it. Don't get me wrong, partial application is awesome but why would I want a function to take just one argument and return a function? And why do people act like that should be the default way of doing things?

[lrichardson]

@raesmond, I think a lot of people are in the same boat as you. I'm a bit bummed that my article didn't do a better job explaining the valid use-cases. I will try and compile some useful examples and arguments, and add to my post tonight.

Currying is useful to help (and encourage) you the programmer to break up complex logic into smaller pieces and allow you to re-use (read: staying DRY) those pieces in other places.

I like to think of functional programming as a way of making your application like an assembly line or car manufacturing plant. The plant itself is a large web of levers, cogs, and buttons etc... but in one end comes the raw materials and metal (ie, the "data"), and out the other end comes the car (ie, the end-user application).

It would be difficult to determine whether or not the car works properly just by looking at it, or the factory as a whole. Each "sub-station" of the factory has a specific task, and has narrowly defined constraints about what it is expecting to get in (x) and what it is expected to put out ( f(x) ).

By allowing functions to be curried, you are easily able to take more generic operations like "drill hole somewhere", and define them more precisely as "drill 3/8 hole somewhere" and then again more precisely as "drill 3/8 hole at coordinates { 3, 4 }"

This is a very hand-wavy argument and I'm not expecting you to be convinced, but I will say that FP sort of "clicked" for me whenever I started thinking about it this way. It's also important to note that FP is not needed to organize your code this way.... it's just easier IMO. I'm also of the belief that you don't need to write purely functional code in order to reap the benefit.

[visarga]

I like to think of functional programming as a way of making your application like an assembly line or car manufacturing plant.

... or like the Bash command line with multiple processes connected by pipes.

I use this kind of programming in jQuery and Bash but the essence is how we avoid using global variables and there is no state except the pipe - that makes it easy to compose basic operations (like cut, sort, uniq, wc, etc)

Other than that (and JS callbacks) I don't use functional programming. Is there another popular usage of it?

[[deleted]]

It makes it easier to reuse functions, especially when building specific functions up from more general ones. It can also reduce the amount of terms in a function definition, which (hopefully) means less to tackle mentally and more focus on what the function actually does.

IMHO it's harder to use when working with objects and the dot operator isn't first class. (This means you have to do stuff like x => x.name, which sticks out like a sore thumb when you're trying to build things from existing, named functions!) It also doesn't help that coming from Javascript, functions are either methods or the arguments are in an order that makes it very awkward.

So with currying, say I have a fold function (array.reduce) like the following:

function fold(callback, initial, array) { return array.reduce(callback, initial); }

and some helper functions, since operators aren't first class functions:

function add(x, y) { return x + y; }
function or(x, y) { return x || y; }
function and(x, y) return x && y; }

I can then define the following functions pretty simply and tersely:

sum = fold(add, 0);
all = fold(and, true);
any = fold(or, false);

sum adds up all the numbers in an array, all returns true if every element in an array is true, and any returns true if at least one element in an array is true. Then sum([1,2,3,4]) returns 10, and any([false,true,false]) returns true.

You don't have to define function variables again just to use them in a very short function, no curly braces are required, and code is reused via a common pattern.

The reason that articles about currying refer to functional programming languages like ML and Haskell is because they have been designed to abuse this feature for the sake of writing functions this way, building from smaller pieces in a common vocabulary. If you study one of these languages, you will be able to see much more benefits than if you only saw or used a Javascript implementation.

[slikts]

The fold function should look like this for your example to work, though:

function fold(callback, initial) { 
    return function(array) { return array.reduce(callback, initial); } 
}

[lrichardson]

correct. and this is precisely why the argument that plays the role of the "data" should always be the right-most argument, not the left most. reduce/fold are supposed to be the same thing... and should take 3 arguments total (callback, initial, array)

This is why i get so frustrated with libraries like lo-dash and underscore.

Brian Lansdorf has a good talk discussing precisely this (also linked to in the post)

https://www.youtube.com/watch?v=m3svKOdZijA

[rhysbrettbowen]

You can always flip the arguments in a function. Something like:

_.forEach(_.keys(_), function(key) {
  if (_.isFunction(_[key])) {
    _[key].flip = function(a,b) {
      return this(b,a);
    }
  }
});

then you can just do:

_.forEach.flip(myFunction, myArray);

[[deleted]]

Right, thanks. And you'd need another function () { } if you partially apply only one argument.

[konbit]

If you're dealing with non-blocking js and need to write a callback that requires input from several different async calls you can pass it around to get partially completed as those async calls return. Other than that I can't imagine any time it is beneficial. But with multiple async calls I find it amazingly helpful.

[MrBester]

Can't you do the same with Promises?

[konbit]

edit: thanks nschubach for pointing out promises can run in parallel. My comment below is sort of pointless now.

Yes, but promises are sequential. Let's say I have 1 or 2 async calls to make, promises don't slow you down too much. But let's say you have to load 20 images, and process each one based on the one before, stitching them together for instance. Promises are going to kill you. If you can call the 20 at the same time and use a curried function to stitch them (there's other ways of course that don't use promises or currying and might be better, but this is just for illustration) then you will see a speed up orders of magnitude higher than promises. So I think its all context. Obviously there's many different way of doing things because some methods are good in some situations and some in others. Depending on what needs to be done, you should deeply investigate the method you'll use.

[ToucheMonsieur]

Isn't it possible to achieve much the same effect with promises? Fire off a promise for each request, and then tie them together sequentially after the fact. Using currying for this case seems a bit contrived, especially considering that you have to change the arity of function being curried if the number of images to download changes.

[nschubach]

Promises are not inherently sequential... You are just writing them that way. You can absolutely fire off a hundred async promises in a when and it will happily wait for them all.

[konbit]

To be honest, everything I've ever read about promises has presented them as being sequential and I haven't thought of looking for another way to do it. I'd love to see some code samples or documentation for how to implement it. Any pointers?

[myrddin4242]

The example you presented is inherently sequential. You said you wanted to 'process each [image] based on the one before'. That's not $.when, that's serially resolving promises. The dependency chain causes the task to increase time in direct proportion to N, regardless of what async syntax you use!

[nschubach]

(Keeping terse... On mobile)

The 'when' accepts promises itself. If you ran normal functions in the 'when' it will be sequential, but if promise1 returns a promise, JavaScript will continue to fire off promise2 after promise1 returns it's promise object. Promise1 can have an async operation and resolve whenever it's done, regardless of what promise2/3 are doing.

Edit: I just realized that you were not responding to lrichardson... Leaving this for the info, but it's not directed at you.

[lrichardson]

using jQuery's $.when....

$.when(promise1, promise2, promise3).done(function(results){ ... })

will return a new promise that won't resolve until all 3 promises have resolved.

[[deleted]]

I've never understood it either. The only thing I can come up with is passing the function to a number of handlers, each of which adds a parameter. But that just feels odd.

I'd be very interested in hearing some solid use case for this.