Case against OOP is understated, not overstated (2020) • Hacker News Board

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

#181

Post by djur » Fri, Feb 11, 2022, 1:17 AM UTC

bcrosby95 wrote: post #109

dboreham wrote: post #95

Conjecture: programming is hard, especially as the scope of the system becomes larger and the problem domain more complex. This means that all programming tools and techniques have at least some problems and downsides. It also means that any solution involves trading off various factors, e.g. code is fast or easy to read but perhaps not both. All this means that you can pretty much point to anything in our field and…

> Conjecture: programming is hard, especially as the scope of the system becomes larger and the problem domain more complex. This means that all programming tools and techniques have at least some problems and downsides. Yes. > You can do this with FP too. But FP isn't used so much... So close.... The problem is single paradigm tools. No single paradigm fits all of a problem. And in my experience, OOP is particularly…

What are these very popular single paradigm OOP languages? The closest thing I can think of is Java.

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

#182

Post by throwawaylinux » Fri, Feb 11, 2022, 1:18 AM UTC

ctxc wrote: post #130

zozbot234 wrote: post #20

This is basically a survey of a bunch of posts, and doesn't do much to provide a consistent critique. Regardless, the true weak point of OOP is arguably implementation inheritance, which just doesn't leave you with a consistent semantics that's open to extension and changes in the basic/derived classes (that is, the well-known "fragile base class" problem is still a showstopper). But that has always been a pretty ad-…

I still don't understand why it's bad! Feels like spaghetti sentences tied together as a single article. Why is OOP so bad, anybody? With scenarios, code samples or alternate implementations?

I'm not sure that it is so bad.

But I still don't understand why it's good! Why is it so good? It is said to be better than (non-OOP) alternatives. Where's the evidence for that?

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

#183

Post by zelphirkalt » Fri, Feb 11, 2022, 1:20 AM UTC

astrange wrote: post #43

zozbot234 wrote: post #27

Earlier quoted context omitted.

"Hiding" state is necessary to endow it with well-defined invariants. This can be done in many FP languages, too. The semantics-side implications of "encapsulated" state w/ proper invariants have yet to be explored, though, and this is where newer PL formalisms like "homotopy types" might end up being quite helpful.

> The semantics-side implications of "encapsulated" state w/ proper invariants have yet to be explored, though It seems that that's called a state machine, and OOP objects should come with state charts, but they don't. > and this is where newer PL formalisms like "homotopy types" might end up being quite helpful. PL research would actually get adopted if they didn't insist on using the worst possible names for everyt…

> It seems that that's called a state machine, and OOP objects should come with state charts, but they don't.

That is because the state chart would so quickly explode into uncountable states or so difficult to understand transitions from state to state, that such a diagram would become instantly useless. Which only goes to show, how unrealistic the idea is, that you can really fully understand such a system and that shows what the problem is. Granted, there may be certain areas of related state, that are separated from other areas, but when the program becomes non-trivial, the lines usually blur, unless some kind of approach is used, which reminds me very much of FP, only that it wraps functions uselessly in classes and objects, instead of making use of modules and functions only.

In an FP style, ideally each function would be a thing you can look at separated from the whole system, if you know what its input can be (which may be difficult). That makes for testable code. I should be able to test every function separately, without having to use ten other classes to make instances to set up an environment, in which I just hope that what I wanted to test, can actually be tested.

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

#184

Post by z5h » Fri, Feb 11, 2022, 1:22 AM UTC

deltaonefour wrote: post #108

dboreham wrote: post #95

Conjecture: programming is hard, especially as the scope of the system becomes larger and the problem domain more complex. This means that all programming tools and techniques have at least some problems and downsides. It also means that any solution involves trading off various factors, e.g. code is fast or easy to read but perhaps not both. All this means that you can pretty much point to anything in our field and…

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

And, in fact, much of the front end ecosystem is constantly getting ideas from Elm which is pure FP… and a pleasure to use (I think).

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

#185

Post by keithasaurus » Fri, Feb 11, 2022, 1:25 AM UTC

cryptica wrote: post #174

Those who hate OOP have never used OOP correctly. None of these articles mention 'cohesion' or 'coupling'... It's not possible to critique OOP unless you understand the principle of loose coupling (ease of substitution) and high cohesion (clear separation of concerns/responsibilities). Without loose coupling and high cohesion, your classes will not be composable which is the whole point of OOP... These characteristic…

Ah yes, the classic "No True Scotsman" OOP defense.

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

#186

Post by z5h » Fri, Feb 11, 2022, 1:27 AM UTC

ferdowsi wrote: post #74

ummonk wrote: post #42

The problem with OOP is not just with poor implementations and inheritance models (e.g. Java) but that state encapsulation is actually bad and cements complexity. The real goal should be to untangle state and decouple it from computations by putting it all in global shared state (e.g. SQL, Redux, ECS frameworks, etc.) while using stateless functional computations to compute changes to the global state. Pure functions…

The opposite end of OOP is the functional purist world where "color = blue when hovering over button" becomes 10 levels of boilerplate indirection in order to update global state and receive changes using actions/reducers/containers/memoizers. It's just substituting one type of needless, brittle complexity for another.

Functional purist here (mostly Elm), and I have very few problems that arise from the paradigm. Also fewer bugs than pretty much any software I use or deal with.

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

#187

Post by almostdeadguy » Fri, Feb 11, 2022, 1:27 AM UTC

sirwhinesalot wrote: post #39

I have not read the article but I've seen other blog posts on the subject. The issue with "OOP is bad" is that OOP means different things to different people. Abstract Data Types are sort of a subset of OOP and are massively useful, I certainly don't think it's a good idea to expose the internal implementation of a data structure most of the time. Any sort of plugin system works in an OO matter. It is a useful tool,…

The problem with the "inheritance isn't part of OO" take is that every single one of the languages we call object-oriented that gained mass adoption have inheritance, including Alan Kay's own smalltalk. There have been entire books written about object-oriented design describing ways to use (or not use) inheritance in program design. So whether or not it was intended to be important by the author of the term is immaterial, it for all intents and purposes is a crucial part of object oriented languages.

Inheritance is not the only problem w/ OO either, many things are straight up awkward to express when you must couple data and code together. Many 2+-argument function w/ disparate parameter types create confusion about which class "owns" the definition of the function.

You also don't need to marry data and code to get the benefits of encapsulation. Many functional languages in the ML family have developed clever solutions to encapsulate the definition of a datatype while exposing it to module-local functions. There's no need for the datatype to carry a method around with it to support this.

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

#188

Post by jshen » Fri, Feb 11, 2022, 1:27 AM UTC

taurath wrote: post #91

Supermancho wrote: post #29

Earlier quoted context omitted.

> ends up creating so much more. This is primarily because of inheritance, which seems counter-intuitive. In a meta-analysis of OOP-based designs, inheritance is used as the primary form of composition with other strategies being either last-resort or added later when the inheritance is already deeply embedded as part of the design. Inheritance is a brittle form of a composition (no-reinherit) that nests state in a d…

> This is primarily because of inheritance, which seems counter-intuitive I agree that inheritance creates a lot more problems, but the usages of non-static methods and internal state even in classes with no usage of inheritance can feel just as bad, when you have a high level method utilizing instantiated objects. Internal state as a whole can be avoided fairly often

I don’t see much difference between

    some_state.do_stuff()
    do_stuff(some_state)

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

#189

Post by dools » Fri, Feb 11, 2022, 1:28 AM UTC

sirwhinesalot wrote: post #39

I have not read the article but I've seen other blog posts on the subject. The issue with "OOP is bad" is that OOP means different things to different people. Abstract Data Types are sort of a subset of OOP and are massively useful, I certainly don't think it's a good idea to expose the internal implementation of a data structure most of the time. Any sort of plugin system works in an OO matter. It is a useful tool,…

"The saddest thing about the "object–relational impedance mismatch" is that the focus went totally to the wrong side. The relational model is a much nicer way to model relations than a graph of objects (that's the whole point after all)."

I found the same thing. When I was using ORMs I always found them clunky for all but the simplest tasks, where I would long for an easy way to use SQL and have it "just work" for objects, so I created this:

https://github.com/iaindooley/PluSQL

It's obviously not been maintained but I think it's a model that has legs: that is, simply the creation of SQL with some convenience methods, allow the use of completely arbitrary SQL, and then intuit the object mapping automatically without loading the entire result set into memory.

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

#190

Post by sirwhinesalot » Fri, Feb 11, 2022, 1:29 AM UTC

seanmcdirmid wrote: post #162

sirwhinesalot wrote: post #154

Earlier quoted context omitted.

Oh you sweet summer child :). Have an upvote just because I'm happy someone managed to avoid it. Did you know Facebook's iOS app has around 18000 classes? Yeah. Edit: It's actually the iOS app, not the Android app, crazy either way. But yeah in university I was taught the whole "a cat is a feline which is a mammal which is an animal" shtick. Completely useless in the real world.

There is nothing wrong with ontological reasoning. A cat is a feline, how you express that relationship, or if it is even worth expressing, is another matter. We also learned “Cat(x) :- Feline(x)”, but never used that either (and no one ever derides the use of predicate logic in programming). I think we spent most of our smalltalk time covering metaobjects (I did my CS program before Java took over).

The problem with the OO style taxonomy is that doesn't just model the taxonomy but it also structures your code, that's usually where the problem is, and it leads to issues like what is the proper superclass: Square or Rectangle.

A square is a kind of rectangle but the "API" of a Square is more restrictive than that of a Rectangle (where both width and height can change independently). I've seen this issue discussed in either this year's or last year's CPP-CON...