First we have to agree on what FP style even means.<p>For some it means chaining collection operations so "one line of code" solves an entire problem. This is not unlike the regexp wizard who can perform miracles with a regular expression which is incomprehensible to most other developers.<p>The above is what turns many people off from FP. As another commenter said, "what's wrong with a loop"? Indeed, accessibility matters; and if your team and new arrivals are not in that mindset, it's like a new language; and they already know a "language" and believe they are getting work done. Why complicate things?<p>I don't believe real FP is about doing these super concise expressions which can take considerable time to comprehend. I think FP is really more about pushing effects and mutations to edges, purifying (and simplifying) intermediate steps/functions, and using simple data structures.<p>The huge selling point of this kind of FP is in testability. When 90% of your code is pure and operates on simple data structures, testing each function is a breeze. No more do you need layers of setup and mocking. You don't even need full objects. If you're testing for a valid phone number in a person "record", you need only pass in a person: { phone: '12343241' }. All the rest of the crap which you would normally have to deal with, just to test this one thing, evaporates.<p>It does mean you end up with a LOT more functions. Then code organization and naming becomes a more significant challenge. But the end result, I believe, is still very much worth it.<p>And from my two recent experiences bringing this approach to OOP teams, I have found that after a brief period of fear and uncertainty, they end up adopting it enthusiastically.
I wrote something on this idea as well referring to it as Debug Driven Development[0].<p>Similar to TDD or Domain Driven Design (DDD) we should aim to write code that is easy to debug. Store intermediate values in a pipeline in variables, store predicates in a variable with a human readable name, and avoid in lining complex function calls.<p>There are other techniques that serve this purpose and additional reasons than what this article explores of how or why this is helpful.<p>[0] <a href="https://sambernheim.com/blog/debug-driven-development" rel="nofollow">https://sambernheim.com/blog/debug-driven-development</a>
When you program on a team choices like using procedural vs OOP vs FP aren't up to you since they impact others. You should be coding for your maintenance programmer, the person who will come behind you, need to quickly understand the code and make changes or bug fixes. The maintenance coder may be you, it might be a team mate or it might be someone yet to join the company.<p>Use your own time or projects foe exploring programming styles.
A critique of "mainstream" FP:<p><a href="https://www.reddit.com/r/DilbertProgramming/comments/qg99f0/functional_programming_is_dysfunctional_givvitup/" rel="nofollow">https://www.reddit.com/r/DilbertProgramming/comments/qg99f0/...</a>
One of the nontechnical advantages of FP focused languages is that writing FP style code won't frighten or confuse anyone by itself. (But of course team maintained FP code should still be held to standards about clarity, maintainability, excess cleverness etc)
If you had to resubmit your code patch four times before you reached version number five, you'd quickly become a persona non grata on your team. Doubly so if every iteration of code review takes a day and it takes you a week to make a trivial 5-line change.