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

291–300 of 557 posts

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

#291

Post by dopidopHN »

shepherdjerred wrote: post #233
djmetzle wrote: post #225

Meh. Is this a hot debate still? No mention of Ruby or smalltalk in this post, which i think of as "true" OO languages, down to the runtime. The ruby object model has its merits! Sandi Metz's POODR is a fantastic intro into OO _and_ a compositional approach to design. FP vs OO is always a false dichotomy for sure. Actors and messaging appear in FP languages. Inheritance surely has nothing to do with OO. Inheritance m…

I completely agree with this. I love writing functional Java. The issue is mutation, not OOP

Would you have any resource on functional Java? My experience with 8 and onward is better for sure. I find myself writing more robust filtering / map-reduce logic. But that’s kind of it.

For instance I don’t feel like function are first class citizen still. ( I almost never user higher order function in Java, even if it’s possible )

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

#292

Post by deltaonefour »

Const-me wrote: post #286
deltaonefour wrote: post #108

Earlier quoted context omitted.

>But FP isn't used so much for real world solutions It's taken over the front end. The react paradigm is FP. SQL read queries are FP.

> The react paradigm is FP. https://reactjs.org/ homepage writes "Build encapsulated components that manage their own state" That's a textbook definition of OOP.

I use the term colloquially. The typical react pattern people use does not put state in the component. It uses a reactive pattern called redux and the state comes from somewhere else.

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

#293

Post by a-dub »

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

Earlier quoted context omitted.

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

interesting. this is really cool!

in the automatic constraint solver variants (which is more interesting to me) are the schedules static (precomputed at compile time) or do they run as a dynamic scheduler of sorts and are the constraints statically checked for deadlock ahead of time?

this architecture is exciting!

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

#294

Post by dopidopHN »

rolisz wrote: post #280
wackro wrote: post #240

Earlier quoted context omitted.

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

I remember trying really hard to find case where I could use a pattern in my code as a junior dev.

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

#295

Post by d--b »

We’re past this turf war. The original “case against oop is overstated” is an attempt to go beyond the gap. It was an article that said “sure oop has problems, but it’s not all bad, maybe we don’t need to throw it all away”.

And then there is this article who just goes through more articles trying to re-ignite the debate. It’s silly.

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

#296

Post by rdtsc »

nomel wrote: post #213
mmphosis wrote: post #159

We have data and complex systems. No one, with the exception of Alan Kay, has convinced me that Object Oriented Programming is or was a good idea. “ … Because the problem with object-oriented languages is they’ve got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle. “ —Joe Armstrong, creator of Erlang programmin…

But, thats exactly the reality of the problem, and exactly what you want. I work with robots, so much of it is physical. There are no floating bananas in the world. They're all held up by something.

The key that Joe was trying to make I think was that the forest and the gorilla have to be explicit:

    State2 = update(State1, ArgX),
    State3 = update(State2, ArgY),
As opposed to, say:

    obj.update(arg_x);
    obj.update(arg_y);
obj holds a gorilla and the jungle, and it may be hard to know how update method works because there is a complicated diamond shaped class hierarchy, and then a thread may concurrently modify parts of it behind our back. You're just trying to add a method or fix a bug, but it's almost impossible because we don't know it affects the gorilla and the whole jungle.

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

#297

Post by mike_ivanov »

galaxyLogic wrote: post #290

Take any Object-Oriented language. Then modify its definition so that any class can have just a single method (as opposed to any number of methods). You now have a new language which you could call a procedural- or functional language based on the set of features that were present in the language you started from. But it is no longer an Object-Oriented language. To make it more concrete start with Java compiler but m…

Put shackles on your feet then try to run. Now, cut off your feet completely and try to run again. See? Shackles were good for you.

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

#298

Post by galaxyLogic »

astrange wrote: post #58
jiggawatts wrote: post #23

I don't quite understand what this is trying to say. It's a summary review of some reviews? Or something. It's not even clear if the author of this post agrees or disagrees with the claim in the YC News title. It's peppered with sentences like: "That you don't understand something doesn't mean it's flawed or bad." Precisely. Many of the arguments against OO are from academics that don't write real-world, large-scale…

> Those same people then cheerfully embrace microservice or K8s, even though they are object-oriented! In case this is not clear, let me define OO for you: > "Object oriented design is all about encapsulated private state with abstract interfaces that have varying implementations that clients don't need to know the specifics of -- even the type names -- ahead of time." "OOP to me means only messaging, local retention…

First-class messaging implies "encapsulation". A message can not directly modify its target. Its target must INTERPRET the message somehow and then decide what to do about it. A message can not modify its target. Only the recipient who receives the message can access its own data, which means its data is "encapsulated".

It is as if you sent me a letter by "first class mail". Great I can read your letter. But your letter can not directly alter the arrangement of furniture in my house. Only I can do that. And perhaps when I read your letter I decide to take such action. Or maybe I decide not to.

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

#299

Post by ummonk »

c-cube wrote: post #266
ummonk wrote: post #211

Earlier quoted context omitted.

> This sort of begs the question: where does classical OOP, the one taught to all undergrad CS majors in programs that use Java or C++, really fit in nowadays? As everyone is telling you, it’s a poor paradigm that makes the developer’s job harder compared to both non-OOP approaches and better approaches (mixins / multiple inheritance). That said, one should be cognizant of the reason it was created in the first place…

C++ supports multiple inheritance though. And it still does it with (multiple) vtables. Did you mean single dispatch?

No, I just had an incorrect memory / mental model of how C++ vtables work.

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

#300

Post by ummonk »

nomel wrote: post #192
ummonk wrote: post #51

Earlier quoted context omitted.

Games are actually moving away from OOP by separating out state into a data oriented system.

I think I need help understanding this. My understanding of data oriented systems is there's a desire to put related data physical close, in memory. It doesn't remove state, it just packs it differently. To be honest, I'm confused by most of the comments here.

One of the benefits of a data oriented ECS setup is that it's much more cache optimal due to the way data is packed, but that's not necessarily the primary reason to use it. In fact, on the data packing implementation side, there are actually differing ways in which the data can be packed, with differing performance pros and cons depending on type of data / access pattern.

Really, the primary benefit is that you get a much cleaner paradigm to work with. Here's a good basic overview of the point of an ECS system: https://iolivia.me/posts/entity-component-system-explained/

In particular I'll point to the key quote in that post that distinguishes ECS from OOP encapsulation: "The whole idea is separating behaviour from logic, so all the data goes in components and all the behaviour goes into systems."

Post reply on HN