Live data from Hacker News

OOP Is Dead, Long Live OOP

gamedev.net

101–110 of 357 posts

Re: OOP Is Dead, Long Live OOP

#101
post #9

If we just had made inheritance as something to be avoided unless absolutely needed then OOP would have probably never got such a bad reputation. All the other concepts make perfect sense.

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 OpenAL renderer, you have to have inheritance somewhere, because you have to store at least one function pointer at some point. std::function in C++ is implemented with inheritance. Rust traits are based on inheritance. However you look at it, you can never completely "get rid" of inheritance if you want to hide both code and data behind a single pointer. Hell, even the linux kernel written entirely in C reimplements vtables by hand for device drivers because it makes so much sense.

Re: OOP Is Dead, Long Live OOP

#102

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…

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.

Re: OOP Is Dead, Long Live OOP

#103
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…

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

What's a couple orders of magnitude of performance and some heavyweight link time dependencies between objects?

Re: OOP Is Dead, Long Live OOP

#104

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.

Re: OOP Is Dead, Long Live OOP

#105

Earlier quoted context omitted.

Consultant here, and I think that's a big blind spot we tend to have: we don't stick around for long enough to see the consequences of what we designed, usually.

I have more experience at startups than as a consultant. I was the 6th hire at a company that grew to 130 over three years and I was never thinking more than a few months in advance. A lot changes in five years — your customers, the competitive landscape. It's an enormously long period of time in technology. It seems like such a waste of time when you have customers that have real, unsolved problems today

Unless it's some one off batch process or a prototype, if the codebase doesn't last at least six months then it's unlikely to be something that makes any money.

In my experience, badly designed code tends to become a net loss after a couple of months because after that time someone is going to have to modify or fix it.

Re: OOP Is Dead, Long Live OOP

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

Re: OOP Is Dead, Long Live OOP

#107
post #9

If we just had made inheritance as something to be avoided unless absolutely needed then OOP would have probably never got such a bad reputation. All the other concepts make perfect sense.

Or… if you're talking about languages like C# and Java (and presumably C++), just make sure all of your classes are either sealed or abstract. This turns classes into proper algebraic data types.

To wit, implementation inheritance gives you a sum type (e.g. a Shape is either a Circle, or a Square, or…) whereas interface inheritance gives you a product type (class Foo : IBar, IBaz means that Foo is an IBar and an IBaz).

Re: OOP Is Dead, Long Live OOP

#108
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…

Except for the fact that objects can be serialized and ORM's exist to convert your data into OOP. How do you think Entity Framework works? How do you think Rails works? You can build almost an entire ORM from a database without even writing any code in Entity Framework.

> And if you want to use other people's objects (say from a library) you first have to make a layer that translates them from your own objects

Funny, I've been using .NET framework objects without any type of translation. And the point is to use inheritance to mitigate the translation.

Don't blame the model for its poor use. If there's no way to get the data you need, then that means the class was designed so you didn't actually need it or there are other ways to get it (i.e. through an interface).

>Clojure gets it right and that's what I use.

Except Clojure uses OOP principles and even admits to saying it uses immutable objects in the form of interfaces. Interfaces are essentially stripped down abstract classes. How this is not a subset of OOP, I don't know.

I'm sure Clojure is great, but can you write interactive applications with it without integrating OOP libraries?

Re: OOP Is Dead, Long Live OOP

#109

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.

You're quoting Joe Armstrong, creator of Erlang

> Because the problem with object-oriented languages is they’ve got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle.

Re: OOP Is Dead, Long Live OOP

#110
post #102

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…

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

Post reply on HN