4 ms·

I've found the most critical difference between OO and FP to be state. Objects are stateful from the moment they are created until they are destroyed. FP is rem

I've found the most critical difference between OO and FP to be state. Objects are stateful from the moment they are created until they are destroyed. FP is remarkable for its general lack of side-effects - i.e. computations do not normally affect shared state. I believe this distinction is a critical one because an application with a lot of shared state is more difficult to scale than one without. As another poster pointed out, in a shared addressed space such as a desktop app, this isn't a concern. But if you want to scale an application across multiple address spaces, communicating and synchronizing the state of objects between these spaces tends to be difficult. So, my tendency is: Small and shared address space? Tend to use OO patterns and implementations. Big and distributed address space? Tend to use FP patterns and implementations. Note, I don't consider OO vs. FP a language choice – I consider it a programming paradigm choice.

fauigerzigerk 13y ago
The problem is that whether or not we have shared mutable state on a logical level is not for us to choose. It's ultimately a property of the task at hand. Pushing shared state onto the database doesn't make it go away. Workarounds like MapReduce or monads only help us defer the moment of truth. If shared mutable state is what users ultimately expect to see, these approaches are merely simulations of shared mutable state that exploit a time gap in users' perception. That gap is very brittle. Nightly batch windows become too short. Users expect real time updates leading to major redesigns of entire systems, like Google dropping MapReduce for their search index. But I think your point about state being the major difference between OO and FP is absolutely true. In OO systems, statefulness is the default everywhere. Nothing is formally known about state in OO system and that is a bad thing. We need state to be explicit and formally specified.

fauigerzigerk 13y ago

The problem is that whether or not we have shared mutable state on a logical level is not for us to choose. It's ultimately a property of the task at hand. Pushing shared state onto the database doesn't make it go away. Workarounds like MapReduce or monads only help us defer the moment of truth. If shared mutable state is what users ultimately expect to see, these approaches are merely simulations of shared mutable state that exploit a time gap in users' perception. That gap is very brittle. Nightly batch windows become too short. Users expect real time updates leading to major redesigns of entire systems, like Google dropping MapReduce for their search index. But I think your point about state being the major difference between OO and FP is absolutely true. In OO systems, statefulness is the default everywhere. Nothing is formally known about state in OO system and that is a bad thing. We need state to be explicit and formally specified.