I'm currently doing a Functional Programming course and I'm quite amused by the concept of higher-order functions and functions as first class citizens. However, I can't yet think of many practically useful, conceptually amazing, or just plain interesting higher-order functions. (Besides the typical and rather dull map, filter, etc functions).

Well, monads follow, and then higher order functions over monads follow from that. It is turtles all the way!
–
Don StewartApr 26 '11 at 19:53

4

Very nice answer. Some of the "control structures" people have come up with are quite unconventional but spectacularly useful. A great example that comes to my mind is quickCheck - a control operator that runs the supplied function several times with arbitrary inputs attempting to make it fail. It's such a simple concept, and higher-order functions (and type classes) make it equally simple to use. Just quickCheck $ \n xs -> length (take n xs) <= n and watch (that one's false, BTW, for negative n - an easy oversight to make, but quickCheck catches it easily).
–
mokusApr 27 '11 at 13:49

2

Another one that just came to mind (it didn't immediately because I tend to take it for granted) is 'forkIO', or anything else having to do with concurrency. Spawning a thread is such a useful higher order function that people even use it in C, despite the language's lack of any special support for them. Just look at the type of, say, pthread_create. HOFs are so useful that people are willing to put up with defining parameter structs, fiddling with pointers to them, usually manually managing the memory for them, and casting to and from void *, just to be able to use them in C.
–
mokusApr 29 '11 at 14:42

"life is boring when it's first order." Well, when you desugar an imperative language's control structure through it's semantics, you end up with something higher order, but you're hard wired into a certain instantiation of the control structure (namely, the range of primitives which the language provides). Higher order behavior lets you grab this directly. And (as you know), you can prove that anything that can be done with loops can be done with HOFs, making higher order programming an extension of (typical) imperative programming.
–
Kristopher MicinskiSep 25 '12 at 1:15

Many techniques used in OO programming are workarounds for the lack of higher order functions.

This includes a number of the design patterns that are ubiquitous in functional programming. For example, the visitor pattern is a rather complicated way to implement a fold. The workaround is to create a class with methods and pass in an element of the class in as an argument, as a substitute for passing in a function.

The strategy pattern is another example of a scheme that often passes objects as arguments as a substitute for what is actually intended, functions.

Similarly dependency injection often involves some clunky scheme to pass a proxy for functions when it would often be better to simply pass in the functions directly as arguments.

So my answer would be that higher-order functions are often used to perform the same kinds of tasks that OO programmers perform, but directly, and with a lot less boilerplate.

This consumes an Int and then consumes that many more Ints before yielding their sum. This can be thought of as a function that takes arbitrarily many arguments, constructed without any language magic, just higher order functions.

Functions in data structures are a very powerful tool that was not part of my vocabulary before I started doing Haskell.

Its Return accum in the first branch. Also, I find it a bit dirty that the first consumed element as a semantic so different from the other ones. I would rather have made the length a parameter of subStream.
–
gascheApr 26 '11 at 20:03

@gasche, thanks fixed. Also I agree that it's dirty -- the point was that the "signature" of this "function" can depend on its parameters, showing the power of a function-in-data-structure construction.
–
luquiApr 27 '11 at 0:02

Higher-order functions are also required for currying, which Haskell uses everywhere. Essentially, a function taking two arguments is equivalent to a function taking one argument and returning another function taking one argument. When you see a type signature like this in Haskell:

f :: A -> B -> C

...the (->) can be read as right-associative, showing that this is in fact a higher-order function returning a function of type B -> C:

f :: A -> (B -> C)

A non-curried function of two arguments would instead have a type like this:

f' :: (A, B) -> C

So any time you use partial application in Haskell, you're working with higher-order functions.

Given two functionals f, g :: (Integer -> Bool) -> Int, then equal f g decides if f and g are (extensionally) equal or not, even though f and g don't have a finite domain. In fact, the codomain, Int, can be replaced by any type with a decidable equality.

The code Escardó gives is written in Haskell, but the same algorithm should work in any functional language.

You can use the same techniques that Escardó describes to compute definite integrals of any continuous function to arbitrary precision.

One interesting and slightly crazy thing you can do is simulate an object-oriented system using a function and storing data in the function's scope (i.e. in a closure). It's higher-order in the sense that the object generator function is a function which returns the object (another function).

My Haskell is rather rusty so I can't easily give you a Haskell example, but here's a simplified Clojure example which hopefully conveys the concept:

I don't think you can say it simulates object-oriented programming. It depends on your definition of OOP: is inheritance (open recursion) a requirement or not? If it is, then what you shown is not an object, just a common form of state hiding. If it isn't, then what you shown is an object (and not a simulation thereof), only following an object protocol which is not standardized by the language.
–
gascheApr 26 '11 at 17:12

@gasche - sure, this is only a simplified example. but if you wanted to add inheritance too it would be easy - e.g. you could do prototype-based inheritance with method implementations stored inside a hash table (which would also be a nice example of first-order functions stored in a data structure for the OP!)
–
mikeraApr 26 '11 at 17:23

Not really easy in Haskell, as it's very strict about type safety and has no intrinsic universal notion of subtyping. Using inheritance is awkward at best when the language provides no built-in means for, e.g., deciding whether one type can be (safely and automatically) substituted for another type. Otherwise, records of functions in Haskell make a very serviceable, if minimalist, prototype-based object system. This is of course no obstacle for languages with dynamic typing or built-in subtyping.
–
C. A. McCannApr 26 '11 at 19:53

Haskell prefers to do inheritance-like things with typeclasses. See the various numeric type classes and instances, for example.
–
PhobMay 13 '11 at 17:55

Please do not perpetuate that myth. Typeclasses are not for inheritance-like things, and are in fact wildly inappropriate for such a task. A simple functor is sufficient.
–
nomenJun 7 '13 at 14:10

Here's a pattern that I haven't seen anyone else mention yet that really surprised me the first time I learned about it. Consider a statistics package where you have a list of samples as your input and you want to calculate a bunch of different statistics on them (there are also plenty of other ways to motivate this). The bottom line is that you have a list of functions that you want to run. How do you run them all?

There's all kinds of higher order goodness going on here, some of which has been mentioned in other answers. But I want to point out the '$' function. When I first saw this use of '$', I was blown away. Before that I hadn't considered it to be very useful other than as a convenient replacement for parentheses...but this was almost magical...

One thing that's kind of fun, if not particularly practical, is Church Numerals. It's a way of representing integers using nothing but functions. Crazy, I know. <shamelessPlug>Here's an implementation in JavaScript that I made. It might be easier to understand than a Lisp/Haskell implementation. (But probably not, to be honest. JavaScript wasn't really meant for this kind of thing.)</shamelessPlug>

It’s been mentioned that Javascript supports certain higher-order functions, including an essay from Joel Spolsky. Mark Jason Dominus wrote an entire book called Higher–Order Perl; the book’s source is available for free download in a variety of fine formats, include PDF.

Ever since at least Perl 3, Perl has supported functionality more reminiscent of Lisp than of C, but it wasn’t until Perl 5 that full support for closures and all that follows from that was available. And ne of the first Perl 6 implementations was written in Haskell, which has had a lot of influence on how that language’s design has progressed.

Examples of functional programming approaches in Perl show up in everyday programming, especially with map and grep:

There’s a lot more than this, but this is just a taste. Closures make it easy to create function generators, writing your own higher-order functions, not just using the builtins. In fact, one of the more common exception models,

try {
something();
} catch {
oh_drat();
};

is not a built-in. It is, however, almost trivially defined with try being a function that takes two arguments: a closure in the first arg and a function that takes a closure in the second one.

Perl 5 doesn’t have have currying built-in, although there is a module for that. Perl 6, though, has currying and first-class continuations built right into it, plus a lot more.