Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Case against OOP is understated, not overstated (2020)

boxbase.org

Post reply on HN
Print view View original

271–280 of 557 posts

Re: Case against OOP is understated, not overstated (2020)

#271

Post by reificator »

a-dub wrote: post #236
reificator wrote: post #218

Earlier quoted context omitted.

> asking the hard question... how does it stand up to the unpleasant cases? It's the best tool I know of for a certain class of problem, that's all I'm claiming. Not evangelizing it as a magical cure-all for all domains, just explaining it in enough detail that it can be understood by someone outside the domain of gaming. > what about when the abstractions age and a new feature for a system needs the data from the co…

thanks for humoring me! i'm writing because i'm genuinely interested. so it seems like then, that the discipline in building a system in this fashion revolves around responsibility for updates (which system is the sole updater of a given type of component) and the sequencing of those systems (ensuring that all the systems that update components that are used by a given system have completed their updates, possibly wi…

That’s a very good question, because sequencing tends to be the place where implementations vary the most.

Usually there will be some way to sort systems into steps and define the order of those steps. Some require you to hardcode the order, others define constraints like “after input” or “before physics” and attempt to solve those constraints, and some let you define groups that can run together and you define the order of the groups. Explicit signaling is not typically built in, but you may be able to implement it yourself if desired.

In environments with an expressive type system, most tend to favor the constraints model. Otherwise ordering tends toward the hardcoded approach, typically implicitly in registration order.

As to managing what systems are responsible for updating a given component’s state, that tends to be left to the game developer.

Sometimes there is a concept of events and if it’s not obvious who should mutate something then systems that want to mutate will send events that later systems can consume. For instance an input system and an AI system might both send a Move(entity, direction) event that a later system validates and applies.

And because it’s cute to do so, often times those events will be implemented as components themselves, with convenience wrappers to make it feel more natural to end user developers. This can come in handy for networked games and debugging in editor. You could also use it in game, such as displaying a unit’s next planned move in a turn-based game.

Re: Case against OOP is understated, not overstated (2020)

#272

Post by capitalsigma »

> On claims of unit testing and OOP, I'm not going to go there much more because I still don't unit test my stuff. I'm currently not against it. I just don't know about it much. I find it much easier to formally verify things correct than to test that they're correct.

Ah, I see, OP has never written nontrivial code.

Re: Case against OOP is understated, not overstated (2020)

#273

Post by leephillips »

woggy wrote: post #265

> To see where the problem is, just think about this: If int/float were separate modules that do not depend on each other, where the (int,float) and (float,int) pairs should be defined? Nowhere? Somewhere? In either one of the modules but why? I'm confused by this argument against multiple dispatch. Can't there be a third module that references both?

Of course there can. The objection makes little sense.

Re: Case against OOP is understated, not overstated (2020)

#274

Post by derbOac »

_9omd wrote: post #268

I never understand all the hate for certain tools. OOP is a tool, FP is a tool, and other programming paradigms are different tools. If you're bad a software architecture and you tend to write convoluted OOP software, you're probably also going to make a mess using FP as well. Applied correctly, they can both be great tools for different problem sets. Writing something that inherently has a lot of state, like a simul…

I generally feel the same, although I can say just as a pragmatic issue, the biggest problems I have ever faced in programming by far have been in dealing with poorly structured inheritance systems and object hierarchies in other peoples' libraries. Bugs are inevitable but problems with object hierarchies seem to screw up everything unnecessarily in a way that doesn't happen in less object-oriented functional and procedural languages. Sometimes it feels like this extra layer of ways to shoot yourself in the foot, and the feet of everyone around you.

Strong typing can be a blessing and a curse, and screwing up type signatures through poor foresight can be a problem regardless. But get into elaborate object systems and it can be a different level. When they're done well it's no problem, but when they're done poorly, it's maddening.

Re: Case against OOP is understated, not overstated (2020)

#275

Post by Mikeb85 »

There's a reason most complex software uses OOP. Functional programming is nice, sometimes, but as projects grow it ends up using patterns that do essentially the same thing as OOP. A monad is basically an OOP object.

To see a language that is purely OOP but also forces you to be very explicit about accessing state, check out Pony language.

Re: Case against OOP is understated, not overstated (2020)

#276

Post by chii »

Mikeb85 wrote: post #275

There's a reason most complex software uses OOP. Functional programming is nice, sometimes, but as projects grow it ends up using patterns that do essentially the same thing as OOP. A monad is basically an OOP object. To see a language that is purely OOP but also forces you to be very explicit about accessing state, check out Pony language.

> A monad is basically an OOP object.

i think it's the other way- an OOP object is a poor imitation of monadic algebra that cannot be generalized with mathematical rules to guarantee certain properties.

Re: Case against OOP is understated, not overstated (2020)

#277

Post by exdsq »

_9omd wrote: post #268

I never understand all the hate for certain tools. OOP is a tool, FP is a tool, and other programming paradigms are different tools. If you're bad a software architecture and you tend to write convoluted OOP software, you're probably also going to make a mess using FP as well. Applied correctly, they can both be great tools for different problem sets. Writing something that inherently has a lot of state, like a simul…

I do feel OO is the default for almost all companies and that requires a lot of debate to start to change so you can use other tools though. I remember working for a C# shop where I had to do some pretty simple data ingestion and cleaning from the NHS API that would have been fantastic in F# with it’s composition patterns, pattern matching, and type system. However because it wasn’t OO I couldn’t get support and so I had to write a lot of factories instead.

Re: Case against OOP is understated, not overstated (2020)

#278

Post by eschaton »

taurath wrote: post #14

In my mind, state is the real enemy impacting: comprehension, brittleness towards making changes, and the surface area exposed to potential bugs. OOP as frequently implemented, while claiming to encapsulate state, ends up creating so much more. In accordance with this view, I think project architecture should be approached with an emphasis around how much state is necessary for it to run. This is why simulations like…

Wow, now we just need to stop interacting with anything stateful, like the real world!

Re: Case against OOP is understated, not overstated (2020)

#279

Post by LudwigNagasena »

thangalin wrote: post #246

The PersonnelRecord isn't OOP and exhibits a widespread misunderstanding: class PersonnelRecord { public: char* employeeName() const; int employeeSocialSecurityNumber() const; char* employeeDepartment() const; protected: char name[100]; int socialSecurityNumber; char department[10]; float salary; } As written, PersonnelRecord class will inevitably lead to code duplication, tightly coupled classes, and other maintaina…

Why not department.transfer(employee) or workplace.transfer(employee, department_from, department_to)? I think that sometimes the most OOP way is just to write

    struct PersonnelRecord {
      char  name[100];
      int   socialSecurityNumber;
      char  department[10];
      float salary;
    }
and be done with it.

Re: Case against OOP is understated, not overstated (2020)

#280

Post by rolisz »

wackro wrote: post #240
zamalek wrote: post #206

My issue with OOP is: Design Patterns: Elements of Reusable Object-Oriented Software. I don't take issue with the authors, with their insights, or anything related to the content of the book. It's that the book exists at all: it's a book filled with solutions to imaginary problems. When using a procedural language the first thing you do is start implementing a solution. When using OOP, you first have to solve the ima…

>solutions to imaginary problems This is a fundamental misunderstanding of what patterns are. The GOF book is used to this though. A design pattern is someting that will naturally crop up if you adhere to certain design principles. If you follow a principle of separating instantiation logic from other logic then you will start to see factories. If you combine multiple complex parts of your code into simpler ones then…

But many programmers use it as a how-to guide. I've had people tell me "but that's how it's done in GOF", even if the design pattern was a poor fit for the problem at hand, just because there was some superficial resemblance to one of the examples in the book.
Post reply on HN