Functional Programming Isn’t the Answer

When I worked at IBM, I met John Backus, the inventor of functional programming. I definitely didn't get it at the time, but have since become an evangelist.

This article makes several good points about FP and why everyone can benefit from having functional techniques in their recipe book.

But it's missing the key fact that introduces problems, which is that there is really no such thing as functional programming in toto because every program must rely on hidden values and have side effects in order to be useful. So functional, in a way, is a myth that we sustain in order to get the benefits he mentions, which are mostly bulletproofing and debug-ability.

In reality, all programs are imperative because the processor is imperative; it does only one thing at a time and in a certain order. Einstein said, "Make things as simple as possible, but no simpler," and this can be said of functional programming, too. Whenever there is a possibility of eliminating a closure, or using immutable, typed data, or composing functions into each other, we should consider the possibility of refactoring to a more functional style -- but that doesn't mean we should just do it. The trade off is that FP is more difficult to write and hides bugs better than imperative code. There are fewer bugs when you're done, but it's harder to get there.

One thing I've started to do in my own code is to declare, in the comments, whether a function is purely functional or if it relies on closures or globals. Having these "flags" at the top of every function shows me places where I might want to refactor to remove some of those potential holes.

Some good points made about the difference between using functional programming in a tasteful manner and treating it as a religion.