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

141–150 of 357 posts

Re: OOP Is Dead, Long Live OOP

#141

Post by jf- »

ken wrote: post #127
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 he…

Depends on how needlessly argumentative your team is. Generally you can reach a consensus through discussion, example and experimentation. We do have intuition, generally we know what simple looks like when we see it, likewise we recognise what the right tool looks like as we try several.

Do you want a checklist for this kind of thing? You’re not going to get one. You have to use your own judgement.

Possibly you’ve fallen victim to being on teams where ego dominates, and members refuse to seek the best option unless they came up with it themselves.

Re: OOP Is Dead, Long Live OOP

#142

Post by jschwartzi »

ozim wrote: post #84
Sharlin wrote: post #65

Earlier quoted context omitted.

> Liskov substitution is useless, you should not use inheritance but composition. Liskov substitution is more about interface inheritance than implementation inheritance, really. LSP basically says that the implementer of an interface must obey the contract the interface specifies. As a real-world example, throwing UnsupportedOperationException in a method implementation is an LSP violation. Of course, this makes it…

Ok yes, it is about subtypes and interface is quite of an abstract base class. But if you have interface as in Java or C# and maybe 2 or 3 implementations without complicated type hierarchy under it, it is not an issue in practice to be not strict about contract, because you can spot deviation from it and fix it quick (ideally you also have integration tests to spot it for you).

I think the point is to forget about specific language features for a moment and think about interfaces the same way a mechanical or electrical engineer does -- as things to be glued together.

Re: OOP Is Dead, Long Live OOP

#143

Post by [deleted] »

Chabs wrote: post #139
ilovecaching wrote: post #132

Earlier quoted context omitted.

Can you please point out exactly what I said when you say 'the behavior I'm criticizing OOP for'. Haskell typeclasses are very different from OOP inheritance or OOP classes. In any case, I don't see how that relates to the explicit criticisms I made.

> All in all, OOP is a toolkit for building bad abstractions: abstractions that do not easily model computation, that hide data. That's a fundamental property of type erasure, which is not exclusive to OOP, and far from the extent of what modern OOP is about

[deleted]

Re: OOP Is Dead, Long Live OOP

#144

Post by mehrdadn »

joering2 wrote: post #104
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…

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.

I don't really follow this. A fleshed-out example describing the trade-offs is almost mandatory for this kind of criticism since this could be very easily due to a misunderstanding or misapplication of OOP rather than a problem with it.

Re: OOP Is Dead, Long Live OOP

#145

Post by dvlsg »

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.

I think composition and mixins should be kept separate. In my mind (and maybe I have an incorrect view of it), mixins throw a bunch of new properties on the base object, whereas composition keeps the original object encapsulated in a single property. Would you consider the second type to be a mixin? I've never heard it described that way.

Re: OOP Is Dead, Long Live OOP

#146

Post by Jtsummers »

beders wrote: post #118
Koshkin wrote: post #94

Earlier quoted context omitted.

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

I'd be comfortable with hundreds of thousands or millions of concurrently executing objects. If your system was actually operating in the "message passing" concept of OO, this wouldn't be impossible to support.

Now, you'd need something lighterweight than many threading libraries (such as C++ and Java programmers usually use), you'd want something closer to Erlang's process model.

Re: OOP Is Dead, Long Live OOP

#147

Post by eecc »

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?

IMHO OOP was a part of the big Software Factory model: a relatively simple, quick to understand tool to onboard masses of superficially trained workforce. A few enlightened Architects and Leaders would paint large strokes of class, collaboration, sequence diagrams while hundreds of "coders" would translate these "visions" into shippable artifacts.

You know how well that ended... ;)

... oh, and watch out for Go! ducks

Re: OOP Is Dead, Long Live OOP

#148

Post by fooyc »

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…

It looks like that you are working on stuff that may not benefit from OOP. You seem to be doing heavy « computations », you care more about the data than the logic around it. Probably Haskell suits your usecases more.

Re: OOP Is Dead, Long Live OOP

#149

Post by Aloisius »

ilovecaching wrote: post #110
Chabs wrote: 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).

Under the original definition of OOP as various alternate definitions, Rust would be OOP. This is all covered here:

https://doc.rust-lang.org/book/second-edition/ch17-00-oop.ht...

Personally, I think the idea that code isn't OOP just because you don't use inheritance to be utterly ridiculous.

Re: OOP Is Dead, Long Live OOP

#150

Post by jschwartzi »

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.

Well, my original point is that thread-safety is easy with the right abstractions, and that choosing your abstractions is a conscious thing. So I don't see how mutability is "inherently thread-unsafe." Rather, programmers are "inherently thread-unsafe" and we have a responsibility to understand the problem domain and choose abstractions that make sense to us and that actually solve the problems we're encountering.

Now if you want to talk about specific languages, then I would generally agree with you about C++ and C, but then there are ways you can design a program in those languages to be thread-safe. With FP you're just choosing a different solution to the problem which comes with its own drawbacks in some cases.

Post reply on HN