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

121–130 of 357 posts

Re: OOP Is Dead, Long Live OOP

#121

Post by jshowa1 »

ilovecaching wrote: post #99

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…

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

Re: OOP Is Dead, Long Live OOP

#122

Post by stochastic_monk »

Chabs wrote: post #3

One thing that I'm surprised this doesn't cover, especially since it's so C++-centric, is that modern C++ OOP is much more defined by lifetime/scope management than anything else. What defines something as an object is the fact that it doesn't exist until it is constructed, and doesn't exist after it gets destructed (which is the case even for fundamental types, with the exception of char/std::byte, btw). Hot take: R…

RAII is my primary use for objects in C+++, and I believe Rust is similar. Inheritance has fewer uses for me.

Re: OOP Is Dead, Long Live OOP

#123

Post by mehrdadn »

jshowa1 wrote: post #115
mehrdadn wrote: post #32

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.

So what? Early cars didn't have AC, therefore AC superceded cars? Or therefore I'm somehow arguing we should use AC instead of cars?

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

Who ever claimed such a thing in the first place? It certainly wasn't me. If there is any question like this under discussion, it is whether OOP should should be removed because generics somehow superceded them (your idea), not the other way around. In either case the answer is clearly No because the idea is obviously ridiculous and not something anybody suggested.

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

Not sure what this is referring to, but I haven't been able to agree with your comment since it was initially written.

Re: OOP Is Dead, Long Live OOP

#124

Post by michaericalribo »

jshowa1 wrote: post #121
ilovecaching wrote: post #99

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…

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

https://en.wikipedia.org/wiki/Argumentum_ad_populum

Re: OOP Is Dead, Long Live OOP

#125

Post by ilovecaching »

jshowa1 wrote: post #121
ilovecaching wrote: post #99

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…

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?

Re: OOP Is Dead, Long Live OOP

#126

Post by seanmcdirmid »

pitaj wrote: post #120
seanmcdirmid wrote: post #82

Earlier quoted context omitted.

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

Mixins can be modeled as inheritance or as composition.

Both Flavor-style mixins and Bracha style mixins utilize inheritance. All mixin definitions should fan out from that early work.

Re: OOP Is Dead, Long Live OOP

#127

Post by ken »

jf- wrote: post #75

Software developers are systematisers by default. We tend to value complexity for it’s own sake, hence the over-engineering common to software projects. The methodologies we use fall victim to the same tendency. We build complex, rigid rule sets that are claimed to improve software or development speed or whatever else, without any actual empirical evidence that these claims are true. All you can really do is try to…

> use the right tool for the right job, and try to keep things as simple as possible

Now all we need to do is get the field to agree on universally applicable definitions of "right tool" and "simple", and never change any requirement after any technical decisions have been made, and we'll be all set!

I had a manager who used the term "ice cream" for phrases like this that sound good (everybody loves it!) but don't help drive any useful conversations or decisions. Should we use the right tool for the job, or the wrong one? Let's use the right one! OK, are we all agreed? Great! It's unanimous. Next issue.

Unfortunately, the 5 people sitting around the table each have a completely different conception of what this means, so we're no closer to a decision than when we started. It's simply not a useful guide or metric. I think it's mostly code for "be quiet and do as I say".

Re: OOP Is Dead, Long Live OOP

#129

Post by jschwartzi »

gambler wrote: post #54
Sharlin wrote: post #20

I’d be very wary of hiring an ”OO” dev who can’t reasonably formulate what the SOLID principles are and why they exist.

SOLID is mostly a bunch of over-confidently stated opinions. Here is my over-confidently stated opinion: if a principle is not applicable to Smalltalk 74, it is not essential to OOP. The only rule in SOLID I would say someone should follow at all times is L, and even then only in statically typed languages. This should be obvious . For example, can you define "responsibility" in any way that's not entirely gut feelin…

It's not really gut feeling. The following is very abstract but it's how I think about the "single-responsibility principle."

When you're designing a software system you need to step back from the individual components for a moment and consider the overall system -- who is using this system, what is the problem being solved here, and how does this solution relate to other problems and solutions within the system. It's not obvious only if you don't completely understand the problem domain, which most people don't.

If you find yourself thinking that some object's responsibility is ill-defined, you need to talk to whomever authored that part of the code to see if there's something you're missing about the system that the code controls. Either you are or they are, and at any rate the conversation will make the software system better somehow, which is the goal.

So once you understand the system and you understand the problem that you're trying to solve, and you think you have a solution, it's an exercise for you to sit down and identify specific activities that the software system has to undertake in order to solve the problem within the context of the system. You can consider these "responsibilities" at a top level and start partitioning them up further into classes that mutate and emit data in response to data received from other components of the system. The boundaries of these classes are interfaces, and each interface should be responsible for operating on a specific kind of data in response to its inputs.

Now the interface itself also needs to be defined in terms of the problem the class is solving. So you use words like "setMotorSpeed" on a class called "ConstantSpeedServo," and your ConstantSpeedServo might be composed with a "ValveController" which is responsible for controlling the position of a valve based on some input data.

This all goes back to thoroughly understanding the system you are controlling so that you can write code in terms of that system, but it goes beyond that in that you have to be very explicit in your understanding of what it is the system does in order to write software that accomplishes that goal.

Re: OOP Is Dead, Long Live OOP

#130

Post by simongray »

jshowa1 wrote: post #108
simongray wrote: post #72

Earlier quoted context omitted.

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

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

That was actually sort of my point. You need all of this extra stuff _because_ your code is all objects. Data doesn't get serialised, data just gets sent and then it gets received. Why should you spend time serialising and de-serialising an object, when you can just send your map data structure directly? Maps can be represented 1:1 as e.g. JSON. Any JSON data is basically a big map data structure. It's one function call instead of hours of writing ORM classes or custom serialisation methods just to send some data over a wire.

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

You don't use interfaces in Clojure, you tend to use multi-methods for most purposes where an interface is needed.

I wouldn't say Clojure uses OOP principles. Its core is written in Java, so obviously that part is forced to use objects, but that is only used to create the immutable data structures used in Clojure, which are represented as data literals, not as objects. You typically don't operate on objects in Clojure unless you're doing interop with Java or JavaScript. Instead what you do is use pure functions that take immutable data as input and spits out new immutable data. There is no object to consider, only the raw input data. A vector or a map is as much of an object as a struct or an enum. Those are data types that also existed in C, not exactly intended as an object-oriented language.

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

Well, yeah? Why wouldn't you be able to?

Post reply on HN