I think part of the problem is that people say OOP but mean imperative programming and that imperative object-oriented programming seems to be the default nowadays. In reality, FP and OOP are more orthogonal than opposites, and it is possible to write very functional OOP, just not in Java*.
My observations, by the way, are based on the set of people I have worked with and, therefore, absolutely not statistically relevant, so here goes nothing.
Different developers value different things, and develop different skills and focus areas. Some developers seem to value most highly having code that just does what it is supposed to do. Since most of the code we are taught and exposed to out there is imperative, and maybe object-oriented, that's the current they usually follow. If they can just write one instruction after another and read that style all the same, bothering with things like function composition, purity, referential transparency, monads, etc. seems just over-complicating things. They can write programs in a style they are already familiar with and, at the end of the day, the program runs the same.
Some other developers seem to be looking for the Holy Grail of programming, a legendary piece of code so perfect that no mortal eyes can withstand. Having your code do what it is supposed to do is nice, but have you ever felt the joy of writing code that reads like poetry, and not like a recipe from your grandma's baking book? Each piece must be abstracted just at the right level and everything must be composable and testable. These programmers write code very differently that the first group, focusing a lot on how the code should do what it is supposed to do.
Some of these developers discover FP and look at the "horrid" code that developers in the first group write and think that the problem lies within (what they call) OOP itself. Afterwards they go around writing articles on how much OOP sucks. But it is fair to say that others just figure out how to write pleasant imperative code.
However the problem is that imperative OOP is the default, so programmers that don't (not yet at least) have a large interest in how the code is supposed to do things stay in this sphere, while some of the developers most focused on the how feel attracted to more declarative paradigms and, not surprisingly, find a lot of like-minded programmers in that sphere.
Basically, my point is that FP forces you to think in a different way about coding than the default, so people that think more about how code should be written are more likely to make the jump. I believe that if declarative functional programming was the norm, we'd see a lot more sloppy FP and articles saying how dangerous FP is and that OOP is the right way.
* The last line of Java I wrote was in Java 1.8, for all I know this assertion could be incorrect nowadays.
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.
I think part of the problem is that people say OOP but mean imperative programming and that imperative object-oriented programming seems to be the default nowadays. In reality, FP and OOP are more orthogonal than opposites, and it is possible to write very functional OOP, just not in Java*.
My observations, by the way, are based on the set of people I have worked with and, therefore, absolutely not statistically relevant, so here goes nothing.
Different developers value different things, and develop different skills and focus areas. Some developers seem to value most highly having code that just does what it is supposed to do. Since most of the code we are taught and exposed to out there is imperative, and maybe object-oriented, that's the current they usually follow. If they can just write one instruction after another and read that style all the same, bothering with things like function composition, purity, referential transparency, monads, etc. seems just over-complicating things. They can write programs in a style they are already familiar with and, at the end of the day, the program runs the same.
Some other developers seem to be looking for the Holy Grail of programming, a legendary piece of code so perfect that no mortal eyes can withstand. Having your code do what it is supposed to do is nice, but have you ever felt the joy of writing code that reads like poetry, and not like a recipe from your grandma's baking book? Each piece must be abstracted just at the right level and everything must be composable and testable. These programmers write code very differently that the first group, focusing a lot on how the code should do what it is supposed to do.
Some of these developers discover FP and look at the "horrid" code that developers in the first group write and think that the problem lies within (what they call) OOP itself. Afterwards they go around writing articles on how much OOP sucks. But it is fair to say that others just figure out how to write pleasant imperative code.
However the problem is that imperative OOP is the default, so programmers that don't (not yet at least) have a large interest in how the code is supposed to do things stay in this sphere, while some of the developers most focused on the how feel attracted to more declarative paradigms and, not surprisingly, find a lot of like-minded programmers in that sphere.
Basically, my point is that FP forces you to think in a different way about coding than the default, so people that think more about how code should be written are more likely to make the jump. I believe that if declarative functional programming was the norm, we'd see a lot more sloppy FP and articles saying how dangerous FP is and that OOP is the right way.
* The last line of Java I wrote was in Java 1.8, for all I know this assertion could be incorrect nowadays.