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.