I'm a Systems Reliability and DevOps engineer for Netdata Inc. When not working, I enjoy studying linguistics and history, playing video games, and cooking all kinds of international cuisine.
On your four listed benefits to FP, I'd contend that they aren't exactly as clear cut as many people make them out to be:
Functional code is easier to understand
This one isn't universally true, and it can actually be patently false for some people. Some aspects definitely are easier (for example, not needing to deal with mentally tracking the meaning of this in JS due to using functional constructs is a huge plus to understandability), but some of the core concepts of FP, like recursion, are actually pretty hard for some people to wrap their heads around.
There are fewer bugs
This isn't always true, and when it is true, it's usually a side effect of improved readability and testability. You can also run into a whole slew of bugs in FP that you're not as likely to encounter in OO, procedural, or other paradigms (recursion is a big offender here, though that's not so much FP as recursion itself).
The code is more compact
Not necessarily. Functional programming languages tend to have a more compact syntax than OO languages, but that's language design more than anything else. A lot of OO or procedural languages could be much more compact if they implemented some of the non-FP specific stuff found in certain FP languages (like pattern matching in Erlang). Certain operations are definitely more compact written in a functional manner (map and reduce for example), but some others are much smaller in an object-oriented or procedural implementation (for example, trial division is more compact in most mixed-paradigm languages when done in a procedural manner than a functional one).
Some even claim that it's easier to test and debug
The testing aspect is a mixed bag. You can much more easily mock-out components in FP code because dependency injection is a rather strict requirement of good functional code, but you can do just as well by making it a strict requirement in OO code. In contrast though, you may need to jump through hoops to make certain things realistically testable in functional code. Part of this is also a result of some higher profile FP languages having very good testing integrations as part of the base environment.
Debugging I'd say is more a side effect of the other aspects than anything else. Easily readable and efficiently concise code is usually easier to debug regardless of paradigm, and FP kind of forces you to avoid certain situations that are inherently hard to debug. It can be more challenging in some cases though, such as when dealing with a well written recursive function in a language with proper TCO.
Note that I'm not trying to discount your argument here. I agree that learning FP is a good way to broaden your horizons as a programmer (though I feel similar about OO, procedural, and most other paradigms), I just feel it's important to understand that most things people tout as benefits of a given paradigm are often have stipulations attached.
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.
On your four listed benefits to FP, I'd contend that they aren't exactly as clear cut as many people make them out to be:
This one isn't universally true, and it can actually be patently false for some people. Some aspects definitely are easier (for example, not needing to deal with mentally tracking the meaning of
thisin JS due to using functional constructs is a huge plus to understandability), but some of the core concepts of FP, like recursion, are actually pretty hard for some people to wrap their heads around.This isn't always true, and when it is true, it's usually a side effect of improved readability and testability. You can also run into a whole slew of bugs in FP that you're not as likely to encounter in OO, procedural, or other paradigms (recursion is a big offender here, though that's not so much FP as recursion itself).
Not necessarily. Functional programming languages tend to have a more compact syntax than OO languages, but that's language design more than anything else. A lot of OO or procedural languages could be much more compact if they implemented some of the non-FP specific stuff found in certain FP languages (like pattern matching in Erlang). Certain operations are definitely more compact written in a functional manner (map and reduce for example), but some others are much smaller in an object-oriented or procedural implementation (for example, trial division is more compact in most mixed-paradigm languages when done in a procedural manner than a functional one).
The testing aspect is a mixed bag. You can much more easily mock-out components in FP code because dependency injection is a rather strict requirement of good functional code, but you can do just as well by making it a strict requirement in OO code. In contrast though, you may need to jump through hoops to make certain things realistically testable in functional code. Part of this is also a result of some higher profile FP languages having very good testing integrations as part of the base environment.
Debugging I'd say is more a side effect of the other aspects than anything else. Easily readable and efficiently concise code is usually easier to debug regardless of paradigm, and FP kind of forces you to avoid certain situations that are inherently hard to debug. It can be more challenging in some cases though, such as when dealing with a well written recursive function in a language with proper TCO.
Note that I'm not trying to discount your argument here. I agree that learning FP is a good way to broaden your horizons as a programmer (though I feel similar about OO, procedural, and most other paradigms), I just feel it's important to understand that most things people tout as benefits of a given paradigm are often have stipulations attached.