Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Case against OOP is understated, not overstated (2020)

boxbase.org

Post reply on HN
Print view View original

101–110 of 557 posts

Re: Case against OOP is understated, not overstated (2020)

#101

Post by f38zf5vdt »

I don't really understand arguments for or against OOP. OOP, to me, has always been about blackboxing some data entity and interacting with it through an API. Where it got wild and wacky was inheritance, but there's nothing fundamentally bad with having a process or object with an internal state you interact with via an API, e.g. a microservice.

Most computer programs have an internal state that you interact with through some API. And sometimes you need to compartmentalize a process and have it work independent of another process. There's literally no way to get away from programs with an internal state and API access since that's how computers, and electronics in general, work.

Re: Case against OOP is understated, not overstated (2020)

#102

Post by sodapopcan »

AnimalMuppet wrote: post #80
ummonk wrote: post #42

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…

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 state…

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 :)

Re: Case against OOP is understated, not overstated (2020)

#103

Post by ummonk »

ferdowsi wrote: post #74
ummonk wrote: post #42

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…

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.

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.

Re: Case against OOP is understated, not overstated (2020)

#104

Post by ianbicking »

eunoia wrote: post #73
ianbicking wrote: post #63

Earlier quoted context omitted.

I assume you are talking about React. It started fairly OOP. Now it's... something else? It's not functional. IMHO hooks and effects are a crazy form of OOP. It's like some weird dynamic scope data definition.

Honest question, I’m very curious. Do you still classify React as closer to an OO paradigm than functional? Agreed hooks are… something else.

Running a function and then looking for magical side effects to effectively get multiple return values from that function sure isn't functional. And it shows in how unintuitive it is to reason about hooks and the leakiness of the whole thing.

I think it looks functional because it's only easy to reason about if you write functional code.

I suppose it tries to solve some of the same problems as OO, like related state and private transitions. But it feels like React itself is the God Object.

Re: Case against OOP is understated, not overstated (2020)

#105

Post by [deleted] »

astrange wrote: post #43
zozbot234 wrote: post #27

Earlier quoted context omitted.

"Hiding" state is necessary to endow it with well-defined invariants. This can be done in many FP languages, too. The semantics-side implications of "encapsulated" state w/ proper invariants have yet to be explored, though, and this is where newer PL formalisms like "homotopy types" might end up being quite helpful.

> The semantics-side implications of "encapsulated" state w/ proper invariants have yet to be explored, though It seems that that's called a state machine, and OOP objects should come with state charts, but they don't. > and this is where newer PL formalisms like "homotopy types" might end up being quite helpful. PL research would actually get adopted if they didn't insist on using the worst possible names for everyt…

[deleted]

Re: Case against OOP is understated, not overstated (2020)

#106

Post by _fullpint »

marcos100 wrote: post #75
_fullpint wrote: post #36

Earlier quoted context omitted.

Sure your first proposition is true. But many people realize you more than likely will not have a team of good to great programmers. OOP is a massive foot gun for many programmers who are okay at best. And that effect is exponential as the project and their team grows.

What isn't a footgun in the terms that you declared? I believe people dislike OOP because the vast majority of code is written using OOP. If everything were written using data oriented programming or whatever, people would have the same reaction as they have regarding OOP.

>> What isn't a footgun in the terms that you declared?

There are definite degrees to this. But something like FP that declares f(x: X) => Y, instead of something like OOP where given context: x: X, y: Y and f() => void (where there is an effect on y) those are massively different scopes of problems.

It's not that you cannot do the previous in the latter, but that people -- especially those that are inexperienced and haven't dealt with the hell of a stateful programming -- routinely reach for as a solution to their problem.

>> I believe people dislike OOP because the vast majority of code is written using OOP.

Why do you believe that's the reason why? There's no implication here -- just a genuine curiosity as to how that was the conclusion.

>> If everything were written using data oriented programming or whatever, people would have the same reaction as they have regarding OOP.

DOP especially given one with a static language forces you to move from one type to your next to solve your problem, and handle your edge cases.

From experience DOP and FP can be intimidating, but usually end up being easier, and the development time, along with the time to stability are hugely reduced -- because it's inherently dumb.

Re: Case against OOP is understated, not overstated (2020)

#108

Post by deltaonefour »

dboreham wrote: post #95

Conjecture: programming is hard, especially as the scope of the system becomes larger and the problem domain more complex. This means that all programming tools and techniques have at least some problems and downsides. It also means that any solution involves trading off various factors, e.g. code is fast or easy to read but perhaps not both. All this means that you can pretty much point to anything in our field and…

>But FP isn't used so much for real world solutions

It's taken over the front end. The react paradigm is FP.

SQL read queries are FP.

Re: Case against OOP is understated, not overstated (2020)

#109

Post by bcrosby95 »

dboreham wrote: post #95

Conjecture: programming is hard, especially as the scope of the system becomes larger and the problem domain more complex. This means that all programming tools and techniques have at least some problems and downsides. It also means that any solution involves trading off various factors, e.g. code is fast or easy to read but perhaps not both. All this means that you can pretty much point to anything in our field and…

> Conjecture: programming is hard, especially as the scope of the system becomes larger and the problem domain more complex. This means that all programming tools and techniques have at least some problems and downsides.

Yes.

> You can do this with FP too. But FP isn't used so much...

So close....

The problem is single paradigm tools. No single paradigm fits all of a problem. And in my experience, OOP is particularly bad at it. Not Prolog levels of bad, but also not much better. We have a huge number of very popular single paradigm OOP languages, because in the '90s the programming gods set forth the decree that OOP is the One True Way to design a system.

Re: Case against OOP is understated, not overstated (2020)

#110

Post by Zababa »

ameixaseca wrote: post #4

Interesting collection of point of views. A language like Erlang indeed seems to align more closely with the spirit of the OOP goals - especially regarding encapsulation and avoiding shared state. I would argue one of the best implementations of OOP is found in OCaml, where a nominal type system lives side-by-side with a structural type system, the latter which is used for objects and classes [1]. You still can use s…

This is one of the things I love about OCaml. Even though the objects aren't used frequently, they were designed well, and people don't mind reaching for them when there is a need. It's a good way to show the "pragmatic, but careful" approach that OCaml has for a lot of things.
Post reply on HN