Code Watch: Functional programming's smugness problem
April 16, 2012 —
(Page 1 of 2)
Related Search Term(s): functional programming
I like functional programming. I think it's going to drive code evolution through the next decade: languages will adopt more functional features, developers will adopt more functional techniques, and at some point, everyone will think that functional programming principles are the "natural" and clearest way to structure code.
But I am no longer sure of this scenario. Functional programming has a major problem that is evident to every mainstream programmer who has expressed an interest in learning what the excitement is about: Functional programmers are a bunch of smug jerks.
What are monads? "Monads are just monoids in the category of endofunctors! Ha ha, you don't understand any of those words, do you, stupid mainstream programmer?"
What are the design patterns that help structure functional systems? "Design patterns? Hey everyone, look at the muggle try to get the wand to work!"
What does functional programming have to offer to my team of programmers developing enterprise applications that have to live in a real-world ecosystem of data, interfaces and APIs? "You don't even see how... (long silence) If you knew category theory, you'd get it!"
Functional programmers have applied modern advances in type theory to yesterday's Smug LISP Weenie to generate today's Insufferable Haskell Prick. Just as LISP advocates carefully avoid the reality of decades of Scheme- and LISP-exposed CS students who happily left those languages behind, functional advocates carefully avoid acknowledging the programmers who have filed in to the functional programming room, listened to the conversation for a bit, read the literature, and quietly left.
What's incredibly frustrating about this is that many functional programming benefits are both clear and already being used by today's programming mainstream. Good programmers understand that immutable data is generally preferable to mutable, that functions that always return the same value for the same inputs are easier to work with than functions whose behavior depends on hidden state, and that complexity is best built with small functions that are focused on a specific purpose. And once programmers get a taste of lambda functions in combination with collection classes (the maps, flatMaps, finds and folds of the world), they won't want to go back.