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

131–140 of 557 posts

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

#131

Post by AnimalMuppet »

sodapopcan wrote: post #102
AnimalMuppet wrote: post #80

Earlier quoted context omitted.

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

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.

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

#132

Post by reificator »

taurath wrote: post #122
reificator wrote: post #117

Earlier quoted context omitted.

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

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

I have no idea. The smalltalk ideal of OOP lives on in all sorts of ways, but the deep inheritance chain version that gets taught in classes? I don't think it has a place apart from maintaining existing code.

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

#133

Post by indymike »

I'm convinced the big win with OOP was more about modularity and encapsulation than OOP. The whole object.method() or object.variable model was pretty nice after spending years dealing with global soup or using naming conventions. The not-so-good part in particular happened when you inherited one too many times... very easy to write, and very hard to debug, maintain, and sometimes test.

A lot of OOP's success it was timing - OO showed up right around the time that we started building large gui apps. Now we have a lot of languages that do a great job doing encapsulation at the module level, which seems to be "good enough" and functional and procedural code seems to work pretty well, and be pretty easy to maintain at the module level.

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

#134

Post by ebruchez »

waynecochran wrote: post #124
cutler wrote: post #112

Earlier quoted context omitted.

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

That's the exact premise of Scala, by the way: more object-oriented than most object-oriented languages (including Java), and yet enabling functional programming.

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

#135

Post by interpol_p »

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…

I would say a big contributor is also reference semantics for classes being the default behaviour in many languages. You end up sharing the state and increasing the surface area of your code which can touch the state with every pass-by-reference in the code base

I know there are mechanisms to avoid this, but many times they are opt-in rather than opt-out, and so it encourages this access-to-state propagation through the codebase where you have far reaching consequences

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

#136

Post by throwawaylinux »

joe_the_user wrote: post #111
throwawaylinux wrote: post #92

Earlier quoted context omitted.

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

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? What are those alternative ways to make a huge system manageable you allude to? As I said, none of the paradigms put forward as alternatives even claim to operate like this. It's serious question, what are the alternatives in this kind of situation? And I'll…

I'm not making the claim though. I want to know what the data is for your assertion that OOP "makes a huge system manageable" in a way that other approaches or language features can not.

Mind you there are countless millions of lines of COBOL, C, etc out there in production so existence alone does not provide any evidence one way or another.

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

#137

Post by _fullpint »

zozbot234 wrote: post #71
dwohnitmok wrote: post #32

Earlier quoted context omitted.

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

Isn't this what a homotopy category is for though?

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

#138

Post by unnouinceput »

ctxc wrote: post #130
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?

OOP is not bad. Also the entire discussion is pointless. Problems require solutions. You do the solution in OOP or not, nobody's gonna care, just that the solution solves the problem. Rest is just whispers in the wind.

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

#139

Post by hashimotonomora »

mdoms wrote: post #129
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?

Julia is quite hot right now.

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

#140

Post by Jtsummers »

AshamedCaptain wrote: post #98
jiggawatts wrote: post #85

Earlier quoted context omitted.

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.

What is your distinction between "huge" and "large"? The Linux kernel is over 30 million SLOC now (though a lot of that is drivers). That's "just" large?
Post reply on HN