Functional programming lies

I like functional programming. A lot. I find it an extremely natural mode of thinking in many respects, and even in imperative programming a sprinkling of functional support helps a lot. There are many practical advantages to it as a discipline.

So why are some of the main reasons advocated by people who don’t know what they’re talking about (a category in which I do find myself grouped more often than I’d like) complete lies?

In particular:

“Because Haskell is a pure language the compiler can automatically memoize functions for you”.

No it can’t. It would be nice if it could magically infer when it was able to do so, but it doesn’t. Lazy evaluation causes enough memory issues without automatically memoizing things. I’m not aware of any Haskell compiler which does this, and GHC certainly doesn’t. (As an added annoyance, there’s no nice way of memoizing a function at all).

A related lie is common subexpression elimination. Haskell doesn’t have side effects, so you don’t need to worry about that aspect of CSE, but it does have lazy evaluation. Partially evaluating a term has the ‘side effect’ of increasing its memory footprint significantly, so CSE can result in some very large space leaks if you’re not careful.

Other more minor lies include implicit parallelisation – it’s not there yet, there are some suggestions (which I’ve not personally evaluated so cannot comment on the veracity of) that it’s not nearly as plausible as we’d like it to be.

Advocacy isn’t a bad thing, but please stick to the facts.

This entry was posted in programming and tagged on by .

One thought on “Functional programming lies

  1. Pingback: Best of | David R. MacIver

Comments are closed.