Mostly adoption is driven by need. Many devs have checked out FP, probably in their language of choice, and like the idea but without a huge obvious benefit or need it solves, they'll stick with their existing paradigm.
I myself have picked up a few FP techniques in JS/TS but see no real benefit of full adoption. Still, I teach the concepts to new Jrs in the hope they'll use them when they simplify things.
I think many JS devs easily pick up .map() and .reduce() but find less benefit in full-on function composition techniques - at least on the server side.
Would you say that the language support and features is a big deciding factor here? There is a huge difference between applying some FP concepts and truly designing/implementing applications using FP
For example you can do FP with PHP, but with so many trade-offs and considerations that might make adoption very difficult and not really valuable for the developers.
The biggest factor for my team is the pressure of forward progress. The amount of time needed to teach a dev Haskell and a whole different approach to development isn't worth it from a business perspective.
On the other hand, I can teach any dev to use specific FP techniques in their existing languages in a couple hours.
Until there's a real use case where a fully FP language is the best and fastest tool for the job, or until some other languages become better at true FP development, this is where we land.
We could change this but it goes back to academia where we teach (incorrect) OOP as classical inheritance. It's hard enough to get Jrs to stop typing "class" or thinking in that way.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Mostly adoption is driven by need. Many devs have checked out FP, probably in their language of choice, and like the idea but without a huge obvious benefit or need it solves, they'll stick with their existing paradigm.
I myself have picked up a few FP techniques in JS/TS but see no real benefit of full adoption. Still, I teach the concepts to new Jrs in the hope they'll use them when they simplify things.
I think many JS devs easily pick up .map() and .reduce() but find less benefit in full-on function composition techniques - at least on the server side.
Would you say that the language support and features is a big deciding factor here? There is a huge difference between applying some FP concepts and truly designing/implementing applications using FP
For example you can do FP with PHP, but with so many trade-offs and considerations that might make adoption very difficult and not really valuable for the developers.
The biggest factor for my team is the pressure of forward progress. The amount of time needed to teach a dev Haskell and a whole different approach to development isn't worth it from a business perspective.
On the other hand, I can teach any dev to use specific FP techniques in their existing languages in a couple hours.
Until there's a real use case where a fully FP language is the best and fastest tool for the job, or until some other languages become better at true FP development, this is where we land.
We could change this but it goes back to academia where we teach (incorrect) OOP as classical inheritance. It's hard enough to get Jrs to stop typing "class" or thinking in that way.