4 ms·

The problem with OOP is not just with poor implementations and inheritance models (e.g. Java) but that state encapsulation is actually bad and cements complexit

by ummonk 5y ago

The problem with OOP is not just with poor implementations and inheritance models (e.g. Java) but that state encapsulation is actually bad and cements complexity. The real goal should be to untangle state and decouple it from computations by putting it all in global shared state (e.g. SQL, Redux, ECS frameworks, etc.) while using stateless functional computations to compute changes to the global state. Pure functions are composable in a way that objects simply aren’t.

ferdowsi 5y ago
The opposite end of OOP is the functional purist world where "color = blue when hovering over button" becomes 10 levels of boilerplate indirection in order to update global state and receive changes using actions/reducers/containers/memoizers. It's just substituting one type of needless, brittle complexity for another.
- mountainriver 5y ago
  Exactly and the functional way is harder for humans to grok
- ummonk 5y ago
  That’s fair and as someone who has that same frustration with it I realized Redux might not be the best example precisely for this reason. I’d argue though that the problem here is the premature abstraction of encapsulating state in actions/reducers/memoizers. This sort of thing would be way more natural in an ECS framework.
- z5h 5y ago
  Functional purist here (mostly Elm), and I have very few problems that arise from the paradigm. Also fewer bugs than pretty much any software I use or deal with.
jayd16 5y ago
Are you saying we should remove local state? If you aren't then why is that better organized than object state?
- pishpash 5y ago
  Few people are organized and use encapsulation to store things where they are easily retrieved. Most people are messy and encapsulate to hide junk under the couch. It's the code monkeys, stupid. Given a powerful enough machinery most code will look like junk. That's why some "beautiful" languages today tie your hands and dumb everything down so you aren't free to do as you like, whereas assembly was just fine 40 years ago.
AnimalMuppet 5y ago
How is state encapsulation bad? Encapsulated state means that only a very few functions can access/change that state. Non-encapsulated state means that any code in the entire executable can change that state. How is that better? > The real goal should be to untangle state and decouple it from computations by putting it all in global shared state (e.g. SQL, Redux, data oriented game frameworks, etc.) while using stateless functional computations to compute changes to the global state. I kind of presume that you're in a single-threaded world. Shared mutable state plus multithreading is a recipe for disaster.
- sodapopcan 5y ago
  In functional languages you can still ensure that only certain functions can change certain parts of the state. The big idea is that state is isolated. You can actually write functional code that looks a lot like OO code (essentially just calling `foo(thing)` instead of `thing.foo()`) but because state is isolated, you know that nothing is changing behind the scenes. It may not seem much, but it's actually really freeing to not have to think about that stuff anymore. Same thing with immutability. I was skeptical of functional for years and was actually a big OO zealot. I finally brought myself to give functional a serious go over 1.5 years ago. I now write it professionally and don't miss OO even a tiny bit. It's really just something you have to try and have an open mind about. I actually still find myself sometimes thinking, "Crap, maybe I should make a copy of this in case something else tries to touch... OH WAIT! IMMUTABILITY! I'M SAFE!" It's a really nice feeling :)
  - AnimalMuppet 5y ago
    Let me separate out immutability for a moment. If I don't have immutability, then if I can call foo(thing), then I can write bar(), and then call bar(thing). Bar can now alter thing. So my encapsulation can be broken by someone just writing a function. (This is the same problem that C had with structs - anyone could write a function to alter the data in your struct, and thereby put it in an inconsistent state.) Now, with something like C++, you can still do that. You have to go to thing, though, and write a new thing.bar(). It therefore becomes much clearer that bar() may break the consistency guarantees of thing. So I don't think that just functional gives you the guarantees that OO encapsulation does. Now, immutability changes things... a little bit. But with immutability, the problem only moves, it doesn't go away. Someone can now write a bar() that returns a new/altered thing, and then pass it to me. I can still get a thing that is in a state that violates the rules for what a thing is supposed to be. And, once again, the same thing can happen with OO. It's just that, if it happens, you have a lot less code to look through to try to figure out how and where it happened. You may have noticed that I care a lot about data being in a consistent, valid state. If you don't care about that, then my arguments may not resonate with you.

by ummonk 5y ago

ferdowsi 5y ago

The opposite end of OOP is the functional purist world where "color = blue when hovering over button" becomes 10 levels of boilerplate indirection in order to update global state and receive changes using actions/reducers/containers/memoizers. It's just substituting one type of needless, brittle complexity for another.

mountainriver 5y ago
Exactly and the functional way is harder for humans to grok
ummonk 5y ago
That’s fair and as someone who has that same frustration with it I realized Redux might not be the best example precisely for this reason. I’d argue though that the problem here is the premature abstraction of encapsulating state in actions/reducers/memoizers. This sort of thing would be way more natural in an ECS framework.
z5h 5y ago
Functional purist here (mostly Elm), and I have very few problems that arise from the paradigm. Also fewer bugs than pretty much any software I use or deal with.

jayd16 5y ago

Are you saying we should remove local state? If you aren't then why is that better organized than object state?

pishpash 5y ago
Few people are organized and use encapsulation to store things where they are easily retrieved. Most people are messy and encapsulate to hide junk under the couch. It's the code monkeys, stupid. Given a powerful enough machinery most code will look like junk. That's why some "beautiful" languages today tie your hands and dumb everything down so you aren't free to do as you like, whereas assembly was just fine 40 years ago.

AnimalMuppet 5y ago

How is state encapsulation bad? Encapsulated state means that only a very few functions can access/change that state. Non-encapsulated state means that any code in the entire executable can change that state. How is that better? > The real goal should be to untangle state and decouple it from computations by putting it all in global shared state (e.g. SQL, Redux, data oriented game frameworks, etc.) while using stateless functional computations to compute changes to the global state. I kind of presume that you're in a single-threaded world. Shared mutable state plus multithreading is a recipe for disaster.

sodapopcan 5y ago
In functional languages you can still ensure that only certain functions can change certain parts of the state. The big idea is that state is isolated. You can actually write functional code that looks a lot like OO code (essentially just calling `foo(thing)` instead of `thing.foo()`) but because state is isolated, you know that nothing is changing behind the scenes. It may not seem much, but it's actually really freeing to not have to think about that stuff anymore. Same thing with immutability. I was skeptical of functional for years and was actually a big OO zealot. I finally brought myself to give functional a serious go over 1.5 years ago. I now write it professionally and don't miss OO even a tiny bit. It's really just something you have to try and have an open mind about. I actually still find myself sometimes thinking, "Crap, maybe I should make a copy of this in case something else tries to touch... OH WAIT! IMMUTABILITY! I'M SAFE!" It's a really nice feeling :)
- AnimalMuppet 5y ago
  Let me separate out immutability for a moment. If I don't have immutability, then if I can call foo(thing), then I can write bar(), and then call bar(thing). Bar can now alter thing. So my encapsulation can be broken by someone just writing a function. (This is the same problem that C had with structs - anyone could write a function to alter the data in your struct, and thereby put it in an inconsistent state.) Now, with something like C++, you can still do that. You have to go to thing, though, and write a new thing.bar(). It therefore becomes much clearer that bar() may break the consistency guarantees of thing. So I don't think that just functional gives you the guarantees that OO encapsulation does. Now, immutability changes things... a little bit. But with immutability, the problem only moves, it doesn't go away. Someone can now write a bar() that returns a new/altered thing, and then pass it to me. I can still get a thing that is in a state that violates the rules for what a thing is supposed to be. And, once again, the same thing can happen with OO. It's just that, if it happens, you have a lot less code to look through to try to figure out how and where it happened. You may have noticed that I care a lot about data being in a consistent, valid state. If you don't care about that, then my arguments may not resonate with you.