FP is not about eliminating side effect at all, because a software that does not has any side effect has no use at all. Instead, FP is about making as much area of your code to be pure function so that they are predictable and consistent, while allow only specific module to be impure, i.e. having side effect.
I would think so, yes. You find that most Smalltalk-inspired OOP advocates tend to view sharing of data as a bad thing. Instead, data is private to an object, and you just tell the object what you want it to do (by sending it a message or invoking a method). The object then induces local mutations to itself. It's still not technically a pure function, but this flavor of OOP follows the spirit of not mutating a shared external state. Because that's what makes programs hard to change over time.
A pure function has additional benefits like thread safety.
Now I got it !
Last question, why do we have to do this ?
FP is not about eliminating side effect at all, because a software that does not has any side effect has no use at all. Instead, FP is about making as much area of your code to be pure function so that they are predictable and consistent, while allow only specific module to be impure, i.e. having side effect.
.. So, pure function could also be a priority for OOP no ?
I would think so, yes. You find that most Smalltalk-inspired OOP advocates tend to view sharing of data as a bad thing. Instead, data is private to an object, and you just tell the object what you want it to do (by sending it a message or invoking a method). The object then induces local mutations to itself. It's still not technically a pure function, but this flavor of OOP follows the spirit of not mutating a shared external state. Because that's what makes programs hard to change over time.
A pure function has additional benefits like thread safety.
Ahah thread.. I'm doing PHP :(