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

The Case Against OOP Is Wildly Overstated

medium.com

Post reply on HN
Print view View original

191–200 of 312 posts

Re: The Case Against OOP Is Wildly Overstated

#191

Post by tsimionescu »

jeffffff wrote: post #76
Barrin92 wrote: post #56

Earlier quoted context omitted.

depends on the domain. In anything that has say, a very structured 'data flow' in one direction, like in finance or accounting or versioning immutability works well as a concept. In other domains like say, game development it feels forced and out of place. If actual usage of paradigms is an indication rather than belief then it doesn't look like functional programming really is intuitive, it tends to be very useful i…

game development seems to be moving away from OOP and towards entity component systems and data oriented design. i've heard arguments that OOP's killer application is desktop guis, which i could buy, but those become less and less relevant daily. (caveat: my experience is entirely in back end and low level software and anything i say about front end or ui development should be highly suspect)

I think the point was that game development is an inherently stateful domain, which ECS recognizes (if anything, ECS is more stateful than OOP, not less). In contrast, using a pure FP language would probably create a lot of friction with many common styles and even algorithms used in games programming (think about how ugly and out of place actual quicksort looks in Haskell).

Re: The Case Against OOP Is Wildly Overstated

#192

Post by [deleted] »

cglace wrote: post #182
jmnicolas wrote: post #168

Since I accepted I was no Einstein I embraced the KISS principle. My code became simpler, easier to understand. Of course it wouldn't get the approval of any software architect or any design pattern fanatic, but I can take any code I wrote 3 years ago, understand it on the fly and edit it with confidence. There are few bugs and they're never a nightmare to find. Now if I have to modify the code I was writing before m…

Amen. I think the mistake is to reach for the complicated patterns first. Rather than refactoring later when it’s obvious they are needed to simplify your code.

[deleted]

Re: The Case Against OOP Is Wildly Overstated

#193

Post by austinl »

jmnicolas wrote: post #168

Since I accepted I was no Einstein I embraced the KISS principle. My code became simpler, easier to understand. Of course it wouldn't get the approval of any software architect or any design pattern fanatic, but I can take any code I wrote 3 years ago, understand it on the fly and edit it with confidence. There are few bugs and they're never a nightmare to find. Now if I have to modify the code I was writing before m…

I like the theory behind app architecture, but I haven't seen a complex design pattern work well in practice (unless the team is small, and everyone has a solid understanding of how it works).

I worked on a mobile app once that really tried to force one of the fancier design patterns — it required something like six files to handle one screen (because, of course, it's best practice to separate your view, view model, controller, etc.) However, a good part of the org didn't understand the nuances of what code should go where, and found it absurdly tedious to manage all of these files to build one minor screen. Velocity plummeted.

I think a good design pattern allows you to scale as complexity increases. Let folks start simple, then provide a clear path to a consistent design pattern that handles more complexity as it's needed.

Re: The Case Against OOP Is Wildly Overstated

#194

Post by rovolo »

_28jh wrote: post #55

The author flatly says "do not use inheritance." Without inheritance and polymorphism, what is left in OOP? If you look at the author's 4 pillars, the only thing left is encapsulation (and "Oversimplified Hot Takes") It seems like the author himself has proven why OOP is bad. You can have encapsulation without OOP. People were doing it in C 40 years ago. And people are doing it in Go right now. No one would call Go a…

You can have polymorphism without inheritance. A single class can implement multiple interfaces, and multiple classes may implement the same interface.

What is your background? C++ combines interfaces and abstract classes, so this may be the issue you're running into. An interface is an abstract class with no instance variables or method implementations. The trouble with inheritance lies in overriding the superclass's method implementations.

Re: The Case Against OOP Is Wildly Overstated

#195

Post by joshuamorton »

zozbot234 wrote: post #187
joshuamorton wrote: post #165

Earlier quoted context omitted.

Actually my response would be that you just have a plain-ish vanilla list of `Component`, and a function `TotalCost(List[Component]) -> float`, which is implemented as, approximately, lambda arr: sum(x.cost for x in arr). This maintains the invariant without state. There's a potential performance cost here, but that usually doesn't matter a whole lot.

> This maintains the invariant without state. Yes, but this is not possible in general. For instance, what if you want to endow your List with a "MaxTotalCost", set at creation. You can't ensure that your list respects that invariant, other than by encapsulating it behind some custom interface.

That's true, although it raises a question: is the maximum you're willing to spend a trait of your bill of materials (I'd argue no), or of some other thing, for example your overall project. In that case you could have a method that validates your BOM against your project requirements.

Re: The Case Against OOP Is Wildly Overstated

#197

Post by commandlinefan »

antonvs wrote: post #151
Jtsummers wrote: post #134

Earlier quoted context omitted.

> There are very good reasons that procedural programming was abandoned a long time ago and the need for global variables to make it work is one of the big ones. Procedural programming does not, at all, require global variables to make it work. I'm not a big fan of procedural programming at scale because it almost always seems to assume mutability (by default) and shared state when dealing with concurrency, but let's…

That's basically a hand-rolled implementation of a state monad that supports real mutability. The Haskell equivalent is the ST monad. While it's possible to do this kind of thing, it's busywork that properly designed programming languages are perfectly capable of handling well on our behalf.

I had the same thought: he's doing OOP without using the "class" keyword. Well-written C code is actually very object-oriented this way, it just doesn't take advantage of the syntactic sugar of C++.

Re: The Case Against OOP Is Wildly Overstated

#198

Post by jayd16 »

MasonOfSpoons wrote: post #145
jayd16 wrote: post #89

Earlier quoted context omitted.

Hash maps hide lots of internal state though. I think the difference is hash maps have a clear, battle tested API and its obvious what should be promised by the interface and what should be internal implementation. Devs aren't clairvoyant so when we're making a new type we might sometimes get this wrong. But this is a fundamental issue with type systems in general and not OOP, is it not?

It really isn't, as OOP languages don't traditionally provide robust mechanisms around immutability. And why would they? The core design of OOP is to wrap mutable state behind methods which control that mutation. OOP was in many ways a reaction to C; shared mutable structs are harmful, so let's invent privacy. Most of the languages which are suggested to be superior alternatives to OOP in this thread have immutable d…

>The core design of OOP is to wrap mutable state behind methods which control that mutation.

That is the mechanism for immutability that is traditionally provided. It is easy to opt out of that protection.

Java and C# are getting records. They're a convenience but are in no way opposed or counter to OOP.

Re: The Case Against OOP Is Wildly Overstated

#199

Post by camgunz »

AnimalMuppet wrote: post #149
keithasaurus wrote: post #130

Earlier quoted context omitted.

> "Tightly binding data and code" allows you to maintain complex invariants via code Not sure I understand what this means. Could you give an example?

I'm not the one you're asking. But... Here's a data structure that represents a bill of materials. It has a list of components, and a total cost, which is the sum of the costs of the components on the list. That's the invariant - that the total cost is the sum of the costs of the components in the list. If it's just a structure, then someone can add or remove a component, and forget to update the total cost, and the…

I think people in general are pretty OK with the data hiding part of encapsulation. Scattering application state across objects as part of encapsulation, and polymorphism and inheritance are the source of a lot of debate though. Bob Nystrom wrote the best description of the polymorphism vs. pattern matching tension I've ever read [1], and I think problems w/ inheritance are all pretty well known (method resolution, programmers becoming taxonomists, etc.)

[1]: https://craftinginterpreters.com/representing-code.html#the-...

Re: The Case Against OOP Is Wildly Overstated

#200

Post by nfw2 »

jmnicolas wrote: post #168

Since I accepted I was no Einstein I embraced the KISS principle. My code became simpler, easier to understand. Of course it wouldn't get the approval of any software architect or any design pattern fanatic, but I can take any code I wrote 3 years ago, understand it on the fly and edit it with confidence. There are few bugs and they're never a nightmare to find. Now if I have to modify the code I was writing before m…

Einstein himself would approve this philosophy. As he once said, "Everything should be made as simple as possible, but no simpler."

Still, finding the simplest-possible solution to complex problems is often challenging in itself, especially considering what is "simple" or "intuitive" can be highly subjective. Engineers are often uncomfortable thinking about these problems because the domain is shifted somewhat away from the realm of logic machines and towards psychology and UX, in which they have little to no education or experience.

Post reply on HN