[cousin_it]

Maybe we're talking about slightly different things?

There are many interesting algorithms that are usually analyzed in an imperative setting, like in-place quicksort, Knuth-Morris-Pratt, or Gaussian elimination. There doesn't seem to be any benefit to analyzing them in an FP setting, because it's not easier and doesn't yield new insights.

It seems to me that the FP approach only really shines on algorithms that are "naturally tree-like". For example, I'm a big fan of Okasaki's work on purely functional data structures, and of Blelloch's work-depth model. But let's not oversell FP techniques as the foundation of all algorithm work.

[l_dopa]

Yes, we're talking about different things. I took the parent comment to mean that talking narrowly about "FP" as programming with pure functions isn't very useful any more. It may have made sense in the 90s when few widely-used languages had h.o.f, but that fight has pretty much been won.

The field that gave rise to FP has a lot to say about how we specify languages and their properties and how we prove things about programs in general. That includes languages with all kinds of effects: state, exceptions, concurrency, etc, and equally as imporant, mechanisms for abstraction and modularity. There's currently no other "foundation" for computation that lets us define these ideas formally.

In discussions of FP, the contributions of the field get reduced to "programming with functions".