First we have to agree on what FP style even means. For some it means chaining collection operations so "one line of code" solves an entire problem. This is n

First we have to agree on what FP style even means. 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. 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? 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. 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. 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. 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.