[spacetraveler11]

Learning generalized concepts of FP just make a lot of sense IMO. Knowing that you can map all functors the same way wether it's an Optional, List, Future or Either is a useful tool to have. Using it in a language with syntactic sugar to compose map and flatMap (>>= in Haskell) operations helps to write clean code a lot. For me, solving problems in a functional way is not always as intuitive as the imperative approach but the end result is usually worth it. That said, FP can become a complex mess if your engineers are too dogmatic about it and bringing on new people who aren't as much into FP is almost impossible then in my experience.

[Akronymus]

IME it is much easier to start with FP and later on introduce OOP rather than the other way around.

And yeah, sometimes stepping down into mutability and such is necessary for performance.

[zelphirkalt]

Yes, that is because in FP you limit yourself in what you are allowed to do. You refrain from doing things like mutating state. In OOP you do it all the time and that breaks assumptions about functions. If you then want to do something FP inside that OOP code, you will get impure functions, which do not compose well, because whatever part of the system you interact with from your FP part, you will have lots of side effects being triggered.

[kaba0]

I’m not sure FP limits you in any way. And I’m not just talking about Turing equivalence.

When you are programming in FP, you are describing the program from another POV - taking the IO monad as an example, it just constructs a “list” of steps that should be taken at a given point vs just listing the steps in the program itself.

In pure FP languages, immutability is enforced due to you describing a given state - it simply doesn’t make sense to change something there.

[zelphirkalt]

You are correct in general about FP. I am talking about introducing FP in an existing OOP program though. You might want to use existing parts, but they are usually all impure, with lots of side effects. Any function in which you use those existing parts will be impure as well, unless you resort to things like IO monad. However, that makes it more complicated to implement things. You are building another layer of protection from the existing code and its state mutations everywhere.

[Akronymus]

I was actually talking about learning, rather than introducing to an existing codebase. But good points anyways.