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

311–320 of 557 posts

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

#311

Post by jay_kyburz »

reificator wrote: post #117
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…

> This is why simulations like say someone making a game or simcity with like relatively independent entities that map to something in real life use OOP. I don't think this is the case, or at least it hasn't been for quite awhile. Any gamedev I've known in the last decade or so would reach for an ECS[0] if they wanted to clone SimCity, in other words they would design it somewhat like a normalized database. Each char…

I doubt any professional gamedev would reach for ECS. No major game engine has a finished ECS system yet. You would have to roll it all yourself and shoehorn it into the engine somehow.

Unity has not shipped DOTS. They actually removed it from the Package Manager last year. Joachim says it has a bright future, but I suspect it will never ship in Unity itself.

Epic has nothing in Unreal yet, though apparently a few months ago somebody spotted some changes in repository that suggests one may be on the way.

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

#312

Post by kgeist »

I've come to like "service-oriented programming" we use at work (I don't know if there's a name for it). Basically, your code is essentially procedural, but instead of free standing functions you use stateless service classes hidden behind interfaces: it gives you very granular namespacing, implementations are swappable, composable, decoratable and testable.

In this system, the models (records) in the domain model are more like classic OOP (objects like "car", "banana") and they have encapsulated state, but only to have a centralized place where you make sure object invariants are upheld whenever their state is mutated (by services), and nothing else.

The hard part is interoperation/invariant validation between multiple objects (aggregates or just related data) and we haven't solved it yet in a consistent manner (everyone comes up with their own approach, for example state propagation via events).

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

#313

Post by valand »

bedobi wrote: post #161

As a professional dev who has made a career out of working in oop languages and codebases, I agree, and it took me far too long to realize that when it comes to oop, the emperor has no clothes. To this day, oop advocates can't even agree on what oop even is or means. Apparently oop as envisioned by Alan Kay was supposed to work like cells in the body that pass messages between each other and take actions independentl…

I agree that both the label OO and FP is overloaded with multiple indiscernable meanings.

I mean Kay's OO, inheritance, class, polymorphism, abstraction, those are mix of paradigm, design pattern, and language feature.

So does FP with its monads, sumtypes, referential transparency

I guess what can make a better discussion is to take apart the label into these individual items and examine them one by one.

Inheritance - bad - get languages to safely discourage its user from using it

Actor and messages - good - get people to understand the concept and how to implement it in each languages

Immutability - good - let's announce how it helps reduce errors

Functional domain modelling - good - let's make everyone know how to do it

Foreign jargon of FP traits - bad - let's make a more walkable learning curve to those jargons

And so on and so on

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

#314

Post by kraf »

agency wrote: post #70
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…

There's a really wonderful talk that I've recommended to almost everyone I've ever worked with called Simple Made Easy[1] by Rich Hickey. I also struggled to explain why I hated state so much. You can talk about races with shared mutable state but even single threaded code I found I couldn't stand it, that it made things harder to reason about and change. It's because state is complex , in the sense Rich discusses in…

Not just you, I had the same experience. I rewatched it several times over the years and understood something new every time.

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

#315

Post by dragonwriter »

jay_kyburz wrote: post #311
reificator wrote: post #117

Earlier quoted context omitted.

> This is why simulations like say someone making a game or simcity with like relatively independent entities that map to something in real life use OOP. I don't think this is the case, or at least it hasn't been for quite awhile. Any gamedev I've known in the last decade or so would reach for an ECS[0] if they wanted to clone SimCity, in other words they would design it somewhat like a normalized database. Each char…

I doubt any professional gamedev would reach for ECS. No major game engine has a finished ECS system yet. You would have to roll it all yourself and shoehorn it into the engine somehow. Unity has not shipped DOTS. They actually removed it from the Package Manager last year. Joachim says it has a bright future, but I suspect it will never ship in Unity itself. Epic has nothing in Unreal yet, though apparently a few mo…

> No major game engine has a finished ECS system yet.

The major engines may not have ECS built in, but some of them are supported by ECS systems that are readily available. Your implicit restriction of professional gamedevs to include only people who both use a major game engine but don't use third party components not supplied by the engine is, I think, overly restrictive.

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

#316

Post by raspasov »

dwohnitmok wrote: post #156
agency wrote: post #70

Earlier quoted context omitted.

There's a really wonderful talk that I've recommended to almost everyone I've ever worked with called Simple Made Easy[1] by Rich Hickey. I also struggled to explain why I hated state so much. You can talk about races with shared mutable state but even single threaded code I found I couldn't stand it, that it made things harder to reason about and change. It's because state is complex , in the sense Rich discusses in…

I enjoyed the talk and agree with it in many ways, but perhaps a contrarian stance will stimulate some interesting discussion. Here's the steelman I can think of against that talk. Hickey's fundamental contention is that whether something is easy is an extrinsic property whereas whether something is simple is an intrinsic property. Whether something is easy is dictated often by whether it is familiar, whereas simplic…

>>> the way humans think is very varied

>>> It all depends on the person.

Based on what I've recently learned about neuroscience and optogenetics, I don't think there's much evidence to support this sort of relativism. On the contrary, many processes in mammalian brains have common mechanisms.

To explore more, this is a great podcast https://peterattiamd.com/karldeisseroth/

Disclaimer: I am a complete layman on the topic, so please correct me if I'm wrong.

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

#317

Post by givehimagun »

kgeist wrote: post #312

I've come to like "service-oriented programming" we use at work (I don't know if there's a name for it). Basically, your code is essentially procedural, but instead of free standing functions you use stateless service classes hidden behind interfaces: it gives you very granular namespacing, implementations are swappable, composable, decoratable and testable. In this system, the models (records) in the domain model ar…

Isn't this Domain Driven Design? I think you understated how easy it is to test in your example. Tests can move from CD to CI because of your architecture. I would love to see more discussions about the tension between scale and test-ability.

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

#319

Post by branko_d »

usrusr wrote: post #96
agency wrote: post #70

Earlier quoted context omitted.

There's a really wonderful talk that I've recommended to almost everyone I've ever worked with called Simple Made Easy[1] by Rich Hickey. I also struggled to explain why I hated state so much. You can talk about races with shared mutable state but even single threaded code I found I couldn't stand it, that it made things harder to reason about and change. It's because state is complex , in the sense Rich discusses in…

That time part is what you are wrestling with when you are battling with state. So it's natural to think about it that way. But there's also this somewhat dumbed down version of the argument: every piece of state a method reads is like an additional function argument and every state it writes an additional return value. What a mess.

This is insightful.

In some sense, the only distinction a "pure" function has over "non-pure" is that it declares all its inputs/outputs (as function parameters and result). We say that a non-pure function has "side effects", but all that actually means is that we don't readily see all its inputs/outputs.

Even a function that depends on time could be converted to a pure function which accepts a time parameter - this is conceptually the same as a function which accepts a file, or an HTTP request or anything else from the "outside world".

The trouble, of course, comes from the tendency of the outside world to change outside of our program's control. What do we do when time changes (which is all the time!) or file, or when the HTTP request comes and goes never to be seen again?

Or when the user clicks on something in the UI? Can we politely ask the outside world for the history of all past clicks and then "replay" the UI from scratch? Of course not. We cache the result of all these clicks (and file reads and network communications and database queries...) and call it "state". When the new click comes, we calculate new state based on the previous state and the characteristics of the click itself (e.g. which button was clicked on). This is a form of caching and keeping a cache consistent is hard, no matter what paradigm we choose to implement on top of it.

The real-world example of this would be React. It helps us implement the `UI = f(state)` paradigm beautifully, but doesn't do all that much for the `state` part of that equation which is where the real complexity lies.

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

#320

Post by thangalin »

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

I dunno man... I think that giving an entity the ability to perform operations upon itself and thereby changing it, looks neat in these examples but scales poorly in a sufficiently commplex codebase. You could express exactly the same thing but get a lot more bullet proof code if you separate out the thing doing the action from the thing you are acting upon. You could have the thing doing the action return the update…

Sure. Depends on the problem domain. One could equally write:

    xferEmployee = employee.transfer( department )
    xferEmployee = company.transfer( employee, department )
    xferEmployee = department.transfer( employee )
    exEmployee = humanResources.fire( employee )
Or, using an event-based architecture:

    new EmployeeTransferEvent( employee, department ).publish()
Post reply on HN