Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

OOP Is Dead, Long Live OOP

gamedev.net

Post reply on HN
Print view View original

151–160 of 357 posts

Re: OOP Is Dead, Long Live OOP

#151

Post by LolNoGenerics »

> This code may be typical of OOP in the wild, but as above, it breaks all sorts of core OO rules, so it should not all all be considered traditional.

This argument drives me nuts. A simple OOP environment can be quite easy to grasp and (mis)use. Following all the golden rules and principles that SOLID et al call for, are comparabily hard to internalize. A rookie can only fail and has to collect, choose and study all the wisdom over the years until he becomes a master. To that point he will create OO code that will break untold rules. Ruling the majority of OO code out there as "bad" is hubris and ignores reality. It is easy to do OOP wrong and hard to get it right. This imbalance is proof enough for me that we don't know what we are doing, just justifing. (Yes this may apply to other paradigms as well)

Re: OOP Is Dead, Long Live OOP

#152

Post by mikmoila »

legulere wrote: post #106
jschwartzi wrote: post #89

Earlier quoted context omitted.

> I think OOP is fine as long as you are doing it and as long as it is single-threaded. I don't really see how threading has anything to do with it. What OOP allows you to do is choose what terms you want to express your solution in. You can choose language that exposes thread-safe aspects of your problem domain without requiring the user to be aware that they are expressing things in thread-safe terms. In my last pr…

OOP is linked strongly to mutable objects, which is inherently thread-unsafe. Sure you can get thread-safety in OOP, but it’s hard. It’s the same reason why global variables are bad but worse. Mutability is rarely needed and often makes things more complicated than needed.

I'm not aware of such "linking". It's very common to write classes of which instances are immutable or thread-safe.

Re: OOP Is Dead, Long Live OOP

#153

Post by dataflow »

ilovecaching wrote: post #125
jshowa1 wrote: post #121

Earlier quoted context omitted.

A poor model for computation that is pervasive in the industry. Poor models usually don't become pervasive.

Can you give an argument why it's a good model?

In your top-level comment you argued it's a bad model and didn't really give an explanation for why. You just make assertions that things are pathological/overly-complex/error-prone in OOP and that other alternatives are better, that it's impossible to reason about memory layout, etc. But I could just as easily assert the opposite is true: that proper OOP does simplify problems down to manageable parts, that encapsulation is what you're supposed to do in proper OOP, that abstracting away memory layout is a good thing, etc... I'm not sure if you find these compelling or not, but if not, then I guess you could see why others feel similarly about your arguments.

Re: OOP Is Dead, Long Live OOP

#154

Post by ahansen »

vietjtnguyen wrote: post #96
Spearchucker wrote: post #80

Earlier quoted context omitted.

Like in procedural languages I write my own harnesses as needed. Because DI adds complexity. And for testing all DI does is make testing easier. You end up shipping all that complexity or you refactor your ship code. To be fair that might be acceptable to many in a typical corporate environment.

What do you mean by DI? I find DI is an overloaded term.

In this context I believe he is referring to dependency injection.

Re: OOP Is Dead, Long Live OOP

#156

Post by pwm »

hota_mazi wrote: post #98
3pt14159 wrote: post #55

Earlier quoted context omitted.

I've found that inheritance is very useful in one situation, and adds nothing over mixins otherwise. If a class does two broad things simultaneously then inheritance can work great. For example, a User class that inherits from a DB mapper class. I don't want to have to tell my class how to write a record to the DB. All that code can be centralized into one thing and then relied upon for its uniformity across all my m…

Duck typing is the worst of all worlds, in my experience. And in defense of inheritance, the Liskov Substitution Principle is extremely useful and makes a lot of sense. If a function accepts a `Weapon` as parameter, surely you should be able to pass it a `Sword`.

The problem with LSP is that it is an incredibly hard property to prove (behavioural subtyping in general is undecidable). So in theory yes, it sounds great in practice with a sufficiently complex system good luck ensuring that you adhere to it.

Re: OOP Is Dead, Long Live OOP

#157

Post by hacker_9 »

Spearchucker wrote: post #80
hacker_9 wrote: post #64

Earlier quoted context omitted.

DI is bad, what? So how are you writing tests then.

Like in procedural languages I write my own harnesses as needed. Because DI adds complexity. And for testing all DI does is make testing easier. You end up shipping all that complexity or you refactor your ship code. To be fair that might be acceptable to many in a typical corporate environment.

Well you are going to need to deal with your dependencies eventually. Unless you are just end2end testing, and not doing any unit tests. In that case good luck finding your bugs when they appear. Or perhaps you write 'if (mode == "test")' everywhere :)

Re: OOP Is Dead, Long Live OOP

#158

Post by ben509 »

This is the "you're holding it wrong" defense of OOP.

Of SOLID, S, O, I and D are rehashing structured programming design principles. LSP is peculiar to it, and not an unreasonable way of thinking of objects, but I don't see people struggling to figure out how to come up with workable class hierarchies.

The point of objects was that they were intuitive and easy, and where it tends to fall apart is in the details. It's often small tasks like writing an equality operator correctly that are absurdly complicated[1]. And while we can construct reasonable class hierarchies, the interaction becomes a bear and the bugs are subtle and confusing.

What I see in OOP programming is that people avoid various idioms or patch around them because they don't trust their tools.

I think the problem with most OOP languages is that some high-level concepts like inheritance were constrained by very low-level implementations, and they often tried to glom several ideas together.

There's no "object algebra" even 40 years in. In C-like languages, objects are using a "struct and vtable in the heap" model. In dynamic languages, they're using the "type instance and a hashtable in the heap" model. Then they typically declare that a value is really a variable, unless it's an atom, and often other weird asymmetries like "the bottom type actually does have a value which is 'null'" and, of course, whatever weirdness they pick up such as floating point.

Those constructs are then overused; this problem is especially apparent in Java where "everything is an object" means that your class becomes your tuple type, and if you want to combine two tuple types you're going to do that via inheritance. In most of them, you don't have a proper discriminated union, so all the stuff you'd do with sum and product types you now have to shoehorn into classes whether it makes sense or not.

It all sort of works, but the reason OOP languages keep adopting non-OOP features is that it doesn't work very well.

[1]: http://jtechies.blogspot.com/2012/07/item-8-obey-general-con...

Re: OOP Is Dead, Long Live OOP

#159

Post by leowoo91 »

leowoo91 wrote: post #36

OOP in game development is in good use with engines like UE4 and Godot, so it is about choice. What really matters is how comfortable you are with the way you develop the game.

I don't get it when a functional programming comment gets highest score in a game programming pattern thread while a game-dev related view gets the lowest.

Re: OOP Is Dead, Long Live OOP

#160

Post by jcelerier »

simongray wrote: post #72
jshowa1 wrote: post #22

Earlier quoted context omitted.

How has the church of OOP failed? Nearly every used language is based almost entirely on OOP. OOP makes organizing software and code reuse incredibly easy. The only real downsides to OOP is that its arguably slower and has more overhead. But that's only a problem in niche applications (ie. embedded apps).

> OOP makes organizing software and code reuse incredibly easy. That is the big promise and the big lie of OOP. It, in fact, accomplishes the opposite. The medium used across systems today is data, not objects. Your objects are not compatible with systems across the wire, they need to be converted to data (JSON, XML, ...). They're not compatible with your data base, they need to be converted to data (SQL, ...). And i…

> That is the big promise and the big lie of OOP.

Well I wonder all those reusable libraries that I'm using all the time such as boost, Qt, POCO, openframeworks, etc... come from then. Am I dreaming them ?

> The medium used across systems today is data, not objects. Your objects are not compatible with systems across the wire, they need to be converted to data (JSON, XML, ...). They're not compatible with your data base, they need to be converted to data (SQL, ...)

not all code on earth is your average server app that communicates with a DB and sends JSON to the internet. I don't think I have even one installed program working like this on my computers. However I have an office suite, a lot of GUI apps, media authoring software, music player, web browser, mail client.. and they are all built with OOP languages - C++ being the one used for the immense majority - and OOP patterns.

Post reply on HN