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

491–500 of 557 posts

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

#491

Post by zanellato19 »

bsenftner wrote: post #438
tonyedgecombe wrote: post #388

Earlier quoted context omitted.

It was abused a lot in C++, mostly because of weaknesses in other parts of the language.

Bullshit, it was the weakness in those developer's minds that screwed their use of this perfectly fine language feature. This is a propaganda war, people. We are being told we are too dumb to handle knives. And the truth is, our industry lets incompetents play our roles, and we (those smart enough to use knives) must suffer the ramifications of those who stab themselves repeatedly and they cry out "it's the language!…

Is this parody?

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

#492

Post by dragonwriter »

_9omd wrote: post #269
ummonk wrote: post #51

Earlier quoted context omitted.

Games are actually moving away from OOP by separating out state into a data oriented system.

But aren't they doing that mostly for performance via better memory layout and thus better cache locality? ie: arrays of objects vs objects of arrays. It's a sacrifice of code architecture for performance. I feel like games are actually a good example where OOP makes sense, since there is inherently so much state and encapsulation is useful.

> I feel like games are actually a good example where OOP makes sense

Intuitively, yes.

In practice, I think once you actually use an ECS for a game you won't want to program them in the traditional OOP way.

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

#493

Post by sirwhinesalot »

nec4b wrote: post #482
sirwhinesalot wrote: post #422

Earlier quoted context omitted.

We will just have to agree to disagree then, for me the Square vs Rectangle inheritance issue is the simplest possible example of the problem, where trying to model an inheritance hierarchy "the right way" directly impacts the structure of your code in a detrimental way, and the solution is to avoid OOP silliness in its entirety. Even in the immutable case if you have a Square inherit from Rectangle it still stores 2…

You are building a straw man from your misunderstanding of the OOP technique. As 'dragonwriter' tried to explain it to you that mathematical model of a square being a kind of a rectangle has nothing to do with OOP modeling. Liskov substitution principle tells you that a rectangle cannot be a super class of a square.

If modeling taxonomies of the world is not OOP modeling, what is exactly? The very reason Barbara Liskov had to point out the damn principle is that people were doing dumb stuff like this.

They still do btw. Universities still teach that Mammals have a walk() method that you implement for Dog and Cat, except then you need to add a Whale and now you're screwed. Silly example, but real world cases are much more subtle. I have seen plenty of NotImplementedExceptions strung across various codebases.

If you haven't done Domain-Driven Design, with cute UML diagrams and everything, then we aren't talking about the same thing (and I have no idea what you are talking about).

Reflecting the business domain into class hierarchies and structuring your codebase around that structure has ruined more codebases than NULL ever did. Code structure should not be dictated by business taxonomy concerns, only by concrete business data.

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

#494

Post by sirwhinesalot »

nec4b wrote: post #484
sirwhinesalot wrote: post #386

Earlier quoted context omitted.

Pretty cool to hear about those, didn't know there was such a dynamic approach to the problem. Either way, the problem in my view is that the question is silly to begin with, Squares and Rectangles should be PODs (or, even better, simple structures), and not have any associated behavior. The decision of whether they are mutable or not then depends solely on the needs of the software, and not on irrelevant modelling c…

What have you solved by having squares and rectangles as PODs? Now you won't be able to treat them as same in some way (e.g. IShape, IDrawable, IPrintable, IArea,...) and you will need twice as many functions for doing same things.

If you make a square and a rectangle into IShapes (with no inheritance hierarchy) you still need 2 separate implementations for GetWidth().

Either way, it's simply not true that you can't treat them the same way because you've made them PODs, there are more kinds of polymorphism beyond subtype polymorphism. Even for the latter modern languages split the data (structs) from the behavior (traits/protocols), see Rust or Swift for example.

If you explicitly need to treat squares and rectangles as a single entity to draw them (alongside other shapes), rather than thinking of each of them having a "draw()" function (likely breaking the single responsibility principle), you should instead have a function square_to_drawable, rectangle_to_drawable etc, where a drawable is also a POD but one that has the relevant drawing data (textures, triangles, whatever). Then a drawing system is responsible for actually rendering these drawables.

That's how it's done on modern game engines. It takes a while to wrap your head around but it works really well. This style is used a lot by modern game engines because performance is way better with this style.

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

#495

Post by amai »

rdtsc wrote: post #296
nomel wrote: post #213

Earlier quoted context omitted.

But, thats exactly the reality of the problem, and exactly what you want. I work with robots, so much of it is physical. There are no floating bananas in the world. They're all held up by something.

The key that Joe was trying to make I think was that the forest and the gorilla have to be explicit: State2 = update(State1, ArgX), State3 = update(State2, ArgY), As opposed to, say: obj.update(arg_x); obj.update(arg_y); obj holds a gorilla and the jungle, and it may be hard to know how update method works because there is a complicated diamond shaped class hierarchy, and then a thread may concurrently modify parts o…

The problem is that setters are usually void functions. Instead they could return the new state/object

State2 = obj.update(argx)

State3 = State2.update(argy)

But if you do this people will argue this is inefficient, because you are copying a lot of objects.

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

#496

Post by native_samples »

c-cube wrote: post #266
ummonk wrote: post #211

Earlier quoted context omitted.

> 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? As everyone is telling you, it’s a poor paradigm that makes the developer’s job harder compared to both non-OOP approaches and better approaches (mixins / multiple inheritance). That said, one should be cognizant of the reason it was created in the first place…

C++ supports multiple inheritance though. And it still does it with (multiple) vtables. Did you mean single dispatch?

Yes, but multiple dispatch is much slower than single dispatch.

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

#497

Post by native_samples »

agumonkey wrote: post #472
wackro wrote: post #449

Earlier quoted context omitted.

I put it to you that the OOP concept of a factory exists because in OOP your factory is often (though not always) a type, and types tend to need names. In e.g. FP there are no objects and therefore no instantiation but you can separate this kind of logic all the same, except you wouldn't call it anything, or would name it like any other function. For the record I've been doing mainly OOP and have dabbled in F# so I'm…

That's the whole point. OO gives a class as base, forcing you to reextract limited instanciation logic into another thing, when it's just functions from a to b. And people get to waste time on this.

No - that's not what factories are at all.

If you want a simple function to create objects, you have those in OOP languages. They're called constructors. They don't even have names independent of the thing they construct, so they're as lightweight as you can get. And if you do want names, you have static methods or top level named functions (depending on language).

Factories exist for a few different reasons:

1. When there are more things to configure about the newly created objects than makes sense to pass as function properties.

2. When an API designer wishes to provide backwards compatibility to his clients, which adding function parameters doesn't do.

3. When there's a need to separate how something is constructed from where it is constructed, i.e. you create a "factory" or "builder", configure what you want it to do, but then don't directly use it. Instead you pass it off to some other code that uses it when it needs to.

These are fundamental concepts. They aren't some side effect of how OO languages work. I think the disdain for them comes largely from programmers who haven't actually done many different types of programming. If all you've ever done is write web apps then yeah they're sometimes going to seem a bit useless. If you've shipped a type safe library API that you've needed to maintain compatibility for over a period of many years, maybe that will be used in ways you didn't anticipate so you can't just arbitrary refactor yourself out of a hole, suddenly these sorts of abstractions start to look pretty good.

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

#498

Post by agumonkey »

native_samples wrote: post #497
agumonkey wrote: post #472

Earlier quoted context omitted.

That's the whole point. OO gives a class as base, forcing you to reextract limited instanciation logic into another thing, when it's just functions from a to b. And people get to waste time on this.

No - that's not what factories are at all. If you want a simple function to create objects, you have those in OOP languages. They're called constructors. They don't even have names independent of the thing they construct, so they're as lightweight as you can get. And if you do want names, you have static methods or top level named functions (depending on language). Factories exist for a few different reasons: 1. When…

point 3 is exactly what I'm saying

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

#499

Post by native_samples »

agumonkey wrote: post #498
native_samples wrote: post #497

Earlier quoted context omitted.

No - that's not what factories are at all. If you want a simple function to create objects, you have those in OOP languages. They're called constructors. They don't even have names independent of the thing they construct, so they're as lightweight as you can get. And if you do want names, you have static methods or top level named functions (depending on language). Factories exist for a few different reasons: 1. When…

point 3 is exactly what I'm saying

But the concept of a factory is independent from whether you name it. In Java you can write a factory like this:

    () -> new Thing(foo, bar);
Behind the scenes it's a class, but you don't write it as such and you don't name it. Nonetheless, it's still a factory.

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

#500

Post by Life_exe »

Scarblac wrote: post #346
momentoftop wrote: post #321

Earlier quoted context omitted.

Here's a pure computation: import Data.List (nubBy) refuteGoldbach :: Integer refuteGoldbach = head $ [ n | n If you think you already know the answer to this computation, get yourself a Field's medal. And then there are pure functions. Every time you compute a function using an input no-one has tried before, you are probably computing something that is not already known. You do this routinely even with a calculator.

And if you don't store the answer in some kind of state, it's lost and computing the pure function was useless.

You don't have to throw away the result. That's what the State Monads are for. Immutable State is Ok. Memoization is Ok.
Post reply on HN