Live data from Hacker News

OOP Is Dead, Long Live OOP

gamedev.net

221–230 of 357 posts

Re: OOP Is Dead, Long Live OOP

#221

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…

Also for those of you doing OOP looking to try something different:

Java/C++ -> Rust: It will feel familiar to you with its C style syntax and multi-statement function bodies. It takes the best parts of many different paradigms, and marries them in a very coherent way. It's performant, has incredible tooling (cargo, rustup), and the community is great.

Python/Ruby -> Elixir: Elixir has the Phoenix framework, great support for web, and supports massive concurrency using the Actor model. Jose did a great job cleaning up the Erlang syntax, and it's gradual typing and heavy use of macros will feel immediately familiar to you.

Re: OOP Is Dead, Long Live OOP

#222
post #140

Earlier quoted context omitted.

I've found that inheritance is very useful in one situation, and adds nothing over mixins otherwise. If a class does two broad things simultaneously then inheritance can work great. For example, a User class that inherits from a DB mapper class. I don't want to have to tell my class how to write a record to the DB. All that code can be centralized into one thing and then relied upon for its uniformity across all my m…

> I don't want to have to tell my class how to write a record to the DB You don’t need inheritance to achieve this. Your User class contains data and probably some business logic. The fact that it’s going to be persisted in a database at some point is a detail that the class shouldn’t know. Consider using the data mapper pattern (or an ORM implementing this pattern). In this pattern, your User object doesn’t even kno…

Active Record should be considered an anti-pattern and is definitely in violation of single responsibility at the least.

Myself, I wouldn't even put any business logic in the User object, except maybe representational logic (e.g. have a couple of helper methods that return multiple representation of the same piece of data).

One of the best things to do is separate behavior from data in the first place, which feels kind anti-OO philosophy, but is definitely easier to reason about and work with.

Re: OOP Is Dead, Long Live OOP

#223

Earlier quoted context omitted.

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…

extends != implements

Re: OOP Is Dead, Long Live OOP

#224

Earlier quoted context omitted.

You are confusing inheritance of implementation with inheritance of interface. The consensus is to use inheritance of interfaces and use composition to implement the interfaces. Hence my phrasing: "Inheritance is better achieved through composition".

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.

Re: OOP Is Dead, Long Live OOP

#225

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…

For some reason 'arguments' against OOP seem to follow a common pattern. You have said many things against OOP, but you haven't actually presented an argument for why it's bad. I'll present each of your assertions here individually to clarify. > OOP is prove a poor model for computation > OO code is almost always significantly more complex and error prone than an equivalent computation written in a concurrent, functi…

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 think OOP not the way (no sum types, cumbersome support for behavioural parameters, and above all an unreasonable encouragement of mutability), but then I have to justify why those points are important, and why they even apply to OOP (it's kind of a moving target). Overall, all I'm left with is a sense of uneasiness and distrust towards OOP.

Re: OOP Is Dead, Long Live OOP

#226
post #218

Earlier quoted context omitted.

Go interfaces, Rust traits, and Haskell typeclasses and simple parameters do exactly what you ask. In fact, it's harder to mock/stub in OOP than it is in FP by the nature of FP making all dependencies always explicit. Being able to use a 'property' in the body of the functions means you're now relying on a side effect that will have to be magically mocked. In OOP, type signatures tend to lie. Not so true for FP.

The problem with simple parameters is that I need to drag all of my low level stuff through all of the layers of the application. I one was imagining a framework for Closure that would do something like that: - you define a bunch of functions. Some of this functions depend on other of those functions. - for dependent ones you define parameters and tag them somehow - you call this functions without mentioning those ta…

That's what composite values are for, combining related pieces of data such that they can be threaded through an application as a unit. State in FP is passed this way through an application.

Adding a framework is a premature abstraction that is likely a sign that you've got your types wrong.

Re: OOP Is Dead, Long Live OOP

#227
post #213

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?

Yes

Re: OOP Is Dead, Long Live OOP

#228

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…

For some reason 'arguments' against OOP seem to follow a common pattern. You have said many things against OOP, but you haven't actually presented an argument for why it's bad. I'll present each of your assertions here individually to clarify. > OOP is prove a poor model for computation > OO code is almost always significantly more complex and error prone than an equivalent computation written in a concurrent, functi…

Such a precise epistemic analysis should be incentivised on hacker news. Thank you.

Re: OOP Is Dead, Long Live OOP

#229

Earlier quoted context omitted.

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

You are confusing inheritance of implementation with inheritance of interface. The consensus is to use inheritance of interfaces and use composition to implement the interfaces. Hence my phrasing: "Inheritance is better achieved through composition".

> The consensus is to use inheritance of interfaces and use composition to implement the interfaces.

A consensus by the "maximization of boilerplate" rule.

Inheritance is the most powerful tool available at the OOP land. It's the one thing that FP languages still didn't replace with enough added advantages to make the OOP stuff look like a toy. So if you are programming in OOP while avoiding inheritance, you would be certainly better in another paradigm.

(And, of course, powerful tools are easy to misuse. That's no reason for forbidding them.)

Re: OOP Is Dead, Long Live OOP

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

It failed by teaching that every data structure should be put into classes using many levels of inheritance, interfaces, encapsulation, accessors and the whole shebang when the thing really is just a plain old integer. OOP is really useful and powerful in many areas and applications but it is not the only tool that has to be used for everything.

That sounds like a failure of the teachers then, not of OOP.
Post reply on HN