Finished (functional) code is like a finished theorem …
I read from Paul Graham’s “On Lisp”
| Quote: |
|
Finished code, like a finished theorem, often covers up a lot of trial and error. So don’t worry if you have to write several versions of a macro. |
That pretty much captures the difficulty that functional programming causes practising software engineers. My PhD thesis in Information Theory is full of definitions, theorems and proofs. It has been over 10 years since I did that work, and I believe it would take me quite a while to understand it now. A finished theorem does cover up a lot of trial and error.
In fact, one of the debates I remember having with my PhD advisor was that I wanted to put in the trial and error reasoning that led to the results in the published work because it would help the reader understand where these came from. He advised against it, because that is just not the mathematical way. I guess that is one reason I came to industry 
Even in academia, best teachers motivate a theorem with trial-and-error reasoning. I love the cold, minimalist, abstract beauty of a well-written mathematical proof as much as the next guy, but the human process that led to it is often messy trial and error. By totally hiding it, we are covering the steps that can help the next guy trace the reasoning.
The academic popularity of functional programming style reflects this preference for the minimalist mathematical proof. In the world of team software development, the priority is not minimalist beauty but on understandable code. A mathematical proof, once finished, is finished - strictly that is not true, but at least that is the usual assumption. But software is an organic evolving system; it is never finished.
My preferred programming style is to make it blindingly obvious to the next reader of the program what is going on. If the person has to spend hours with paper and pencil (as often happens in figuring out a mathematical proof), that portion of the software will probably never be touched.
If we don’t want write-only code, we have to recognize the needs of the next programmer who reads a piece of code. If Paul Graham’s comment about macro design reflect the functional programming mindset (I believe it does), it explains why FP not widely embraced by the mainstream. I recognize that there are a lot of good ideas in there, and I recognize some of those ideas have made it to popular programming languages. But FP as a programming paradigm needs to get out of the “finished theorem” mindset, in my opinion, if it has to be embraced by the broader software industry.