Hacker News Reader

Comment by dpc_pw | Hacker News Reader

OOP is a superficial lowest common denominator of programming. Everyone can understand on a superficial level (cat is a animal, dog is an animal, cat does meou, dog does bark, kind of thing), and proceed to write programs. That's why it is popular.

OOP works on low complexity, small projects, but quickly falls apart at certain point, but then it's just head scratching and finger pointing ("this ORM is just bad, next time we will use a different one").

More experienced people figured out some way around OOP to make it more robust, so whenever OOP is criticized they just do the "oh, you just doing it wrong: insert excuse and advise here".

People who really though it through, and tried different approaches are the ones that hate it and are vocal about it. They see through the folly. They can tell how core principles of OOP are bad ideas. How encapsulation at object level is usually pointless and costly, how inheritance doesn't make sense, and so an so.

View on HN

I would really appreciate some examples of oop being "wrong" and the problem solved in a better way. I just don't see why its bad, it makes sense to me. Our lib has classes and submodules with functions. A filetype benefits from a class that contains methods to manipulate said file but other common operation are better put in a function imho.

Just saying "if you are really smart you'll see that oop is bad" just sounds so... Empty.

I personally don't like inheritance as it is implemented in Java/C++. To me it feels like terrible default way to design a language so that methods can be shared between structured data types. It's certainly useful in a lot of cases, but I don't think it is in the majority of cases.

Traits feel more natural to me. Instead of needing to make a subclass of a data structure to attach a foo method to it, you can define a collection of foo methods with the same name and pick the runtime implementation based on data structures passed to the method. I understand that this six of one, half dozen of the other, but I do prefer it this way.

Granted, this is not something OOP does "wrong," and you can use generics to accomplish a similar thing, so it's not that big of a deal.

Inheritance is just traits combined interfaces. Interface is type, trait is the implementation. It just so happens that bringing the type along with the implementation is so common/useful that traits on their own aren't as common as inheritance.

It's not empty, it's downright hypocritical.

I fully accept that not everything benefits from being expressed in objects, which is why hybrid languages like Python are so excellent. But yes, even if some things don't map, keeping OOP around for things that do makes too much sense to ignore.

what's a thing that "does make sense?" The common one is "GUIs". But even React has basically taken UI and turned it functional (obviously not pure functional, but most FPs are not Haskell), by way of using distinctly non-OOP patterns to manage detached local state. There are of course plenty of other, less well known functional UI frameworks in their respective functional languages.

State management systems are what OOP is used.

It used to be GUIs until React, Elm and such proved that FP style describing the end state is a better fit.

"Simulations" can be done in both real time state management OOP style or FP or data centric style with explicit time.

Operating systems are a good example for state management OOP. Linux is written in C with OOP techniques. FP with immutabilty of objects would likely not be a good fit because operating systems are expected to just run in thr background and to not waste resources (eg by copying full objects each microsecond).

Anything where Erlang shines is another good fit for OOP because its actor model actually is the original vision of OOP - objects reacting to messages.

In small doses, OOP is invaluable, especially for defining modules and their interfaces. Alas, OOP advocates, especially in the old days, oversold it. Several major flaws:

* "Everything is an object". This creates unnecessary confusion between data and modules and sometimes even functions.

* "Everything is a message". This encourages splitting state between a myriad of objects, each hiding some tiny bit of mutable state that changes whenever it receives a message. Reasoning about such a state graph is impossible for any non-trivial application.

* "Everything is an interface", which leads to tests tightly coupled to implementation due to mock over-usage.

* "Everything is an inheritance hierarchy". Practice has proven that composition is better than inheritance.

No, no, no.

Everything is a pointer-wide cell of bits, with a type tag.

Now we're cooking with gas!

https://news.ycombinator.com/item?id=24358711

OOP only provides illusions of reuse-ability. In reality every component created in OOP takes extra steps and extra glue code to make compose-able.

In programming you want to build small primitives that you can compose to form larger higher order primitives. This allows you to reuse lower level components to form new programs. OOP does not allow you to do this easily.

Too many small primitives lead to grouping. An object can be a collection of primitives.

And isn't a collection of primitives a grouping in itself?

An object is a grouping of primitives. So according to your logic OOP should have the same problem.

The real issue isn't grouping. The true nature of abstractions is the formation of higher level abstractions from "groupings" of lower level primitives. So "grouping" is fundamental to abstraction and therefore fundamental to programming.

The problem with OOP is that the groupings are forced. I cannot reuse a method outside of the context of the object because the method is tied to mutable state.

For example:

Try to write a function addOneTimesTwo from the composition of the three primitives below (in python):

  def addOne(number): 
     return number + 1

  def timesTwo(number):
     return number * 2

  def compose(f, g):
     return lambda x: f(g(x))

Answer: addOneTimesTwo = compose(timesTwo, addOne)

You will note, compose is a universal functional operator. The definition for compose above is the most primitive way to compose functions in FP.

Try to do the same with OOP:

  class AdditionObject:
       def __init__(self, number):
           self.number = number

       def addOne(self):
           self.number += 1


  class MultiplicationObject:
       def __init__(self, a, b):
           self.a = a
           self.b = b
       
       def mult(self):
           return self.a * self.b

Certainly do-able with OOP. But I cannot extract the methods away from the state. In order to use the banana (method) I need the gorilla holding it and the entire forest it lives in (Object) to come with it.

It can be done, but generally you need a lot more glue code to make it work especially given the fact that people can get more creative with OOP. As you can see the MultiplicationObject is an example of this creativity. It was written with a different interface then the AdditionObject.

Basically if you know haskell even similar issues to the above can be dealt with in terms of haskell. You can certainly define a composition operator for even the most complex types. The issue with OOP is that EVERYTHING is a complex type. A standard Object already has enough complexity to necessitate custom composition operators so you're basically writing custom glue code everywhere. Either you're writing complex glue code or your bending all your code to fit into a framework.

Nothing is truly modular.

   class Math {
    public static function addOne  (int $i){ return $i+1; }
   public static function multiTwo function (int $i){ return $i*2; }
   }

With classes those functions or methods are grouped together under a math class.

Calling it is as simple as: Math::addOne(2)

When you need Math you include it.

Seem cleaner than including little addOne functions as global closures.

Let's say bob wrote One class and Jane wrote another class and these classes are used in many places around the code base.

I'm the programmer that has to compose these classes... You're telling me that I have to change the implementation/interface of what they wrote? What about the dependencies?

This is what I mean by "Not reusable."

Additionally typical OOP involves mutating state. The purpose of the class is to hold methods that operate on internal state. Otherwise what you're writing is basically function calls under a namespace.

>Seem cleaner than including little addOne functions as global closures.

Again Put it under a namespace called Math; problem solved. The purpose of a namespace is to group functions together. The purpose of a class is to group methods together that operate on shared state.

If your methods don't involve a "this"

  function addOne(){
     this.value + 1;
  }

then you're not really doing OOP. You're just repurposing the class as a namespace.

The number + 1 or x 1 doesn't require an object or oop. It doesn't require a function either and would be better to just inline.

The great thing about repurposing a class as a namespace is I can pass that repurposed namespace package anywhere.

You never need to change their code either inject those objects into a new class or extend one and inject the other.

>The great thing about repurposing a class as a namespace is I can pass that repurposed namespace package anywhere.

namespaces can be passed anywhere anyway.

>The number + 1 or x 1 doesn't require an object or oop. It doesn't require a function either and would be better to just inline.

+ 1 and x 1 are just examples. If you take the examples and make it more complex the problem still remains.

An inlined expression is still a function. It's just not named.

  y = function(x){return x+1;

  b1 = 1 + y(2)

  x = 2
  b2 = 1 + (x + 1)

In the above code y(2) and x = 2; x+1; are equivalent.

>You never need to change their code either inject those objects into a new class or extend one and inject the other.

You rarely ever need to do this in FP, but you need to do this all the time in OOP.

> oop being "wrong"

ORMs that overload getters and setters as DB transactions: It creates a harmful illusion that the data inside the object are equally as authoritative as the data in the source of truth (as in database).

My take on ORMs (and OOP) is that they create a harmful illusion that data is just a bunch of "objects" that can be used in some abstract "reusable" way without care for the concrete form it have to be stored (relations, indices, collections/tables) to support efficient computation.

See https://twitter.com/dpc_pw/status/1240719977071575040 for how this works in practice.

If you ask Gavin King or other creators of ORMS their complaints is that they lower the barrier of entry so much that even people who know nothing about databases end up using them. A lot of people seem to have the impression that the ORM is supposed to solve all their problems when an ORM is more of a convenience thing. You have to know the limitations of your database and design your database structure based on those limitations first. Your domain objects (objects representing data in the database) are supposed to match the design of your database, not the other way around.

People like to call this a leaky abstraction but I think it's far more boring. Know your tools (both the ORM and the database). It will be worth it. Don't hesitate to use raw SQL if the ORM doesn't play along.

I disagree, but I would agree quite strongly if it were just the first three paragraphs, with all instances of "OOP" replaced by "imperative programming."

OOP really hasn't been given a fair shake. On the academic side, people figured out pretty early on that OOP doesn't mix well with an imperative programming style. It undercuts the basic idea, same as for FP. But the siren song of multi-paradigm programming is hard to resist. So the tradition of OOP that started with C++ (and ultimately displaced what the academics were working on) was basically an experiment to see if you can improve the flavor of cow pie by mixing it with apple pie. It turns out, no, not so much. You don't really make the cow pie any better, but you do make the apple pie much, much worse. Unfortunately, few people realize it's even possible to do OOP without all the BS (pun intended). Most of us have never known anything but this tradition that basically ignored everything that happened during the 1970s, rolled the universe back to the state of the art as of Simula 67, and took over the world by reassuring managers that nobody was going to try and take away their precious lowest-common-denominator imperative code.

I mentioned elsewhere in the comments that Alan Kay once stated, in so many words, that to him encapsulation was about getting away from an imperative, stateful way of doing things and moving toward a much more declarative style of programming. Being able to do that was a key strength of his formulation of OOP. And it's hard to deny that he was on to something. What his lab was able to accomplish, in so little time and so few lines of code, should be enough to give anyone pause.

But OOP is now strongly associated with bloated and sprawling codebases, not smaller ones. And enabling people to rise out of the imperative programming tarpit and adopt a more declarative style is now commonly cited as a key advantage of FP over OOP. Clearly, something was lost along the way.

> "this ORM is just bad, next time we will use a different one"

...pretty sure there are competing abstraction layers to working with DBs other programming paradigms.

> OOP works on low complexity, small projects, but quickly falls apart at certain point, > More experienced people figured out some way around OOP to make it more robust,

I thought it fell apart?

> "oh, you just doing it wrong: insert excuse and advise here".

Wait til you learn what point-free style is in Haskell! Have fun!

> People who really though it through, and tried different approaches are the ones that hate it and are vocal about it.

So if you happen to like OOP, you just haven't thought it through. Thanks for the constructive comment!

I think you lost the room when you mentioned Haskell. If someone has to reach point where they understand point-free style in order to form this anti-OOP opinion you won't find many takers.

> "oh, you just doing it wrong: insert excuse and advise here".

>> Wait til you learn what point-free style is in Haskell! Have fun!

I honestly don't understand what you're trying to say here. Care to elaborate?

As for ORMs: no, other styles of programming don't have this particular problem nor competing abstracting layers approaching this level of chaos. The ORM addresses a specific mismatch problem between relational databases and objects from OOP. This problem is so messily unique that it has been aptly named "The Vietnam of Computer Science": http://blogs.tedneward.com/post/the-vietnam-of-computer-scie...

OOP encourages writing code in "reusable" way of having bunch of objects referencing each other, which throws out of the window the reality of data having an actual form that has to support efficient computation.

This kind of works (to the point) while the data is entirely in memory, but quickly falls appart when it's a bigger data set in external storage.

I am yet to see a OOP project with ORM that have not fall appart in a way I described in these twitter post:

https://twitter.com/dpc_pw/status/1240719977071575040

I think the argument is kinda cheap. I mean, there are also those people, who just understand the superficial principles of OOP and struggled to understand some OOP design and therefore don't like it. Simply saying that the people who like OOP are the ones who don't see though the folly, works the other way around too and has no real substance as an argument.

> OOP works on low complexity, small projects, but quickly falls apart at certain point

Some very large project, like Windows and all major browser browser engines (as far as I know) are written in C++.

> They can tell how core principles of OOP are bad ideas. How encapsulation at object level is usually pointless and costly, how inheritance doesn't make sense, and so an so.

Can you explain these? I'd like to know why people think encapsulation and inheritance don't make sense.

I don't know if I see eye-to-eye with grandparent but I'll give it a shot!

As others have pointed out, everyone has a different definition of what the core principles of OOP are.

When Alan Key coined the term "object-oriented programming", he had message passing (among other things) in mind. If you like that definition, stop reading this and go use Erlang. If you were more thinking of the various modern languages we now call OOP, read on.

The "lies for small children" version is that OOP is all about modelling the real world in a natural way: apple.eat(), car.drive(), etc. Nouns are objects and verbs are methods. From my POV it's a strawman to reduce OOP to this, but I bring it up because some people like it this way and will argue for it - "It's a natural way to think about software", etc.

How are nouns and verbs actually modelled in practice? You don't file.read() and file.write(), you construct a FileReader and FileWriter, and you tell them to read() and write(). The verbs ofen show up in class names (fileREADer). It's delegation of responsibility and I argue it's a good way to design software. But delegation of responsibility is not restricted to OOP.

Putting aside modelling and design concerns, what are the core features of OOP languages? I like the Uncle Bob definition of Inheritance, polymorphism and encapsulation.

Inheritance:

Inheritance is fraught with more "lies for small children". A Lion is a type of Cat which is a type of Animal. I admit this is another strawman because using inheritance to model taxonomies like this is dumb and doesn't happen in the real world. How is inheritance used in the real world? I honestly don't see it that often. A lot of frameworks like to hijack your 'main' method and force you to use inheritance to run the thing, e.g. MyApp extends SpringApp. I keep trying to think of inheritance examples and think "no, that's just an example of using an interface".

Anyway, one of the principles in the OOP body of knowledge that has emerged over time is to "favour composition over inheritance". You might get to share some behaviour and cut down some code between 2-3 classes, but on the flipside, now when you want to modify just 1 class, you have to realise you're modifying the other 2 classes as well.

Elsewhere in the OOP body of knowledge is the five SOLID principles. I love SOLID. Someone familiar with SOLID might say "but we know how to safely extend classes because of the (L)iskov Substitution Principle!" But it's not an instructive way to safely use inheritance. It basically says "don't fuck up inheritance".

Polymorphism:

Lots of languages have polymorphism. I mainly use Java and I'm disappointed in its polymorphism story. Perhaps other OOP languages do it better? Java has interfaces/abstract-classes as well as "Generics" (first-order parametric polymorphism). First-order parametric polymorphism will let you model List<Integer> as List<I>, but it will not let you model it as L<Integer>. Why does this matter? When you want to abstract over things that are "mappable", like Optional and Stream.

     <U> Optional<U> map(Function<? super T,? extends U> mapper);
     <R> Stream<R> map(Function<? super T,? extends R> mapper);

I can't do this:

     <U> F<U> map(Function<? super T,? extends U> mapper);  // The F stands for "Forbidden" !

I have worked on a large codebase where one of my tasks was to move from Guava Futures to Java 8 CompletableFutures. I really would have liked the ability to hide those concrete classes behind some kind of abstraction. Incidentally later on one of my colleagues said he'd like to rewrite it using Observables. At a different company one of my coworkers went the other way - he did a "hack week" project of converting a codebase from Observables to Futures. It would be better if you could just leave the business logic generic and instantiate it over an Observable or a Future as you saw fit. I don't know OO languages that let you do this.

Encapsulation:

I think the most promininent definition of encapsulation is you hide data inside an object and only manipulate that object using its (public) methods. Why might you want to hide data in such a way? So you can delegate responsibility to the object, because it will handle the data better than you will from outside the object. You don't need objects for that. You can do that with data and functions - unless you insist upon the apple.eat() syntax instead of eat(apple) discussed in paragraphs 2-3.

NB. Putting state inside an object doesn't make it safe for concurrent modifications. But that's a whole 'nother discussion topic. In the "real world" I rarely need to use a mutable data field in an object. Fields are generally just other dependencies, e.g. database handles or other services.

I think I did a reasonable job of hitting "the core principles". It's not so much that they're "bad ideas", but rather, once you strip away the large, good majority of ideas which is available outside OOP (e.g. delegation of responsibility) you're just left with the bad ideas (e.g. inheritance) or ideas which have been executed better elsewhere (polymorphism, message passing.).

On inheritance: https://www.sicpers.info/2018/03/why-inheritance-never-made-...

On encapsulation: I joke that encapsulation on a level of an object is like putting a lockpad on your right pocket to protect your left hand from reaching to it.

Normal people keep doors and locks at the entrance of a door or a room (module level), not on every single object they have. That's why OOP software tends to look so schizophrenic: with walls erected between everything against everything, making stuff like https://github.com/Hello-World-EE/Java-Hello-World-Enterpris... possible.

You might check some of my blogposts at dpc.pw if you care to read more of my thoughts on this.

Disagree entirely.

OOP is 'widespread' because it is frankly a very powerful (and obvious) way to encapsulate and organize information and function by breaking down said problems into digestible units or 'mini modules' if you will, that also happens to lend well to how humans interpret the world.

Polymorphism is a very powerful tool for adaption.

Far from 'problems at scale' - it's the complete opposite: well designed OOP is generally the best abstraction to use at scale, to the point wherein most of the world's most comprehensive APIs are in fact OOP.

Inheritance is definitely overused, and OOP is not ideal for many kinds of projects, but overall, it's successful because it's extremely useful.

It's 'mid level' Engineers, those who have discovered the foibles of OOP Orthodoxy, who 'develop their own ideas for the first time' who are the most ardent critics. Those who get past that see it for what it is, just a tool, very useful in many ways, not so much in others.

TypeScript has fundamentally better OO utility that Javascript, Dart was developed using OOP, Kotlin absolutely kept those ideas, etc. etc..

Obviously, maybe not the best for a lot of systems programming.

It's 100% here to stay, or at least an evolution of it.

I agree with you, but trying to map your problems onto tree-based OOP inheritance is absurd.

Trait-based programming solves polymorphism much more elegantly as any type can adopt a behavior. These systems are going to replace the old paradigm.

Most OO paradigms include pretty strong architectures for traits/interfaces.

They are definitely useful, but 'inheritance' is extremely useful in many cases wherein there is a lot of material overlap in code.

It gets out of hand fast and it's not perfect, but it's just so useful at a small scale, in so many ways.

Every programming paradigm falls apart on high complexity large projects. So OOP isn't necessarily any worse in that regard. As an industry we still haven't figured out a consistent set of best practices for such projects.

This comment reeks of frustration. Let me tell you, there is nothing "superficial" about being able to communicate effectively about code, or about how systems work. There is fundamental value in this notion.

I’m not sure I understand this. I’m working on a 100,000 line swift project and we don’t seem to have those problems.

For example I just added a data caching system where a generic DataCache is used by most data types, with a few more sophisticated caches for special needs implementing the same DataCache protocols, so they can all plug in to the same places wherever needed.

And a series of CacheRefresh objects that inherit base refresh functionality from a superclass, and just impose the their specific REST api calls. And everything is written as functional as possible, with limited state and parameter dependent methods.

It’s working great, any model that needs caching can have a data cache, and any UI that needs to prefetch data can have a CacheRefresh object for each type of data it’s dependent on. I’ve pretty much minimized boilerplate and redundant code this way.

So what am I doing wrong, or what could I be doing better?

> People who really though it through, and tried different approaches are the ones that hate it and are vocal about it. They see through the folly. They can tell how core principles of OOP are bad ideas. How encapsulation at object level is usually pointless and costly, how inheritance doesn't make sense, and so an so.

You seem confident in this position - can you provide some resources for others to become more familiar with that philosophy, proofs against OOP, and/or alternative approaches to architecture?

Yeah, if you've ever worked in a functional language, console'd into and looked at data in flight, and instantly identified what was wrong because data from someone else's library wasn't encapsulated behind private fields, you would never want to encapsulate anything ever again.

Even Eclipse lets you look at private data when debugging. Besides that though, you don't have to make data private- it's just common practice to do so.

> it's just common practice to do so

- key point is that is that it's common practice, and the situation you're in is debugging data emitted by someone else.

Please see https://twitter.com/dpc_pw/status/1240719977071575040 for description how OOP + ORM business code falls apart in practice, then https://dpc.pw/opportunistic-programming for what I encourage. Then more posts there if you're still interested.

The first isn't really a critique of OOP. It's a critique of ORMs that doesn't recognize ORMs are not OOP despite the name - they initialize state that languages refer to as "objects", but those do not offer true abstractions.

The second link is good, but it's just describing OOP done right. If you read the original publications, way back, OOP was never about idiomatically programming in Things - the typical example of "Dog extends Animal" is antithetical. Objects should be closer to microservices. Within those objects... stateless transforms and simple state containers (like structs), or some spaghetti. Didn't matter, the other objects should never interact below the interface.

Windows runs on millions of devices. An absolutely core pillar of Windows is COM and the most recent versions have only added to that foundation with WinRT.

If anything is pure OOP it's COM. And although it has a deserved reputation for being hard to start working with, and documentation these days is sparse; it's going full-steam ahead when you boot a Windows box.

Given that UWP is COM on steroids, there is plenty of documentation, what is hard to find is classical COM with ATL kind of stuff, but for that there are still plenty of books at a library nearby or garage sales.

> OOP is a superficial lowest common denominator of programming.

That statement seems out of touch of the decades of OOP flogging that it took to get OOP support to be a staple of mainstream programming languages, so that it could be a common denominator.

Just a some three decades ago, anyone using OOP terminology was instantly stereotyped as an ivory tower academic.

I don't see how you can manage a project of any significant complexity without objects and the way they allow you to compartmentalize your systems without relying on a bunch of global state.

My approach is: You decompose it into services and actors passing messages (remote vs local), withing each running an imperative shell over FP domain logic. If you care you might read more on https://dpc.pw/opportunistic-programming and https://dpc.pw/how-i-structure-my-apps-in-rust-and-other-lan...

>OOP is a superficial lowest common denominator of programming. Everyone can understand on a superficial level (cat is a animal, dog is an animal, cat does meou, dog does bark, kind of thing), and proceed to write programs. That's why it is popular.

I think its more complex then this. The simplest form of programming is procedural. OOP is a level of abstraction above it in terms of understanding. I think the catharsis of grokking OOP gives it the illusion of being better.

Reply on news.ycombinator.com