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

91–100 of 557 posts

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

#91

Post by taurath »

Supermancho wrote: post #29
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…

> ends up creating so much more. This is primarily because of inheritance, which seems counter-intuitive. In a meta-analysis of OOP-based designs, inheritance is used as the primary form of composition with other strategies being either last-resort or added later when the inheritance is already deeply embedded as part of the design. Inheritance is a brittle form of a composition (no-reinherit) that nests state in a d…

> This is primarily because of inheritance, which seems counter-intuitive

I agree that inheritance creates a lot more problems, but the usages of non-static methods and internal state even in classes with no usage of inheritance can feel just as bad, when you have a high level method utilizing instantiated objects. Internal state as a whole can be avoided fairly often

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

#92

Post by throwawaylinux »

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.

This is the sort of hype that has followed OOP around everywhere though. Well that's great, of course we would want to take a horribly messy program and make it less messy! Who wouldn't?

But where is the evidence that it actually performs as advertised? Does it make software easier to deal with? Is it superior to alternative ways to achieve that?

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

#93

Post by jiggawatts »

zozbot234 wrote: post #35
jiggawatts wrote: post #23

I don't quite understand what this is trying to say. It's a summary review of some reviews? Or something. It's not even clear if the author of this post agrees or disagrees with the claim in the YC News title. It's peppered with sentences like: "That you don't understand something doesn't mean it's flawed or bad." Precisely. Many of the arguments against OO are from academics that don't write real-world, large-scale…

Rust is not an "anti-OO" language. It has a basically complete featureset for OO programming with the one exception of implementation inheritance. It is fully usable for programming "in the large".

You say that it is fully usable for programming in the large, but other than Servo I can't think of any large Rust projects of the top of my head.

Certainly there are none with more than 1K developers collaborating.

I'm aware that you can have "dyn Trait" in Rust and a Box of a trait also provides runtime polymorphism. However, it just has too much friction due to explicit "no more OO!" decisions by the Rust core language team to enable truly large-scale programming, at least in my humble opinion.

I think such decisions stem from logic like this:

"I saw OO used extensively at and the was a huge mess and nobody was happy, hence OO is bad and should be avoided."

Meanwhile the logic is more like:

" needed OO because it was large, and it was unpleasant to work on because it was large, not because it was OO. It would have been worse if it wasn't OO."

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

#94

Post by pjbeam »

jiggawatts wrote: post #23

I don't quite understand what this is trying to say. It's a summary review of some reviews? Or something. It's not even clear if the author of this post agrees or disagrees with the claim in the YC News title. It's peppered with sentences like: "That you don't understand something doesn't mean it's flawed or bad." Precisely. Many of the arguments against OO are from academics that don't write real-world, large-scale…

There is some very large scale Rust stuff happening at Amazon; whether it's OO or not I do not know.

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

#95

Post by dboreham »

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 laugh heartily at how piss poor it is. You can do this with FP too. But FP isn't used so much for real world solutions and therefore statistically you will find many more things to laugh about in OOP which is very commonly employed against real world problems.

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

#96

Post by usrusr »

agency wrote: post #70
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…

There's a really wonderful talk that I've recommended to almost everyone I've ever worked with called Simple Made Easy[1] by Rich Hickey. I also struggled to explain why I hated state so much. You can talk about races with shared mutable state but even single threaded code I found I couldn't stand it, that it made things harder to reason about and change. It's because state is complex , in the sense Rich discusses in…

That time part is what you are wrestling with when you are battling with state. So it's natural to think about it that way. But there's also this somewhat dumbed down version of the argument: every piece of state a method reads is like an additional function argument and every state it writes an additional return value. What a mess.

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

#97

Post by taurath »

stickfigure wrote: post #79
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 complexi…

I agree with this - and of course without any state whatsoever the program is unlikely to be useful. A database, a network connection pool, and initialized configurations are required pieces of state for just about any backend service, and you can't really get rid of them. But having clear lines around how state is stored and utilized and minimizing it in business logic to me creates a much more sane program.

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

#98

Post by AshamedCaptain »

jiggawatts wrote: post #85
ByteJockey wrote: post #66

Earlier quoted context omitted.

> Has anyone seen large scale development done successfully in an an "anti-OO" language like Rust? Taking "anti-OO" to mean languages that specifically don't have OO capabilities (rather than languages where you can choose not to use OO). Any of the large C code bases?

Very often in code like that you see "struct" types filled with function pointers.. Those are literal OO "vtables", just implemented manually instead of being generated by the compiler. The Linux kernel is huge, yes, and is written in a "pre-OO" language. It's also full of OO paradigms. For example, the core kernel developers don't want to have to write huge "switch" statements to handle the thousands of different dr…

For the record, the Linux kernel is not huge, just large. Just saying that because many people here show Linux as a model of a "huge" software project and yet it absolutely isn't. E.g., project-wide refactors/API changes are still performed multiple times per release and done usually by a single-person team, something which would just be unthinkable in huge software projects.

Agreed with the point, though.

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

#99

Post by mountainriver »

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.

Exactly and the functional way is harder for humans to grok

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

#100

Post by troupe »

agency wrote: post #70
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…

There's a really wonderful talk that I've recommended to almost everyone I've ever worked with called Simple Made Easy[1] by Rich Hickey. I also struggled to explain why I hated state so much. You can talk about races with shared mutable state but even single threaded code I found I couldn't stand it, that it made things harder to reason about and change. It's because state is complex , in the sense Rich discusses in…

I think I was at that talk. If I remember right the Sussmans were there as well and Gerry was the first to his feet giving Rich a standing ovation after that talk.
Post reply on HN