3 ms·

If all the programs you write are like recipes, then imperative probably makes a lot of sense. Imperative is never a problem for small programs. It's when the

If all the programs you write are like recipes, then imperative probably makes a lot of sense. Imperative is never a problem for small programs. It's when they grow over time that they become more and more difficult to reason about. In the best case you manage the complexity with good architecture, refactoring and automated testing practices; in the worst case you end up with a program that is not worth changing because every bug fix introduces two new bugs. Functional programming allows breaking through that ceiling at the expense of a good deal more rigor.

SeanDav 11y ago
And yet the software industry survives and thrives with only niche use of functional programming at best... EDIT: To clarify. I am agreeing with the original author. If Functional Programming is as great as it is supposed to be it would have been eating everyone's lunch by now. It has been around forever, yet it remains quite niche. This indicates strongly that there must be underlying reasons it is not more popular.
- dasil003 11y ago
  How is that a rebuttal? I feel some unspoken axe to grind...
- Ericson2314 11y ago
  So what? Perhaps it would thrive even more if. Your argument does however explain why there is little pressure industry-wide to switch.
agumonkey 11y ago
There are low frequency systemic laws at play. Software reuse is still a myth. Large project don't see any benefit to invest into FP abstractions. It's not even business smart so far since you make a shit load of money from accidental complexity. Tools to manage tools to manage tools that makes you look pro. I know from experience that even in high skilled domains, IT shops and their client are probably only at 30% efficiency (6 monthes turnover means ~2 months of actual work, low quality one, before leaving). There are no forces at play that respond to the problem that FP solves.
smoyer 11y ago
I completely agree with your comment regarding functional programming becoming more useful as complexity increases - even the author's example is rife with functional programming. Think about the steps where the flour, baking powder and salt are added to the small bowl. The act of measuring these ingredients can easily be thought of as a pure function that takes a large amount of a raw ingredient, a measure and returns the correct amount. I'm sure there are many examples of pure functions implied but I have to say that I rather like working backwards - yes, a finished cake really is cooled after baking after batter that has been mixed. If you're putting together an engine in your garage you work the same way - nobody rebuilds their carburetor while it's mounted on the intake manifold (okay, not many people even have carburetors anymore). You build "assemblies" and create the larger whole from sub-assemblies. The same applies to virtually all manufacturing ... I spent a lot of time designing electronic systems that all started by populating circuit boards.

SeanDav 11y ago

And yet the software industry survives and thrives with only niche use of functional programming at best... EDIT: To clarify. I am agreeing with the original author. If Functional Programming is as great as it is supposed to be it would have been eating everyone's lunch by now. It has been around forever, yet it remains quite niche. This indicates strongly that there must be underlying reasons it is not more popular.

dasil003 11y ago
How is that a rebuttal? I feel some unspoken axe to grind...
Ericson2314 11y ago
So what? Perhaps it would thrive even more if. Your argument does however explain why there is little pressure industry-wide to switch.

agumonkey 11y ago

There are low frequency systemic laws at play. Software reuse is still a myth. Large project don't see any benefit to invest into FP abstractions. It's not even business smart so far since you make a shit load of money from accidental complexity. Tools to manage tools to manage tools that makes you look pro. I know from experience that even in high skilled domains, IT shops and their client are probably only at 30% efficiency (6 monthes turnover means ~2 months of actual work, low quality one, before leaving). There are no forces at play that respond to the problem that FP solves.

smoyer 11y ago

I completely agree with your comment regarding functional programming becoming more useful as complexity increases - even the author's example is rife with functional programming. Think about the steps where the flour, baking powder and salt are added to the small bowl. The act of measuring these ingredients can easily be thought of as a pure function that takes a large amount of a raw ingredient, a measure and returns the correct amount. I'm sure there are many examples of pure functions implied but I have to say that I rather like working backwards - yes, a finished cake really is cooled after baking after batter that has been mixed. If you're putting together an engine in your garage you work the same way - nobody rebuilds their carburetor while it's mounted on the intake manifold (okay, not many people even have carburetors anymore). You build "assemblies" and create the larger whole from sub-assemblies. The same applies to virtually all manufacturing ... I spent a lot of time designing electronic systems that all started by populating circuit boards.