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

241–250 of 357 posts

Re: OOP Is Dead, Long Live OOP

#241

Post by loup-vaillant »

p2t2p wrote: post #177

All my attempts to jump off OOP train break at exact same moment when I try to write a unit test. Closure: or, simply use this monstrous component pattern when 70% of your code is boilerplate or hack into namespaces and override functions in them in runtime. And don’t forget to do it in right order! JavaScript: yeah, simply re-define ‘require’ before importing dependencies in tests. Yeah, do it in right order. Recent…

Give it up. Mocks are mostly useless.

If you want testable code, the first step is to separate computations from effects. Most of your program should be immutable. Ideally you'd have a mostly functional core, used by an imperative shell.

Now to test a function, you just give it inputs, and check the outputs. Simple as that.

Oh you're worried that your function might use some other function, and you still want to test it in isolation? I said give it up. Instead, test that other function first, and when you're confident it's bug free (at least for the relevant use cases), then test your first function.

And in the rare cases where you still need to inject dependencies, remember that most languages support some form of currying.

Re: OOP Is Dead, Long Live OOP

#242

Post by codetrotter »

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…

That sounds very interesting. Did you open source any parts of your code, write any blog posts about it or give any public talks about it? I would love to read/watch whatever you have available to the public :)

Re: OOP Is Dead, Long Live OOP

#243

Post by [deleted] »

Consultant32452 wrote: post #178
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…

My personal anecdotal experience is that OOP lends itself well to very very large codebases. A language like java with packaging, classes, and encapsulation strongly encourages some meaningful organization. Even if that organization is implemented poorly by the user, it's better than what I have seen users create in the real world with languages like C. If you have a project where a single person could reasonably und…

[deleted]

Re: OOP Is Dead, Long Live OOP

#244

Post by [deleted] »

tomelders wrote: post #69
learc83 wrote: post #37

Earlier quoted context omitted.

> that uses composition instead of inheritance What they are referring to as ECS is more than just composition over inheritance. There are entity component architectures that are just that--Unity's existing class based component architecture for example. But the ECS in this case refers to Data Oriented Design--basically laying out data like normalized database tables. Every component system has a table, and each row…

The confusing thing about the name “Entity Component System” is that “System” is thing in ECS. It’s not a system of Entities and Components, it’s a pattern thay has three parts; Entities, Components, and Systems.

[deleted]

Re: OOP Is Dead, Long Live OOP

#245

Post by josephg »

Consultant32452 wrote: post #178
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…

My personal anecdotal experience is that OOP lends itself well to very very large codebases. A language like java with packaging, classes, and encapsulation strongly encourages some meaningful organization. Even if that organization is implemented poorly by the user, it's better than what I have seen users create in the real world with languages like C. If you have a project where a single person could reasonably und…

I was a programming teacher some years ago and I would sometimes grade two submissions, which had both gotten full marks from the automated tests but where one was 150 loc and the other 500 loc. The most surprising part was that if I read the longer submission first, it would never really seem like there was that much excess code to take away. But obviously there was.

> My personal anecdotal experience is that OOP lends itself well to very very large codebases.

In my experience Java / C++ style OOP creates very very large codebases in the same way. I think its quite surprising that many engineers don't seem to have any idea how much waste there is in their "clean" java code. (Or C++ that follows the same style).

I also almost always find it far easier to read dataflow oriented code or functional code compared to their OO counterparts because all the state transitions are made absolutely clear. In OOP, your system state is spread across every file in the project. Compare to, say, a website implemented using React/Redux. I can inspect a single object to see the entire state of the application. When there's a bug, usually either that object has the wrong value (so I know how to fix it). Or the object has the right value and the bug is in the rendered component. Easy peasy. In comparison, in a java program the bugs often show up between classes. They end up relating to the relative timing of function calls that mutate state. Or the lifecycle of objects conflicting in weird ways. Its much worse for comprehension and much more work to debug. (And yes, I've spent years working in both styles professionally.)

Re: OOP Is Dead, Long Live OOP

#246

Post by Hodgman »

_halgari wrote: post #173
TeMPOraL wrote: post #24

Earlier quoted context omitted.

I don't think Entity-Component-System is Unity-specific. From what I recall from other articles, Unity has its own idiosyncratic implementation, but the pattern has several slightly different interpretations.

Correct, the first game to use ECS was Dungeon Siege back in 2002: https://www.gamedevs.org/uploads/data-driven-game-object-sys...

Dungeon siege used an "Entity/Component" framework. That's a very different thing to an "Entity/Component/System" framework.

Re: OOP Is Dead, Long Live OOP

#247

Post by jshowa1 »

mehrdadn wrote: post #123
jshowa1 wrote: post #115

Earlier quoted context omitted.

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

So you don't really know what I was originally talking about yet you continue to act like you do? My point was in a response to the OP's implication that somehow the original OOP literature was perverted by misunderstandings and wrong implementations of the current generation, as if the original OOP documents were somehow "pure".

I pointed out that just because the literature is original doesn't mean it can't be superseded. I gave generics as an example that was later implemented in OOP languages and fail to see how implementing these perverted the original intentions.

I was then told that OOP intentions were originally meant to be dynamically typed and that the static typing of generics was meant to put it towards the original intentions of this dynamic structure (this is untrue because Alan Kay just didn't like static typing, but didn't make dynamic typing a requirement for OOP). Upon further research, the earliest OOP concepts were explained in the 1960's and the first OO language (Simula) was statically typed and a superset of ALGOL 60 which was a language made in 1960, with Simula following in 1965. Smalltalk came in at 1972 (around the time of generics) and is considered the definitive OOP language which is dynamically typed.

So its hard to say, without direct sources, what the original intentions of OOP were, but considering OOP appeared before the first languages that contained generics (i.e. 1970's), generics is an idea that superseded OOP.

Considering the utility of generics, its clear that later concepts that were added to OOP did not somehow perverse the original literature.

So we've established the following: 1) The earliest OOP language (Simula) was statically typed. 2) Generics came in after Simula 3) The original intention of OOP could probably be attributed to Alan Kay, who created Smalltalk, but it borrowed heavily from Simula. And while Alan Kay coined the term OOP, the idea was not created in a vacuum as OOP concepts predate Smalltalk.

Hopefully this provides some clarification. But my guess is people will continue to misinterpret what I meant.

Re: OOP Is Dead, Long Live OOP

#248

Post by dkarl »

LolNoGenerics wrote: post #151

> This code may be typical of OOP in the wild, but as above, it breaks all sorts of core OO rules, so it should not all all be considered traditional. This argument drives me nuts. A simple OOP environment can be quite easy to grasp and (mis)use. Following all the golden rules and principles that SOLID et al call for, are comparabily hard to internalize. A rookie can only fail and has to collect, choose and study all…

Ruling the majority of OO code out there as "bad" is hubris and ignores reality. It is easy to do OOP wrong and hard to get it right.

It wasn't the inherent nature of OOP that caused that terrible style to become dominant. It's a style that was actively taught and promoted since at least the mid-1990s. It was taught, and taken for granted, that objects were containers for mutable values. Deep inheritance hierarchies were taught as the norm, not the exception. Java was built around this model and then became one of the most popular programming languages in industry, and learning materials for Java reinforced the style. Everyone interviewing for a Java programming position from the late 1990s through the mid 2000s had to learn special jargon related to this style and regurgitate it in interviews. We're suffering through a hangover from decades of this horrible version of OOP being promoted as the "right" way to write software in industry and academia.

Re: OOP Is Dead, Long Live OOP

#249

Post by Hodgman »

lerno wrote: post #183
zdmc wrote: post #176

A good heuristic: if you’re not dealing with “state” (i.e., Games, DB ORM, Reinforcement Learning), then don’t use OOP

Really? I’d say the accidental distribution of state across objects due to cross cutting concerns is exactly where OO breaks down for me.

If cross-cutting concerns are making your architecture unwieldy, you likely haven't used composition enough / are doing OOP the bad way (tm).

Re: OOP Is Dead, Long Live OOP

#250

Post by ilovecaching »

josephg wrote: post #245
Consultant32452 wrote: post #178

Earlier quoted context omitted.

My personal anecdotal experience is that OOP lends itself well to very very large codebases. A language like java with packaging, classes, and encapsulation strongly encourages some meaningful organization. Even if that organization is implemented poorly by the user, it's better than what I have seen users create in the real world with languages like C. If you have a project where a single person could reasonably und…

I was a programming teacher some years ago and I would sometimes grade two submissions, which had both gotten full marks from the automated tests but where one was 150 loc and the other 500 loc. The most surprising part was that if I read the longer submission first, it would never really seem like there was that much excess code to take away. But obviously there was. > My personal anecdotal experience is that OOP le…

We came to the same conclusion! Hidden state does make debugging difficult. Glad to hear our data points corroborate.
Post reply on HN