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

271–280 of 357 posts

Re: OOP Is Dead, Long Live OOP

#271

Post by cryptica »

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…

I don't understand what the problem with OOP is. My OOP code has always been clean and easy for myself and other people to read and modify.

When I read articles complaining about OOP, I just can't relate at all.

The idea of functional programming makes no sense to me except for writing very specific simple programs. For example, I like using some functional programming on the front end with VueJS but even there, I still allow mutations in certain parts of the code.

I like being able to store state in different instances and allow it to be mutated independently of each other.

I like it when related logic and state is kept close together in the code; it makes it easy to reason about different parts of the code independently.

On the other hand, with functional programming, it can be difficult to figure out where state comes from because there is very little abstraction to separate different parts of the code.

Re: OOP Is Dead, Long Live OOP

#272

Post by maxxxxx »

blindwatchmaker wrote: post #267
maxxxxx wrote: 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.

Mutable internal state is problematic with or without inheritance.

There are plenty of use cases where you need internal state. Think about UI in a desktop app for example. Not everything is a data pipeline with a clear in and out.

Re: OOP Is Dead, Long Live OOP

#273

Post by maxxxxx »

spdionis wrote: post #224
jcelerier wrote: post #166

Earlier quoted context omitted.

But you still use the OOP concept of inheritance, which is basically "indirect methods with function pointers". Beside, "interfaces" don't even exist as a syntaxic concept in many OOP languages, C++ being the most prominent one.

I think C++ is the only one that doesn't have interfaces.

An abstract class with only abstract methods is essentially the same.

Re: OOP Is Dead, Long Live OOP

#274

Post by bribri »

I can't think of any oop abstractions that I prefer to functional abstractions. If you really need has-a is-a relationships or mutability you can get them a la carte with a language like Clojure, but they're not deeply baked in to the language nor the encouraged pattern for extending code.

Re: OOP Is Dead, Long Live OOP

#275

Post by noblethrasher »

da02 wrote: post #264
noblethrasher wrote: post #199

Earlier quoted context omitted.

Well, the best analogue to the Codd's relational algebra is Hewitt's actor model in my professional opinion. Both are based on mathematical formalism, though the Actor Model goes a bit further in that it's also informed by physics. But, just as SQL doesn't really implement Codd's relational algebra, so it is the case that most so-called OOP languages miss the mark vis-à-vis Alan Kay's original conception. The analogy…

Kay also mentioned the Internet is an OO system. At one point he was thinking every object would have it's own IP address. He does have an account here on HN. https://news.ycombinator.com/threads?id=alankay1 I hope he doesn't get tired of explaining the same things over-and-over again. I have asked questions and he has answered, but I usually end up misinterpreting the ideas. :(

Yep, I follow him pretty closely, and knew about his account and comments on here.

Funny story: That is at least the second account that he created on HN. He registered an earlier one just to reply to a comment that I had made[1].

[1]: https://news.ycombinator.com/threads?id=alanone1

Re: OOP Is Dead, Long Live OOP

#276

Post by kroltan »

blub wrote: post #213
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…

You develop web services professionally in Haskell, Erlang and Rust, but you think that Java-style OOP is too complex?

I don't think it is the case that a certain programming paradigm can be intrinsically harder, maybe only less practiced.

OOP / imperative style is almost the norm nowadays, but that doesn't imply it's the "easiest", just the one that got the most momentum (which can be attributed to social factors moreso than technical ones), and thus is widely taught and talked about, which helps with education on such style.

Re: OOP Is Dead, Long Live OOP

#277

Post by Twisol »

westoncb wrote: post #234
loup-vaillant wrote: post #225

Earlier quoted context omitted.

The pattern you talk about is mainly a product of not wanting to squeeze a whole essay into an HN comment. I also suspect the problems with OOP are hard to communicate. I for one always had a problem with OOP, but I could never quite point it out. Sure, when faced with an OOP design, I could almost always find simplifications. But maybe I never saw the good designs? Maybe this was OOP done wrong? I do have reasons to…

> The pattern you talk about is mainly a product of not wanting to squeeze a whole essay into an HN comment. That may very well apply to the GP's comment—but, my observation of the pattern is derived from a mix of mini-essay comments, and articles people are writing on Medium or their blogs or whatever, where the space constraints aren't so tight. There are a couple things you'll regularly find: laughably bad straw-m…

> Additionally, we don't have a mature theoretical framework for making the comparisons.

This is really the problem. As much as I have strong opinions and beliefs about how to architect code, every argument I come up with boils down to some flavor of "I like it better this way". Which is true -- I do like it better this way -- but hardly actionable, and it doesn't get at the essence of why I like it better.

The problem with making everything an object -- or more precisely, having lots of mutable objects in an object space with a complex dependency graph -- is that it becomes very hard to model both how the program state changes over time and what causes the program state to change in the first place. I think the prevailing OOP fashion is to cut objects and methods apart into ridiculously small pieces, which takes encapsulation and loose coupling to an extreme. This gives rise to the popular quip, "In an OOP program, everything happens somewhere else." I can't think straight in this kind of setting.

I believe that mutable state should be both minimized and aggregated. As much as is humanly possible, immutable values should be used to mediate interactions between units of code (be those functional or OO units), and mutation should occur at shallow points in the call stack. Objects can work well for encapsulating this mutable state, but within the scope of an object, mutation should be minimized and functional styles preferred.

Using a functional style doesn't mean giving up on loose coupling or implementation hiding. Rust, Haskell, and plenty of other languages support these same concepts in the form of parametric polymorphism, e.g. traits or typeclasses. It does mean giving up on the idea that you can mutate state whenever it's convenient. Instead, you have to return a representation of the action you'd like to take, and let the imperative shell perform that action.

Speaking of imperative shells and functional cores, Gary Bernhardt's talk called "Boundaries" is an excellent overview of this kind of architecture [1]. There was also a thread here on HN about similar principles [2].

[1] https://www.destroyallsoftware.com/talks/boundaries

[2] https://news.ycombinator.com/item?id=18043058

Re: OOP Is Dead, Long Live OOP

#278

Post by da02 »

noblethrasher wrote: post #275
da02 wrote: post #264

Earlier quoted context omitted.

Kay also mentioned the Internet is an OO system. At one point he was thinking every object would have it's own IP address. He does have an account here on HN. https://news.ycombinator.com/threads?id=alankay1 I hope he doesn't get tired of explaining the same things over-and-over again. I have asked questions and he has answered, but I usually end up misinterpreting the ideas. :(

Yep, I follow him pretty closely, and knew about his account and comments on here. Funny story: That is at least the second account that he created on HN. He registered an earlier one just to reply to a comment that I had made[1]. [1]: https://news.ycombinator.com/threads?id=alanone1

Ha ha. I always wondered why that lonely one-comment account existed. I suspect many people are using data abstraction and calling it OOP. I am not a professional programmer. What do you like to use when designing software? Functional? Types? C? Haskell? Pharo?

Re: OOP Is Dead, Long Live OOP

#279

Post by ww520 »

ilovecaching wrote: post #170
fooyc wrote: post #148

Earlier quoted context omitted.

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.

Actually I work primarily on web services. We benefit from Haskell in that HKTs allow us to model our service completely in the type system. Our Rest and GraphQL API are completely modeled in a type level DSL. Once we've ingested data, which can then be validated automatically using types, we can then express our data transformation in a way that makes the transitions extremely transparent in our code. Our backend se…

Sounds like the service in your case is a sessionless gateway that does data transformation and dispatching. It fits the functional style.

Re: OOP Is Dead, Long Live OOP

#280

Post by SolarNet »

Hodgman wrote: post #252
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…

The fact the the original code is a straw-man is discussed. The fact the flexibility is being removed is discussed too, along with why it was there and hits on better ways to re-achieve it later. It's mentioned that these were going to be covered in a follow-up. You need to work on your speed reading skills before throwing shade...

> The fact the the original code is a straw-man is discussed.

Yes, but instead of timing it against the improvements the grand-author made to the straw man, you still timed it against his straw man.

So I'll quote you: "You need to work on your speed reading skills before throwing shade..."

> The fact the flexibility is being removed is discussed too

You state: "Why do these frameworks exist then? Well to be fair, they enable dynamic, runtime composition. Instead of GameObject types being hard-coded, they can be loaded from data files. This is great to allow game/level designers to create their own kinds of objects... However, in most game projects, you have a very small number of designers on a project and a literal army of programmers, so I would argue it's not a key feature."

Which is failing to recognize that the whole point of the original code - written by a game engine developer - is to demonstrate exactly how to do this for performance and flexibility for any small team.

> along with why it was there and hits on better ways to re-achieve it later. It's mentioned that these were going to be covered in a follow-up.

With out it being there, I cannot judge it. But considering that you removed features and barely managed to match the ECS for performance is... not promising.

The point of the ECS is to be a very efficient solution to the run-time composition problem. You removed run-time composition and still weren't technically able to be more performant than it with your solution. You are comparing apples to oranges and still loosing on arguably the most key aspect of the entire problem space!

Post reply on HN