[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.