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

121–130 of 557 posts

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

#121

Post by joe_the_user »

keithasaurus wrote: post #89
joe_the_user wrote: post #86

Article like this miss the question of what purposes OOP serves in practice and so fail to offer alternatives to that purpose. In practice, OOP basically exists to take some horribly messy program, put an interface around it, and make it slightly less terrible to deal with. Similarly, it also involves creating an interface to a thing a programmer barely understands and letting the programmer do some things with it. W…

> In practice, OOP basically exists to take some horribly messy program, put an interface around it, and make it slightly less terrible to deal with. Similarly, it also involves creating an interface to a thing a programmer barely understands and letting the programmer do some things with it. Which is to say is about letting the programmer be wrong and only fail moderately - as opposed to making the programmer is rig…

I was referring thing like using member functions to do bounds checking and to make parameters consistent.

That's not really "the right way" to do programming or something generic abstraction gets you. The calling function should just know what it's doing. The Dijkstra quote "Object oriented programs are offered as alternatives to correct ones..." is correct. If you set a wrong parameter, it's ignored and your program works, it might have a more subtle bug from what you thought your wrong parameter would accomplish.

But this is still useful for programs produced by large teams where some people knowledge is limited. It's a mess but no one has put forward an alternative to the mess.

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

#122

Post by taurath »

reificator wrote: post #117
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…

> This is why simulations like say someone making a game or simcity with like relatively independent entities that map to something in real life use OOP. I don't think this is the case, or at least it hasn't been for quite awhile. Any gamedev I've known in the last decade or so would reach for an ECS[0] if they wanted to clone SimCity, in other words they would design it somewhat like a normalized database. Each char…

I appreciate that info! Its an abstraction that I had used in the past to demonstrate to other engineers that I have thought seemed somewhat useful about OOP, but as I was typing I thought to myself I'd bet that modern performant games wouldn't use active mutable entities but rather abstract into systems that change state at certain ticks so state can be much more easily managed, reasoned about and optimized.

This sort of begs the question: where does classical OOP, the one taught to all undergrad CS majors in programs that use Java or C++, really fit in nowadays?

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

#123

Post by zozbot234 »

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…

> if they didn't insist on using the worst possible names for everything

If the alternative is stuff like "FactoryFactoryFactory", I'm not sure that's better.

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

#124

Post by waynecochran »

cutler wrote: post #112
waynecochran wrote: post #18

OOP is a great fit for UI frameworks. OOP is a bad fit for many other things. They guy who hammers nails all day thinks screwdrivers are worthless.

John Carmack came to the opposite view in the end ( https://web.archive.org/web/20130819160454/http://www.altdev... ), favouring pure functions and immutability above all else.

OOP and functional programming are orthogonal -- you can do both ...

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

#125

Post by garethrowlands »

wrnr wrote: post #37
waynecochran wrote: post #18

OOP is a great fit for UI frameworks. OOP is a bad fit for many other things. They guy who hammers nails all day thinks screwdrivers are worthless.

OO gets you a long way, still there are interesting approaches being tried with data-driven programming through either composing lenses and ECS. I have a hard time understanding lenses, seems like a lot of work to reproduce the most strait-forward concept in OO (getters and setters). ECS do away with object and give you almost like a relational database, but it is cumbersome to encode hierarchies, but they do offer a…

Lenses solve a problem you don't have in OOP. Since OOP allows mutation, to change a value within a nested structure, just mutate it. If you don't want to mutate, then getters and setters don't help and changing nested structures is awkward.

Lenses solve the nested mutation problem for immutable structures but then go past what you can do with getters and setters. For example, you can compose bigger lenses out of smaller ones.

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

#126

Post by sirwhinesalot »

ledgerdev wrote: post #41

Data Oriented Programming. In short, don't entangle your code with data, and the data should immutable. https://blog.klipse.tech/databook/2020/09/25/data-book-chap0...

Data Oriented Programming originated from video game development and is all about knowing your hardware and making sure you transform data A into data B in the most efficient way possible.

This tends to have other benefits besides performance as the simplification of code that results from focusing on the right thing also tends to help with architecture (until you go ham on optimization).

What it most certainly is not about is immutable data since that's counter to efficiency. It's hard to beat a big fat buffer you poke at directly. Not entangling code with data and focusing on immutable data is Functional Programming, pretty much its definition, not Data Oriented Programming.

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

#127

Post by joeldo »

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.

I'm not exactly sure how hooks are related to OOP. Their design was inspired by 'Algebraic Effects' which are more functional in nature than OO.

This gives a good breakdown: https://overreacted.io/algebraic-effects-for-the-rest-of-us/

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

#128

Post by joe_the_user »

bcrosby95 wrote: post #109
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…

No single paradigm fits all of a problem. And in my experience, OOP is particularly bad at it.

The only reason OOP wins is because it doesn't enforce a single paradigm. You write 100% or 99% procedural code, you can write a functional program and encapsulate it. You can write a shell script and pop a GUI on top (it's marvelous in a horrible sort of way). OOP's lack of constraints is what lets it be used all sorts of places.

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

#129

Post by mdoms »

contravariant wrote: post #17

I've come around to Julia's point of view that it makes more sense for the methods to be separate from the object they're acting on. I just wish Julia had a succinct way of saying "This object needs to have implementations for functions X,Y,Z", rather than duck typing everything and just seeing if it works. Maybe it isn't too bad in practice I just don't like it when a function can fail because the implementation cha…

Who is Julia?

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

#130

Post by ctxc »

zozbot234 wrote: post #20

This is basically a survey of a bunch of posts, and doesn't do much to provide a consistent critique. Regardless, the true weak point of OOP is arguably implementation inheritance, which just doesn't leave you with a consistent semantics that's open to extension and changes in the basic/derived classes (that is, the well-known "fragile base class" problem is still a showstopper). But that has always been a pretty ad-…

I still don't understand why it's bad! Feels like spaghetti sentences tied together as a single article.

Why is OOP so bad, anybody? With scenarios, code samples or alternate implementations?

Post reply on HN