Recently I read a blog post titled “Functional Programming Is Not Popular Because It Is Weird”. I strongly disagree with the assessment and Twitter was too short for an answer, hence this blog post :-)
The blog post says that “Writing functional code is often backwards and can feel more like solving puzzles than like explaining a process to the computer”. I don’t agree at all, and I think this is simply a result of seeing functional programming in imperative programming terms. The first thing that comes to mind is that programming should not feel like “explaining a process” to the computer. Why should it? Imperative programming is centred around the process, the how. Functional programming is more focused on the what (which indeed is backwards compared to imperative, but I don’t think it’s backwards for humans).
Second, I think the recipe example is terrible and doesn’t show anything about the two styles of programming. The point of reading a program is not to be able to follow it step by step and produce the correct result (the computer does that), it’s about understanding the intent. Food recipes are about mixing things and obtaining the result. Programming is not about mixing things. In fact, the easier to separate and recombine they are, the better. This is very unlike a recipe.
Third, there is the “Imperative languages have this huge benefit of having implicit state. Both humans and machines are really good at implicit state attached to time”. Hahaha, what? State is the source of many, many problems in programming. Avoiding state, or at least separating the state-juggling bits, generally makes for better programs. Humans are terrible at keeping state in their minds, or understanding how a certain state was reached, or realising what produced changes in the state. To give an more concrete example of this: the post claims that “you know that after finishing the first instruction the oven is preheated, the pans are greased and we have mixed a batter”. No, you don’t. In a real program, you would be reading the source code for the second point, and it wouldn’t be obvious what the current state is at that moment. You would have to read, understand and play in your head the whole first point (and remember that, in real programs, there would be many ways to reach point 2, yikes!). And when anyone changed the first point, suddenly your understanding of the second point would be wrong, and you wouldn’t even know because the second point’s source code hasn’t changed. That is one of the reasons why state is generally best avoided.
The C++ example using templates as a functional language I’ll just skip as I don’t think is relevant at all for real functional programming. But right after, the author claims “I spend too much time trying to figure out how to say things as opposed to figuring out what to say”. I can relate to this while I was learning functional programming, but that’s entirely normal: you are, in a way, re-learning how to program. Many of your instincts and mental tools aren’t valid any more, and in some sense you have to start over. It’s frustrating, but the fact that it’s hard means that you’re being forced to think in a different, and in my view better, way.
Finally, at the end there’s “if functional programming languages want to become popular, they have to be less about puzzle solving”. If it wasn’t hard for imperative programmers to learn it, it wouldn’t be a different style, it would simply be a different syntax. No point in learning it! The reason why it feels like “puzzle solving” is because it’s different, not because it’s hard.
Now, I’m not saying functional programming is the best tool for every single problem, but most gripes imperative programmers have about functional programming are about “it’s different”, whether they realise it or not. Don’t be afraid to learn functional programming when it seems hard: that’s the whole point, you are learning a different way to solve problems!