The Case Against OOP Is Wildly Overstated • Hacker News Board

Re: The Case Against OOP Is Wildly Overstated

#141

Post by AnimalMuppet » Fri, Jul 31, 2020, 5:57 PM UTC

dnautics wrote: post #29

api wrote: post #3

Earlier quoted context omitted.

That sounds snarky. Not sure if that was intended or not, but regardless I read your comment as: "OOP is good when you use the object oriented structure as a tool to organize your code and data to solve a problem, but not when you try to wrap your solution or your conception of the problem itself around OOP." It's 2020, and after 50+ years of programming language research I think it's safe to say that there is no "on…

> In other words I'd consider OOP for a "state-rich" problem domain Why is a paradigm like FP necessarily bad for this? Not all FPs are pure like Haskell, and some exist specifically for the purpose of managing state in sane ways (for example which tolerate concurrency without introducing bugs).

Which FP languages do you think would be good for managing state?

I've read here on HN the idea that FP is appropriate when you can think of your program like a pipe (data comes in, data goes out). To me, significant amounts of state would be antithetical to that. Is that view mistaken?

Re: The Case Against OOP Is Wildly Overstated

#142

Post by cogman10 » Fri, Jul 31, 2020, 5:57 PM UTC

zaphar wrote: post #123

I respectfully disagree that frameworks and stdlibs for languages like Java and .Net are better due to use of Inheritance. In fact I struggle to come up with a single occasion where use of Inheritance was not an Antipattern. The exception I suppose is when you have no other way to do polymorphic interfaces.

I've seen a few clean examples where it works really well.

Particularly, Java's AbstractMap is a thing of beauty in the amount of code it saves you if you need to make your own map data structure for whatever reason. One method override and you have all the Map functionality.

Otherwise, I agree that it is an Anti-pattern like 99% of the time. Young devs tend to reach for inheritance almost out of instinct whenever they have code they want to share. It's a hard habit to beat out of college grads (Honestly, some of our senior devs haven't learned that lesson :( )

Re: The Case Against OOP Is Wildly Overstated

#143

Post by goatlover » Fri, Jul 31, 2020, 5:59 PM UTC

jdonaldson wrote: post #101

I believe OOP was successful largely because of Conway's law. OOP itself is a hierarchical (inheritance) type system that mirrors hierarchical social systems in business. It's very "top down" in its orientation, and also allows teams to tightly control the information they are dealing with. Also, I didn't even read TFA. However, I think it's only fair since it's a medium post that requires login.

Also because of UIs.

Re: The Case Against OOP Is Wildly Overstated

#144

Post by AnimalMuppet » Fri, Jul 31, 2020, 6:01 PM UTC

lgessler wrote: post #4

This doesn't speak to what I consider some of the most dangerous parts of OOP, which include the assumptions that tightly binding data and code is helpful, and that statefulness is fine to freely sprinkle throughout your program.

If your program has statefulness (worse, has to have statefulness), then it seems better to control where it is (encapsulate it), rather than letting it run all over the place in the program.

And, if you have code that is for working on a particular kind of data, why is binding it to the data problematic?

Re: The Case Against OOP Is Wildly Overstated

#145

Post by MasonOfSpoons » Fri, Jul 31, 2020, 6:02 PM UTC

jayd16 wrote: post #89

winstonewert wrote: post #82

Earlier quoted context omitted.

I think the key differentiater is that OOP (in some versions) wants to hide the data and not just implementation details. For example, a hash map data structure hides the details of how the hash map is implemented, but it doesn't hide the data. In some versions of OO, the object should not only hide the implementation details but also the data. Any function that needs that data MUST be a method of that object. That's…

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 data records and algebraic data types as core building blocks. These are very different than C-style structs, as they can provide stronger safety guarantees without a massive ream of boilerplate.

A class or method interface promises unfortunately little around essential topics like mutability, concurrency, or termination.

Re: The Case Against OOP Is Wildly Overstated

#146

Post by fdupress » Fri, Jul 31, 2020, 6:03 PM UTC

keithasaurus wrote: post #130

zozbot234 wrote: post #105

Earlier quoted context omitted.

"Tightly binding data and code" allows you to maintain complex invariants via code, and to abstract away from the specifics of any single implementation. Statefulness per se is quite manageable; what's not manageable is shared, mutable state that isn't isolated to a single, modular, highly cohesive "unit" of code that can be understood in its totality. The real issues with OOP have to do precisely with things that br…

> "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?

A good example would be a complex state machine, where you rely on the fact that the state is only modified by the state machine code to make sure it remains well-formed, and the control-flow itself heavily relies on the state being well-formed (think of a TLS session, for example).

But then again, what you want there is modularity, which OOP provides, but is also well-supported in other paradigms.

Re: The Case Against OOP Is Wildly Overstated

#147

Post by dllthomas » Fri, Jul 31, 2020, 6:08 PM UTC

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)

> entity component systems

Nitpick, but I'm not sure this is the correct plural.

As you may very well know (but just in case, and for others), the "system" in ECS doesn't describe ECS as a whole, but another part of the model - you have entities, attributes of those entities, and systems that operate on those attributes.

That said, I'm not sure what I'd suggest instead. "Entity component system systems" is obviously terrible. Just not pluralizing probably works, here? or "towards the entity component system pattern"?

... shrug

Re: The Case Against OOP Is Wildly Overstated

#148

Post by api » Fri, Jul 31, 2020, 6:09 PM UTC

AnimalMuppet wrote: post #141

dnautics wrote: post #29

Earlier quoted context omitted.

> In other words I'd consider OOP for a "state-rich" problem domain Why is a paradigm like FP necessarily bad for this? Not all FPs are pure like Haskell, and some exist specifically for the purpose of managing state in sane ways (for example which tolerate concurrency without introducing bugs).

Which FP languages do you think would be good for managing state? I've read here on HN the idea that FP is appropriate when you can think of your program like a pipe (data comes in, data goes out). To me, significant amounts of state would be antithetical to that. Is that view mistaken?

That's a good way to put it. I've thought of it as "FP is good if you can think of your program as a single possibly recursive data transform, even if it's a very elaborate one."

AFAIK it is theoretically possible to model any program that way, but it's only convenient for some problems.

Re: The Case Against OOP Is Wildly Overstated

#149

Post by AnimalMuppet » Fri, Jul 31, 2020, 6:11 PM UTC

keithasaurus wrote: post #130

zozbot234 wrote: post #105

Earlier quoted context omitted.

"Tightly binding data and code" allows you to maintain complex invariants via code, and to abstract away from the specifics of any single implementation. Statefulness per se is quite manageable; what's not manageable is shared, mutable state that isn't isolated to a single, modular, highly cohesive "unit" of code that can be understood in its totality. The real issues with OOP have to do precisely with things that br…

> "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 invariant is violated. But if it's an object, if the code is bound to the data (in the way OOP normally calls encapsulation), then only the member functions can modify the structure. So if you want to add a component, you have to use the object's addComponent method, which (in a properly debugged object) isn't going to forget to update the total cost.

Now, you could say that the structure could have a code library to go with it, and that could have an addComponent function. That's true. But the user doesn't have to use that function - they can mess with the list directly, if they think they know what they're doing. Whereas with OOP encapsulation, they have to use the existing function. That function can guarantee that the object's invariants are maintained.

Re: The Case Against OOP Is Wildly Overstated

#150

Post by mopierotti » Fri, Jul 31, 2020, 6:12 PM UTC

After working in the Scala, which blurs the line between FP and OOP, daily for years, I feel like the choice to use OOP or not tends to boil down to how you'd prefer to solve the Expression Problem [1] for your domain. (if you follow the paradigm of "Functional Core, Imperative Shell")

If you're following this paradigm, for all your core objects they:

-Will be immutable, meaning calling methods on them will not change their state. (except for potentially some transparent optimizations, eg in-memory caching)

-Should not have methods that have side effects (i.e. purely functional)

If this is the case, then choosing whether your classes are objects or simple data structs is only a matter of code organization. ie do you want objects to carry around their methods with them, or have those functions live separately.

If you want to share method implementations among objects, you have the option of using inherited methods/types for a more OOP solution, or the typeclass pattern for a more FP solution. (Though the typeclass pattern has significant syntactical baggage in Scala)

[1] https://wiki.c2.com/?ExpressionProblem