Currying is about turning/representing a function which takes n inputs into n functions that each take 1 input. Partial application is about fixing some of the inputs to a function.

The motivation for partial application is primarily that it makes it easier to write higher order function libraries. For instance the algorithms in C++ STL all largely take predicates or unary functions, bind1st allows the library user to hook in non unary functions with a value bound. The library writer therfore does not need to provide overloaded functions for all algorithms that take unary functions to provide binary versions

Currying itself is useful because it gives you partial application anywhere you want it for free i.e. you no longer need a function like bind1st to partially apply.

But I can do the same thing (left-curry, right-curry, n-curry or partial application) by simply creating another named or anonymous function or closure that will forward the parameters to the original function (like tripler2) in most languages (even C.)

And the optimizer will look at that and promptly go on to something it can understand. Currying is a nice little trick for the end user, but has much better benefits from a language design standpoint. It’s really nice to handle all methods as unary A -> B where B may be another method.

It simplifies what methods you have to write to handle higher order functions. Your static analysis and optimization in the language only has one path to work with that behaves in a known manner. Parameter binding just falls out of the design rather than requiring hoops to do this common behavior.

As @jk. alluded to, currying can help make code more general.

For example, suppose you had these three functions (in Haskell):

> let q a b = (2 + a) * b

> let r g = g 3

> let f a b = b (a 1)

The function f here takes two functions as arguments, passes 1 to the first function and passes the result of the first call to the second function.

If we were to call f using q and r as the arguments, it’d effectively be doing:

> r (q 1)

where q would be applied to 1 and return another function (as q is curried); this returned function would then be passed to r as its argument to be given an argument of 3. The result of this would be a value of 9.

Now, let’s say we had two other functions:

> let s a = 3 * a

> let t a = 4 + a

we could pass these to f as well and get a value of 7 or 15, depending on whether our arguments were s t or t s. Since these functions both return a value rather than a function, no partial application would take place in f s t or f t s.

If we had written f with q and r in mind we might have used a lambda (anonymous function) instead of partial application, e.g.:

> let f' a b = b (x -> a 1 x)

but this would have restricted the generality of f'. f can be called with arguments q and r or s and t, but f' can only be called with q and r — f' s t and f' t s both result in an error.

MORE

If f' were called with a q'/r' pair where the q' took more than two arguments, the q' would still end up being partially applied in f'.

Alternatively, you could wrap q outside of f instead of inside, but that’d leave you with a nasty nested lambda:

f (x -> (y -> q x y)) r

which is essentially what the curried q was in the first place!

There are two key points about partial application. The first is syntactic/convenience — some definitions become easier and shorter to read and write, as @jk mentioned. ( Check out Pointfree programming for more about how awesome this is! )

The second, as @telastyn mentioned, is about a model of functions and is not merely convenient. In the Haskell version, from which I’ll get my examples because I’m not familiar with other languages with partial application, all functions take a single argument. Yes, even functions like:

(:) :: a -> [a] -> [a]

take a single argument; because of the associativity of the function type constructor ->, the above is equivalent to:

(:) :: a -> ([a] -> [a])

which is a function that takes an a and returns a function [a] -> [a].

This allows us to write functions like:

($) :: (a -> b) -> a -> b

which can apply any function to an argument of the appropriate type. Even crazy ones like:

f :: (t, t1) -> t -> t1 -> (t2 -> t3 -> (t, t1)) -> t2 -> t3 -> [(t, t1)]
f q r s t u v = q : (r, s) : [t u v]

f' :: () -> Char -> (t2 -> t3 -> ((), Char)) -> t2 -> t3 -> [((), Char)]
f' = f $ ((), 'a')  -- <== works fine

Okay, so that was a contrived example. But a more useful one involves the Applicative type class, which includes this method:

(<*>) :: Applicative f => f (a -> b) -> f a -> f b

As you can see, the type is identical similar to $ if you take away the Applicative f bit, and in fact, this class describes function application in a context. So instead of normal function application:

ghci> map (+3) [1..5]  
[4,5,6,7,8]

We can apply functions in an Applicative context; for example, in the Maybe context in which something may be either present or missing:

ghci> Just map <*> Just (+3) <*> Just [1..5]
Just [4,5,6,7,8]

ghci> Just map <*> Nothing <*> Just [1..5]
Nothing

Now the really cool part is that the Applicative type class doesn’t mention anything about functions of more than one argument — nevertheless, it can deal with them, even functions of 6 arguments like f:

fA' :: Maybe (() -> Char -> (t2 -> t3 -> ((), Char)) -> t2 -> t3 -> [((), Char)])
fA' = Just f <*> Just ((), 'a')

As far as I know, the Applicative type class in its general form would not be possible without some conception of partial application. (To any programming experts out there — please correct me if I’m wrong!) Of course, if your language lacks partial application, you could build it in in some form, but … it’s just not the same, is it? 🙂