Live data from Hacker News

OOP Is Dead, Long Live OOP

gamedev.net

111–120 of 357 posts

Re: OOP Is Dead, Long Live OOP

#111

Earlier quoted context omitted.

Sure, the general consensus is that inheritance is better achieved through composition. But let's be serious for a minute here: even regular inheritance has hardly ever led to the kind of nuclear disaster than most pundits claim. It makes your code base a bit more unwieldy and a bit harder to evolve, but it's really not the end of the world.

> Sure, the general consensus is that inheritance is better achieved through composition. This sentence does not make sense. If you want to have a class composed of two other classes, whose behaviour is defined at run-time - say, a generic "Engine" object which is composed of a "GraphicsRenderer" and an "AudioRenderer" where the first one can be a D3D renderer or an OpenGL renderer and the second can be an XAudio or…

You are confusing inheritance of implementation with inheritance of interface.

The consensus is to use inheritance of interfaces and use composition to implement the interfaces.

Hence my phrasing: "Inheritance is better achieved through composition".

Re: OOP Is Dead, Long Live OOP

#112

Becoming a professional Haskell and Erlang developer really shifted my view on OOP (let OOP denote class based OOP as found in Java or C++). In my view, OOP is prove a poor model for computation, and the result has been that OO code is almost always significantly more complex and error prone than an equivalent computation written in a concurrent, functional, or structured paradigm. Recent trends in language design (s…

> my view on OOP (let OOP denote class based OOP as found in Java or C++)

Maybe you should take a look at a real OOP language like Smalltalk before you tell us why OOP is a bad idea. Otherwise, I might tell you why consumers will never adopt cars as I drove a Trabant once.

Re: OOP Is Dead, Long Live OOP

#113

Becoming a professional Haskell and Erlang developer really shifted my view on OOP (let OOP denote class based OOP as found in Java or C++). In my view, OOP is prove a poor model for computation, and the result has been that OO code is almost always significantly more complex and error prone than an equivalent computation written in a concurrent, functional, or structured paradigm. Recent trends in language design (s…

Someone with 15 years programming OOP told me once: here is the best way to describe object oriented programming: you asked for object “monkey”, and you got the whole jungle, as well as monkey’s bananas.

Exactly, you get a tangle of objects and data that's impossible to reason about, and isn't made explicit in the types.

Re: OOP Is Dead, Long Live OOP

#114
post #63

I think OOP is fine as long as it's the only thing you are doing and as long as it is single-threaded. Problems will occur if you need to convert the innards of your objects to data (i.e. JSON etc.), if you need to materialize objects from data (i.e. ORM) or if you need to write multi-threading safe code. If you expose things as data, just be honest about it and treat it as such. It's already out in the open, why hid…

> 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 has no built-in facilities to deal with multi-threading. It's orthogonal to it and that's a problem.

Thread safety can't be expressed or enforced and you can't grab a bunch of classes from somewhere and assume anything about their fitness for multi-threaded code.

Typically one has to carefully design a class for multi-threaded use. Reasoning about state inside objects then quickly becomes infeasible.

Re: OOP Is Dead, Long Live OOP

#115
post #27

Earlier quoted context omitted.

Just because prior literature exists, does not mean it should not be superseded. For example, generics wasn't even a thing when OOP originally started and yet LINQ and basic list ADT's wouldn't be as powerful without it.

> Just because prior literature exists, does not mean it should not be superseded. For example, generics wasn't even a thing when OOP originally started and yet LINQ and basic list ADT's wouldn't be as powerful without it. No, this not an example... generics did not "supercede" OOP.

My point is that earlier OOP documents did not implement generics.

When they were finally implemented in OOP, it superseded the original intentions of OOP.

The question is, are we now supposed to remove generics because they don't conform to the early literature of OOP?

Looks like the OOP edited his comment though, so my point is irrelevant.

Re: OOP Is Dead, Long Live OOP

#116

Becoming a professional Haskell and Erlang developer really shifted my view on OOP (let OOP denote class based OOP as found in Java or C++). In my view, OOP is prove a poor model for computation, and the result has been that OO code is almost always significantly more complex and error prone than an equivalent computation written in a concurrent, functional, or structured paradigm. Recent trends in language design (s…

> my view on OOP (let OOP denote class based OOP as found in Java or C++) Maybe you should take a look at a real OOP language like Smalltalk before you tell us why OOP is a bad idea. Otherwise, I might tell you why consumers will never adopt cars as I drove a Trabant once.

Smalltalk OOP looks almost exactly like Erlang gen_servers and shares a lot of nice properties with them. Unfortunately the concept has been twisted into it's current day meaning that's akin to the OOP we find in Java, C++ etc.

Re: OOP Is Dead, Long Live OOP

#117
post #102

Earlier quoted context omitted.

I think you are conflating OOP with type erasure. Most OOP languages support type erasure (including rust!), but that's far from all there is to it.

How so? I believe I was addressing the fundamentals of OOP: Classes, methods, inheritance, overloading, visibility, etc. Also, Rust, while allowing the assigning of behavior to a type, is explicitly not OOP. Check it's Wikipedia page (which doesn't include OOP in the list of paradigms) and the O'Reilly book (which says Rust isn't OOP).

I didn't mean rust was fundamentally OOP, but that rust implements, through runtime traits, exactly the behavior you are criticizing OOP for. Sorry about that

Re: OOP Is Dead, Long Live OOP

#118
post #94
post #63

I think OOP is fine as long as it's the only thing you are doing and as long as it is single-threaded. Problems will occur if you need to convert the innards of your objects to data (i.e. JSON etc.), if you need to materialize objects from data (i.e. ORM) or if you need to write multi-threading safe code. If you expose things as data, just be honest about it and treat it as such. It's already out in the open, why hid…

> as long as it is single-threaded Yet, there is a well-known pattern, which is to have objects each running on its own thread . (Incidentally, this gives a new - I'd say, true - meaning to the notion of 'message passing' as the idea of how objects are to communicate.)

How many projects do you know that do that? Yes, the original intent of OOP is message passing between objects. But no on thought about massive parallel computing back then.

And how many objects do you want to run in its own thread? 10k? 100k?

Re: OOP Is Dead, Long Live OOP

#119

Earlier quoted context omitted.

> Just because prior literature exists, does not mean it should not be superseded. For example, generics wasn't even a thing when OOP originally started and yet LINQ and basic list ADT's wouldn't be as powerful without it. No, this not an example... generics did not "supercede" OOP.

My point is that earlier OOP documents did not implement generics. When they were finally implemented in OOP, it superseded the original intentions of OOP. The question is, are we now supposed to remove generics because they don't conform to the early literature of OOP? Looks like the OOP edited his comment though, so my point is irrelevant.

> My point is that earlier OOP documents did not implement generics.

> When they were finally implemented in OOP, it superseded the original intentions of OOP.

No, when they were implemented in static OOP, it brought static OOP closer to intentions of the original, dynamic, OOP, where generic-ness doesn't require parametric polymorphism.

Re: OOP Is Dead, Long Live OOP

#120

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…

Mixin inheritance is also inheritance, just linearized multiple inheritance actually.

Mixins can be modeled as inheritance or as composition.
Post reply on HN