Questioning functional programming

We’ve been tracking functional programming languages like Haskell and Erlang for a while, most recently watching the release of the Prags’ “Programming Erlang and the rapid progress Bryan, John, and Don are making on Real World Haskell. Leon Brocard drew my attention to The 10th ICFP Programming Contest. Others like Tim Bray have also been getting their hands dirty (Tim started quite a runtime-length war in blogs with his posts on “appalling” Erland performance analysing logfiles, with various languages and factions competing to improve the benchmark’s runtime in various languages).

The final report (PDF) has been released. It’s notable for two things: the fiendish complexity of the problem and the absence of functional programming languages in the final results. Top place went to a C++ program, with a Perl team right behind in second. In third place was “Team Celestial Badger” using OCaml and C++. In all there were 81 teams using C++, 67 using C, 66 using Haskell, 64 using Python, 52 using OCaml, 48 with Java, and 35 with Perl. Only 4 tried Erlang (the same number as used Delphi). Quoth the judges:

One thing that struck us during and after the contest, reading IRC channels and blog postings, was that many programmers don’t have a lot of confidence in their favourite (functional) language: when they realised that their implementation of the DNA machine was too slow, their first instinct
was often to switch to a “faster” language such as C. But
the problem wasn’t the language but algorithmic complexity:
a straight-forward Haskell implementation using the right
data structure (e.g. Data.Sequence [3]) would be fast enough
and outperform by several orders of magnitude an optimised
C implementation using a dumb data structure. So programmers should worry less about languages and more about
good old complexity.

As far as functional programming is concerned, we must
conclude that functional languages didn’t fare too well this
year (although in the Top 15 there were five users of OCaml
and three of Haskell). Better luck next year!

It says to me that we’re still in the early days of widespread adoption of functional programming. Like Ruby, which had tiny uptake until Rails and 37 Signals boosted it into the stratosphere, functional programming languages lack a reason to use them. Even those who advocate them aren’t comfortable enough with them to push on with them in the face of hard problems.

tags: