Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The answer to this question depends on how you define OOP and FP. I think the answer is "sort of".

The problem with OOP is that it encourages the proliferation of mutable state. If each object has mutable state, then a large object-oriented program has distributed mutable state, potentially in hundreds of different silos. Problems like concurrency become impossible to reason about.

FP encourages the careful sequestration of mutable state. It's false to say that FP outlaws it entirely, since it's hard to do anything useful without side effects. However, functional style limits and sequesters mutable state to such a degree that it's usually easy to reason about what side effects are happening.



"The problem with OOP is that it encourages the proliferation of mutable state."

It should be pointed out that this is a characteristic of the languages and not actually OOP. The original insight, something like "Hey, let's bundle together data structures and their methods into one unit, and communicate with them via messages!" (which got turned into "method calls") actually has nothing to say about mutability. You can and people have build object systems based on immutable objects.

The implications of doing that are deep and profound and color the rest of the system and are beyond the scope of this posting, but it can be done.


This is a great point. Given how I tend to get annoyed when people reflexively associate static typing with Java, I shouldn't be so quick to make the leap from OOP to mutable state. Many OOP concents (e.g. inheritance) are mutability-agnostic.


Yes. And FP may even go so far, and uphold this segregation at the language level. I.e. Haskell's type system and IO Monad.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: