Why Don't We Use Functional Programming Languages More?

October 11 2004

Jim Steel asked the question many of us have asked at some point, which I'll paraphrase as "why don't we use functional programming languages more?".

I once made a joke along the lines of "I encourage people to go into functional programming because it stops a lot of very clever, talented people from competing for my job opportunities". Functional programming and so on are of great theoretical interest to many people, but I'd suggest it's no surprise that most people who get sucked in do so when they start a post-grad degree. Our academic culture places "Greek letter mathematics" on a pedestal, and functional programming is often seen as the programming equivalent.

The problem is, a lot of the resulting work isn't very practical. For example, have you ever tried getting a stack backtrace from Haskell when you type head []? Hint: you don't get one, it basically just says "error". Whilst this might be acceptable for a two line Fibonacci generator, it is simply unacceptable whilst writing a large system - knowing the file and line number that caused an error is absolutely vital for debugging! Simon Peyton-Jones admits that lazy evaluation [which is the reason why Haskell can't really do stack backtraces], for example, isn't used that often. Despite the problems it causes and its relative lack of use, many Haskell people proclaim this feature as something which will cure all programming ills! And then of course FP languages have to resort to magic / hackery in the form of monads (Haskell) or the World type (Clean) to do I/O. Unfortunately I/O is sequenced and imperative in nature, and doesn't fit into the FP way of doing things very well. That's all well and good but most real-world tasks involve interacting with humans - which necessarily involves I/O - so trying to sweep such an issue under the carpet doesn't sit comfortably with me.

The (controversial?) opinion I've come to, is that the FP paradigm is fundamentally ill-equipped to deal with many practical problems. The world involves state, and state changes; just because that tends to throw a spanner into the theoretical works doesn't change the reality. This gap between the theory and practise is why people don't use functional programming languages. Whilst giving a talk on Converge at a seminar earlier this year, I was asked if I had looked at functional programming [indeed, I have - Converge's compile-time meta-programming features are heavily indebted to Template Haskell]. After my talk, I approached the questioner and asked if they were a functional programming fan. "I love such languages... Of course, I use Java for everything these days, because it's much easier".

But despite my cynicism, I actually feel that this shouldn't stop people working on FP itself, because some of the ideas that have resulted from such work are genuinely great. And that should encourage those of us who are non-FP'ers to look at their work and try and lift the best ideas from it into the areas we work. I believe this is the most realistic way for functional programming to "win" in some sense: by subverting the mainstream.

Link to this entry