Follow-up to “Functional Programming Doesn’t Work”

Not surprisingly, Functional Programming Doesn’t Work (and what to do about it) started some lively discussion. There were two interesting “you’re crazy” camps:




The first mistakenly thought that I was proposing fixing problems via a judicious use of randomly updated global variables, so every program turns into potential fodder for the “Daily WTF.”




The second, and really, the folks in this camp need to put some effort into being less predictable, was that I’m completely misunderstanding the nature of functional programming, and if I did understand it then I’d realize the true importance of keeping things pure.




My real position is this: 100% pure functional programing doesn’t work. Even 98% pure functional programming doesn’t work. But if the slider between functional purity and 1980s BASIC-style imperative messiness is kicked down a few notches—say to 85%—then it really does work. You get all the advantages of functional programming, but without the extreme mental effort and unmaintainability that increases as you get closer and closer to perfectly pure.




That 100% purity doesn’t work should only be news to a couple of isolated idealists. Of the millions of non-trivial programs ever written—every application, every game, every embedded system—there are, what, maybe six that are written in a purely functional style? Don’t push me or I’ll disallow compilers for functional languages from that list, and then it’s all hopeless.




“Functional Programming Doesn’t Work” was intended to be optimistic. It does work, but you have to ease up on hardliner positions in order to get the benefits.