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

201–210 of 357 posts

Re: OOP Is Dead, Long Live OOP

#201

Post by ozim »

jschwartzi wrote: post #142
ozim wrote: post #84

Earlier quoted context omitted.

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.

No, Liskov substitution is much more abstract level, if you go with physical interface definition it does not work at all. It is not about attaching things but about type hierarchy. Thing you describe does not account for Covariance and Contrvariance and then it also goes into generic types which also huge abstraction which does not fit in physical world.

Re: OOP Is Dead, Long Live OOP

#202

Post by shady-lady »

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…

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

Did you have many years experience with Java/C++ beforehand?

Re: OOP Is Dead, Long Live OOP

#203

Post by vietjtnguyen »

ahansen wrote: post #154
vietjtnguyen wrote: post #96

Earlier quoted context omitted.

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

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

I guess I meant to ask what they mean by dependency injection. A bare version is just passing dependencies as arguments and I can't imagine what is so egregious about that. Maybe they mean something more complicated?

Re: OOP Is Dead, Long Live OOP

#204

Post by ilovecaching »

Aloisius wrote: post #149
ilovecaching wrote: post #110

Earlier quoted context omitted.

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.

Except that Rust lacks almost all of the features and terminology you'd expect of an OOP language. Again, I take OOP to mean what one learns in school... A class based language with inheritance, overloading, visibility of members, constructors, etc.

Rust can define behavior on any type of data, including scalar values. There is no concept of a "class" and constructors and simple functions that return instantiated values. They are not automatically called when a value is instantiated. Traits are more like interfaces, they constrain an implementer. A value has no way of inheriting behavior. Visibility is at the package level, and Rust offers no notion of encapsulation inside of a package.

Rust is, by the trending definition of OOP, not OOP.

Re: OOP Is Dead, Long Live OOP

#205

Post by ilovecaching »

shady-lady wrote: post #202
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…

> 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++). Did you have many years experience with Java/C++ beforehand?

I started as a C++/Python developer. I learned C++ and Python in school, and wasn't exposed to Haskell or Erlang until later in my career. I've also professionally written Ruby, Java (Swing/Spring), Rust, and Go.

Re: OOP Is Dead, Long Live OOP

#206

Post by Waterluvian »

ken wrote: post #188
Waterluvian wrote: post #8

Earlier quoted context omitted.

I think this relates to what you're saying. I've never felt any frustration that OOP feels like the wrong tool when I'm using languages that give me the choice to use it or not (like Python, and JavaScript). But when I'm using Java, as one example, it often feels like I'm really locking myself into a design up front. In Python, especially. I'll find myself starting off all experiments or simple projects with function…

> I've never felt any frustration that OOP feels like the wrong tool when I'm using languages that give me the choice to use it or not (like Python, and JavaScript). Do you not miss more advanced features, like multiple dispatch? Do you just implement it ad-hoc when you need it? I don't know any way to say it that doesn't come off sounding condescending, but this looks like the Blub Paradox to me. Python's brand of O…

It's not something I've ever needed with such frequency that I wished it was in the core langauge. When I need it I just use a library that exposes it. I use a decorator based multidispatch.

Re: OOP Is Dead, Long Live OOP

#207

Post by steveklabnik »

Aloisius wrote: post #149
ilovecaching wrote: post #110

Earlier quoted context omitted.

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.

So, I wrote that chapter, and part of why we don't really discuss definitions is that there are so many conflicting ones. Instead, we tried to focus on goals, and how they'd apply to Rust.

Personally, I believe the two big OOP definitions are "Java OOP" and "Smalltalk OOP", and Rust fits neither. People coming from heavy OOP backgrounds really struggle with Rust for this reason. It's also why this chapter was the hardest one to write.

Java: https://docs.oracle.com/javase/tutorial/java/concepts/ (Sometimes phrased as "Encapsulation, Inheritance, Polymorphism, Abstraction")

Smalltalk: http://wiki.c2.com/?AlanKaysDefinitionOfObjectOriented

Re: OOP Is Dead, Long Live OOP

#208

Post by ByThyGrace »

SolarNet wrote: post #184

Everything here is bad and wrong on so many levels. It's hard to even wrap my head around the amount of wrong going on everywhere here. The initial Object Oriented (OO) code - as partially demonstrated by the author, and more succinctly by the grand-author - is badly designed. In the grand-author's slides they remove a number of these stupidities, which the author appears to ignore (both for final performance compari…

Can you cite or link to properly implemented ECS solutions, in your opinion?

Re: OOP Is Dead, Long Live OOP

#209

Post by [deleted] »

ilovecaching wrote: post #116
arendtio wrote: post #112

Earlier quoted context omitted.

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

[deleted]

Re: OOP Is Dead, Long Live OOP

#210

Post by derefr »

ilovecaching wrote: post #204
Aloisius wrote: post #149

Earlier quoted context omitted.

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.

Except that Rust lacks almost all of the features and terminology you'd expect of an OOP language. Again, I take OOP to mean what one learns in school... A class based language with inheritance, overloading, visibility of members, constructors, etc. Rust can define behavior on any type of data, including scalar values. There is no concept of a "class" and constructors and simple functions that return instantiated val…

> Again, I take OOP to mean what one learns in school

Don't do that, then. "OOP" is a term-of-art in an academic discipline. It means exactly what it was used to mean by the people who coined the term in the papers they coined it in.

The thing that schools teach under the name "OOP" is a https://en.wikipedia.org/wiki/Lie-to-children intended to introduce something vaguely like OOP, not to introduce OOP itself.

---

And, before you ask: no, there is no academic jargon term for "the thing that C++ and Java are." From an academic perspective, neither language has any particular unifying semantics. They're both just C with more syntax.

OOP is a different set of semantics, based around closures (objects) with mutable free variables (encapsulated state), where an object's behavior is part of its state.

C++ and Java can simulate this—you might call this the Strategy pattern—but if you build a whole system out of these, then you've effectively built an Abstract Machine for an actually Object-Oriented language, one that ends up being rather incompatible with the runtime it's sitting on top of.

Post reply on HN