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

281–290 of 357 posts

Re: OOP Is Dead, Long Live OOP

#281

Post by westoncb »

Twisol wrote: post #277
westoncb wrote: post #234

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

That makes a lot of sense to me. Looking forward to checking out "Boundaries".

Btw, one other idea I've had on the subject is that the problems with mutable state can be mitigated if we were able to more easily see/comprehend the state as it's being modified by a program; without that capability the only recourse we're left with is our imagination, which of course is woefully inadequate for the task. You can see more concretely what I'm talking about in my project here (video): http://symbolflux.com/projects/avd

From what I've seen, structuring a program to not modify state is almost always more difficult than the alternative[0]. There are certain problems where this difficulty is justified (because of, e.g., reliability demands); but I think most problems in programming are not those, and if we could just mitigate the error-proneness of state mutation, that may leave us at a good middle ground.

[0] The exception is when you're in a problem domain that can naturally be dealt with via pure functions, where you're essentially just mapping data in one format to another (i.e. no complex interaction aspects).

Re: OOP Is Dead, Long Live OOP

#282

Post by humanrebar »

loup-vaillant wrote: post #241
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…

That's a solid plan for acceptance testing and a great way to make sure you can never test diagnostic, recovery, rollback, and other something-abnormal-happened-here logic.

For small programs with few interfaces to worry about, that might be fine, but as you number of users go up, the odds go up that you'll be ensuring rollback bits get flipped when filesystems fail. None of that is simple to test without some sort of dependency injection or other heavyweight design pattern.

Re: OOP Is Dead, Long Live OOP

#283

Post by humanrebar »

hota_mazi wrote: post #98
3pt14159 wrote: post #55

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…

Duck typing is the worst of all worlds, in my experience. And in defense of inheritance, the Liskov Substitution Principle is extremely useful and makes a lot of sense. If a function accepts a `Weapon` as parameter, surely you should be able to pass it a `Sword`.

Except Firearms require the reload() method be called periodically between calls to use(). So now we have to think about whether Swords need an empty reload() method or whether there need to be separate Firearms and Blade interfaces based on Weapon.

Re: OOP Is Dead, Long Live OOP

#284

Post by SolarNet »

ByThyGrace wrote: post #208
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?

I think the C++ library https://github.com/skypjack/entt gets pretty close to the ideal for a purely compile time implementation. It is implemented with modern C++ template meta-programming - which is to say it is basically a DSL encoded into C++ and can generate arbitrary code at compile time - while better than it used to be to read C++ template meta-programming is still very difficult to read. It also comes with a number of utility libraries for using it efficiently and correctly, including a signal library, service locator, and scheduler (among others).

It still has it's limitations though. Because it is a compile time library, it can't do any runtime optimizations like it could with a JIT. Also, because C++ reflection is atrocious, it doesn't provide the best support for runtime type manipulation (reflection features are often paired with the component pattern implementation, especially in general purpose game engines). This comes back to dynamically meta-programmed languages (e.g. python, lisp) that could theoretically out perform even ENTT using a JIT - with the appropriate reflection features - and meta-programming. However an ECS only really makes sense in a non-garbage collected language (or if the language exposes a non-GC meta-programming interface). Since there aren't really any viable JIT (+ reflection) + meta-programmed + non-GC languages out there, I don't think a perfectly correct implementation exists.

I think an ideally implemented example will eventually be Johnathan Blow's experimental language Jai (or a library for it) given what has been stated publicly about it (metaprogramming, JITted, reflection, not garbage collected, has built in support for SoA types). But that's not a viable example to look at at the moment.

Re: OOP Is Dead, Long Live OOP

#285

Post by humanrebar »

maemilius wrote: post #215
fooyc wrote: post #140

Earlier quoted context omitted.

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

My understanding of SRP is that the _implementation_ of those two things should be separate, not the interface.

Well, the I in SOLID is Interface Segregation, so there's a problem there too.

Re: OOP Is Dead, Long Live OOP

#286

Post by sidlls »

da02 wrote: post #238
sidlls wrote: post #131

Earlier quoted context omitted.

The engineering organization where I work is full of dysfunction. This is because numerous poor practices were ignored or encouraged over the years. Now there is strong inertia against change because the incompetent long-timers know all the tricks and manage their job security through the system as it is. This is not uncommon especially in the Bay Area.

What does the software or company do? For example, do they make software for accountants? Construction?

It's relatively young and the products are all mostly based on what is called data science and machine learning these days.

Re: OOP Is Dead, Long Live OOP

#287

Post by Twisol »

westoncb wrote: post #281
Twisol wrote: post #277

Earlier quoted context omitted.

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

That makes a lot of sense to me. Looking forward to checking out "Boundaries". Btw, one other idea I've had on the subject is that the problems with mutable state can be mitigated if we were able to more easily see/comprehend the state as it's being modified by a program; without that capability the only recourse we're left with is our imagination, which of course is woefully inadequate for the task. You can see more…

Oh, that's very cool! I had a similar idea years ago, but I didn't have the technical chops to pursue it at the time, and I ended up losing interest. I think this would actually be even more useful in the kind of architecture I'm describing, since the accumulated state has a richer structure, and many of the smaller bits of state that would be separate objects are put into a larger context.

> From what I've seen, structuring a program to not modify state is almost always more difficult than the alternative

You're not wrong! I don't think we should get rid of mutable state, but I do think we should be much more cognizant of how we use it. Mutation is one of the most powerful tools in our toolbox.

I've found that keeping a separation between "computing a new value" and "modifying state" has a clarifying effect on code: you can more easily test it, more easily understand how to use it, and also more easily reuse it. My personal experience is that I can more easily reason locally about code in this style -- I don't need to mentally keep track of a huge list of concepts. (I recall another quip, about asking for a monkey and getting the whole jungle.)

There is a large web app at my workplace that is written in this style, and it is one of the most pleasant codebases I've ever been dropped into.

Re: OOP Is Dead, Long Live OOP

#288

Post by westoncb »

Twisol wrote: post #287
westoncb wrote: post #281

Earlier quoted context omitted.

That makes a lot of sense to me. Looking forward to checking out "Boundaries". Btw, one other idea I've had on the subject is that the problems with mutable state can be mitigated if we were able to more easily see/comprehend the state as it's being modified by a program; without that capability the only recourse we're left with is our imagination, which of course is woefully inadequate for the task. You can see more…

Oh, that's very cool! I had a similar idea years ago, but I didn't have the technical chops to pursue it at the time, and I ended up losing interest. I think this would actually be even more useful in the kind of architecture I'm describing, since the accumulated state has a richer structure, and many of the smaller bits of state that would be separate objects are put into a larger context. > From what I've seen, str…

Interestingly, I think I built that project with an architecture somewhat reminiscent of the 'boundaries' concept (still just surmising at this point). It's a super simple framework with two types of things 'Domains' and 'Converters'. Domains are somewhat similar to a package... but with the boundaries actually enforced, so that you have to explicitly push or pull data through Converters to other Domains; Converters should just transform the format from one Domain to that of another (they are queue-based; also sometimes no translation is necessary).

I'll quote from the readme:

> This Domain/Converter framework is a way of being explicit about where the boundaries in your code are for a section using one ‘vocabulary,’ as well as a way of sequestering the translation activities that sit at the interface of two such demarcated regions.

Inside each Domain I imagine something like an algebra... a set of core data structures and operations on them.

But yeah, I have very frequently thought about visualizing its behavior while working on that visualizer :D

Is your research related to programming languages?

Also I'm going to have to think about "computing a new value" vs. "modifying state" —not sure I quite get it...

Re: OOP Is Dead, Long Live OOP

#289

Post by agentultra »

For me, whenever someone invokes the GoF or SOLID, I’m reminded of the Brothers Grimm. It’s programming by folklore. That’s all the GoF did: they went out into the world and tried to observe how programmers were structuring their programs. And they seemed particularly interested in programmers using OOP.

All of these principles have very little basis or formal definition. Bertrand Meyer did make some headway with Eiffel. But the type systems are so weak and the lack of formal semantics makes all of these discussions a bit of hand waving and bike shedding.

At least the DOD folks have some guiding philosophy and are trying to optimize the design of programs to account for memory latency of modern hardware architectures.

The OOP defenders are basing their argument on hot air and hand waving.

There are more interesting languages these days with better designs. Ones that are based on better theories in my opinion.

OOP will be around for a long time if only because it has so many adherents and people will be stubborn to change if history has anything to say about it.

Post reply on HN