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

71–80 of 557 posts

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

#71

Post by zozbot234 »

dwohnitmok wrote: post #32
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.

What would homotopy types bring to the table?

They seem to be necessary if you want a notion of "equivalence" (for both values and types) that enables you to make functions, operations, constructs etc. independent of any notion of "underlying representation" as well as seamlessly applicable across equivalent 'representations'. This is desirable in both higher mathematics (where homotopy types were first developed) and software engineering, for much the same reasons.

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

#73

Post by eunoia »

ianbicking wrote: post #63
akavi wrote: post #45

Earlier quoted context omitted.

> OOP is a great fit for UI frameworks. The biggest UI framework of the past decade is decisively anti-OOP in its philosophy

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.

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

#74

Post by ferdowsi »

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.

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

#75

Post by marcos100 »

_fullpint wrote: post #36
everyone wrote: post #16

People spend way too much time arguing about this.. If you're a good programmer u will be able to do excellent maintainable work in any language you're experienced with. If you're bad you will make a mess in any language. It'd be like carpenters saying "spruce is terrible if you make anything from spruce its fucked, you have to use oak." ; A good carpenter will be able to make something amazing from spruce. Like carp…

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.

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

#76

Post by hgs3 »

Based on my own experience, OO works best for small, self contained concepts whereas procedures work best for the overall program architecture. Notice when OO is evangelized it's always done using self contained concepts, like data structures or GUI widgets rather than architecture. When you do use OO for program architecture, like in Java, you'll end up with lots of pointless indirection and brittle, over engineered design pattern soup. Procedures are simply more "fluid" because they are smaller, self contained and easily refactorable which is exactly what you want when it comes to program modifications.

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

#77

Post by paragraft »

FpUser wrote: post #57
akavi wrote: post #45

Earlier quoted context omitted.

> OOP is a great fit for UI frameworks. The biggest UI framework of the past decade is decisively anti-OOP in its philosophy

What it the name?

React, presumably, with its approach that a UI is well described by nested functions operating on state. It's a good point. I remember long discussions on mailing lists for various FP languages conceding that UI toolkits were the one area where OOP seemed the natural fit. Haven't seen many of those discussions since React emerged.

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

#78

Post by jayd16 »

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…

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

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

#79

Post by stickfigure »

taurath wrote: post #14

In my mind, state is the real enemy impacting: comprehension, brittleness towards making changes, and the surface area exposed to potential bugs. OOP as frequently implemented, while claiming to encapsulate state, ends up creating so much more. In accordance with this view, I think project architecture should be approached with an emphasis around how much state is necessary for it to run. This is why simulations like…

If only we could completely eliminate state! Thankfully, I am working on a plan for this. It should take around 10^106 years... give or take.

The serious comment here is that the real world imposes a minimum floor on the amount of mutable state that you have to model. Databases are giant piles of mutable state. Maybe we should start talking about "essential state" and "accidental state" the way we talk about complexity.

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

#80

Post by AnimalMuppet »

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 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.

Post reply on HN