Why is OOP still so widely spread?

I love HN don’t get me wrong, but my coworkers and I like to poke fun at it. Some jokes are “why didn’t you just use rust?” and “Well what did Paul Graham have to say about it?” when debating something. It’s a culture like any other. I would say a lot of super smart people are here, who have deep knowledge on the most esoteric niche subjects, and provide a lot of sage wisdom and advice. But there are a lot of cranks too (including myself!).

Yes, thankyou! I think about this every time I see "Systems are so powerful we can just throw RAM/CPU cycles at every problem, efficiency doesn't matter..." as if everyone on the planet is doing web apps, and there are no engineering/architectural situations that might drive certain languages or design principles. Such as this:

https://www.intel.com/content/dam/www/programmable/us/en/pdf...

I guess I'm just focused on a niche market...

Think about languages as tools: focus on the tools you need to use. Your career will be long and there will be plenty of time to branch out, but you have very limited time for mastery, so you should master the tools you use often.

All too often, I find this devolves into me scouring the internet for "C++ is ok but the ownership model is so primitive that I would never start a new project in it" and comparing it to "My problem with Rust is that it's still such a nascent language I can't trust it to have the libraries I need". Who are these people, and why are they saying these things? Are their gripes relevant to me? I have no way to know!

Honestly, just pick one and run with it. Part of becoming an experienced programmer is developing your own heuristics for how to pick the right tool for the right job and how to read this type of discussion, and a big part of that is building up both wins and losses to train your intuition.

When they say "OOP is now considered an anti-pattern, most companies are moving towards reactive FP", do they really mean "I work at snapchat and the ads group I work for is moving away from OOP. My friend at amazon said he's doing the same thing"?

If it's an internet forum and you don't see references or citations, it's probably safe to assume it's the latter. They might still be right, but not verifiably so.

Try not to get bogged down by what others say. If you’re looking for a job in a particular industry, follow the fads of that industry. Otherwise, just keep building your knowledge and worry less about whether it’s the right specific technology.

There's another dimension of the issue: types of the project the person has experience with.

Something that works in a low-level Windows desktop doesn't necessarily work in high-level Linux web. Something that works for NASA or SpaceX doesn't necessarily work for a mobile game startup. Something that works for FAANG is not necessarily the best way for a web site that's running on a single server. Something awesome for a social network is not guaranteed to do any good for a bank, or a research lab.

That "something" can be pretty much anything: languages, libraries, IDEs, frameworks, project management practices, hiring practices. The only thing these projects have in common is "people need to write code that does something". Almost everything else is different. And yet we have many discussions where people working in different industries, on projects with different requirements, budget, users, revenue sources are arguing which language is better.

I'm sorry if this is what you understood. The hate is from people hearing the complaints of experts. The experts generally have great understanding of the pros and cons, and are aware of the weaknesses, which they will openly talk about and sometimes that will make it sound worse, almost hyperbolic to others. Even I'm faulty of doing this, I might say this just sucks, or it's total rubbish, but really I mean it's pretty good and there's a lot of good ideas and parts, just needs some refinement and a few modifications because there are still problems with it, and I just faced one such wart so I'm frustrated and writing a big blog post to complain about it.

And this is the source of the misunderstanding. Overreaction and hyperboles from experts, taken at face value to those who are learning about it.

To your other points, I think it's interesting you bring up React since its biggest competitors: Vue, Svelte and Angular are all OO based and seem to be doing well.

> Can you name a contemporary expert or a platform that started or spent a good chunk of time as FP and ran back towards OOP

Hum, I think most did. OCaml added an object system to ML. CommonLisp added an object system to lisp. Haskell added TypeClasses. Scala is an attempt at an Haskell like language with a full object system. F# and Kotlin both have object systems as well. One could argue actors are a purer form of OO. And so on.

See, my point is that experts only ever complained about certain aspects of current iteration of so called OO programming languages. And as you can see, alternate languages they'd reach for or newer languages after them (or even newer version of those languages) all tried to address those shortcomings, but did not throw the baby out with the bathwater. There is convergence of ideas, and most of those languages have many if not most of the OO staple feature set, while having taken a few out or added some other inspired often by FP, but sometimes by other paradigms too.

I’m not sure. For example, frameworks are often nicer in OO than FP. Of course some wag will suggest you shouldn’t use frameworks, only libraries, but that misses the point.

Plugins strike me as another use case that works better in OO than FP. I’m certainly not saying you can’t have a plugin architecture in FP though, it just won’t be as nice to use, that’s all.

I expect in a few years the OO revival will be strong. “Look, we can neatly model fundamental concepts such as timers again!”

>> Can you name

Does es5 to es6 count? es5 was in theory already OO but the predominant usage appeared to be more heavily influenced by FP. I could be wrong on that but books like javascript the good parts were popular.

React is probably not a good example, because it didn't really expose its users to the horrors of OOP. There wasn't much inheritance and subclassing going on in the userland; you didn't really see SecondaryButton component inherit from the Button component and override its "render" or "onClick" method. True, there were some such codebases, but it was extremely rare. So no, I don't think React users have ever experienced the full extent of OOP, where you have to hunt through your codebase up the hierarchy chain for the bit of code that is misbehaving.

I can't think of a time where we killed a project or rewrote a project to make it more functional. Or where OOP bite us.

React went functional for a reason. Does everyone share that reason?

The reality is that the difference between general purpose languages aren't that great. Even when highly conservative languages like Java adopt functional programming elements, they don't really add capabilities, they only change convenience. Lambdas are nicer than anonymous classes but they are still equivalent in functionality. The situations in which you absolutely need a purely OOP or FP focused language are pretty rare. People need a language that does a little bit of everything but doesn't go too deep into either end. The problem with feature rich languages is that they are ripe for abuse. When someone discovers a feature for the first time they are going to test it out. People produce a lot of crap in their learning phase that should be thrown out but it ends up in production code bases.

When in truth they’ve simply formed an echo chamber for their own loudly-stated views.

There are other programming paradigms and there are of course multi-paradigm languages. As a for instance I do most of my work in Prolog these days (because PhD) which is a logic programing language, so neither OOP nor FP but, er, well, LP. There's many logic programming languages that mix multiple paradigms like Logtalk (LP and OOP), Visual Prolog (LP and OOP) Mercury (LP, OOP and FP), OZ (LP, OOP, FP, constraint, concurrent) etc etc.

I mean, I understand that OOP and FP may be the only relevant paradigms in a particular context- but, in that case, what is the context that is assumed in this thread? Web development? App development? Games development? AI? Data science? Embedded systems? Compiler writing?

EDIT: I guess this "OOP or FP" thing reminds me of myself at my first undergrad CS year. I knew a bit of JS/HTML/CSS, a bit of Java and C#, a bit of SQL and had heard of C and C++ so I was trying to place them into categories, like "C#, Java and C++ are OOP, C is procedural, that's it, there's no other paradigms". Then, in the second year I met Prolog and it kind of blew my mind. It's good to have one's mind blown like that, though it stings at first when one realises how little one knows and how many assumptions one built on such little knowledge. One feels a little dumb. But one quickly gets over it because there is suddendly a world of interesting new things to learn.

Thank you for demonstrating my point :p

This is exactly what I'm referring too. The use of hyperboles or blanket statement by experts, which are taken at face value by those learning from them. Whereas your real sensibilities are well reasoned, nuanced, and your disliking of OO is in the details. Not everyone can get that from your reaction. So it creates this fashion trend, it's trendy to hate on OO. That's not constructive, because experts also know there's a lot to learn from OO, and not everything about it is bad.

I'm developing a structurally typed language now. Is there some research you could recommend me?

Totally agree, but what I'm arguing is that a lot of the pain points people associate with OOP are actually more about the pain points of a nominally-typed system, and when you use OOP with a structurally-type language a lot of those pain points go away.

Even when you elevate a particular construct to be first-class in a language; the expressiveness of languages differs greatly.

For example, prior to lambdas, first-order functions existed in Java in the form of static methods - but higher-order functions weren't really possible. Even now, we lack the ability in Java to express certain forms of functions which are possible in more expressive functional languages.

Lisp's in general have the same control constructs as many imperative languages, but it's possible to do higher-order abstractions over them through the use of macros and constructs like shift/reset or call/cc and the fact that everything is a s-expression.

In this regard, Java and C-like struct pointers are almost first-order OOP languages - the composition via inheritance is quite frankly poor compared to the other paradigms.

It's even more strange now, that we have distinctly non-OO languages that explicitly use the first-parameter-is-struct pattern, e.g:

struct definition: https://github.com/elixir-lang/elixir/blob/v1.10.4/lib/elixi... and functions: https://hexdocs.pm/elixir/Date.html#functions

In OOP you can have multiple functions that are called "save" and they are primarily distinguished by their type. If you define a static function in Java you call it by invoking its namespace:

    MyThing.somefunction(myThing, args)

Compare this to Haskell records. Field names are not defined inside a type dependent namespace and therefore you cannot reuse field names in a second record. If I remember type classes correctly they allow you to define implementations sharing the same function name, but they don't allow you to have multiple type classes define a function with the same name so they do not offer type dependent namespaces either.

OOP tends to make organization easier because of this namespacing feature. It probably has led to "over-organized" codebases though. Too much of a good thing can also backfire.

That is the thing, at their basic level, objects are just some form of extensible modules.

The benefit of `data.sort()` is you could write that in a function that accepts a `data` that could be an array, a vector, a linked list, etc... anything that implements the "sortable" interface. Writing `Array.sort(data)` in your function means the function won't be usable for any kind of data other than arrays.

The other features of OOP like encapsulation, inheritance and abstraction -- these aren't so special. But OO polymorphism is pretty unique.

I think the first one feels a lot more natural. It also seem to lower the cognitive load of knowing where to find the sort method / function. Is that just because I have used mainly OOP style languages?

A fairer analogy would be to say that OOP is a particular architectural style, and FP is another.

You can mix Japanese woodworking with European woodworking by using screws, nails and glue whenever you feel like it. Its simpler than pure Japanese woodworking, not as pretty, quicker to construct, doesn't last as well. You can even forego Japanese woodworking entirely, but to do so is to throw away an entire culture's worth of knowledge about how to cut, shape and join wood, so likely not a great idea.

Analogy: You talk to some master chefs. You tell them that the sharp knives are dangerous; they should get rid of them. They're going to tell you to get lost. The knives are valuable to them precisely because they are sharp. Sure, an amateur like me could seriously cut himself on one. So?

OK, "I wouldn't work on such a project" is a fine answer. But not a universal one.

1) performance bottlenecks are generally no longer CPU computation (network tends to dominate for many many things), and there is nonzero overhead to most functional operations.

2) coordination-free concurrency can in many cases often overcome computational bottlenecks, and non-OOP is far more effective for the code author in dealing with/grokking concurrency.

3) in the intervening time, functional patterns for some things (like UI) have been discovered which make fp a good fit for things that in the past were understandably the domain of OOP.

But OOP languages do have lambdas and function pointers, so can easily do something very close to that. In Kotlin:

    fun addOne(value: Int) = value + 1
    fun addTwo(value: Int) = value + 2
    val addThree = fun (value: Int) { addOne(addTwo(value)) }

Even in Java you can do function composition, though it's not well known and a bit verbose:

    import static java.lang.invoke.MethodHandles.*;
    import static java.lang.invoke.MethodType.*;

    static int addOne(int i) { return i + 1; }
    static int addTwo(int i) { return i + 2; }

    void combine() throws Throwable {
        var lookup = lookup();
        var type = methodType(int.class, int.class);
        var first = lookup.findStatic(Main.class, "addOne", type);
        var second = lookup.findStatic(Main.class, "addTwo", type);
        var combination = filterReturnValue(first, second);
        System.out.println(combination.invoke(1));   // Prints 4
    }

    Camera camera = createCamera({"rotation": 90});

    Bitmap bitmap = createBitmap({data: data, samepleSize: 4});
    ImageView imageView = createImageView(bitmap);

These sorts of objects provide a nice API, but they don't contribute to good internal designs. I have seen many systems were there is an attempt to map objects to physical things (like on a modem, you might have a "demux" object). Invariably, software ends up having to bend to the design of the hardware, and you end up with very leaky abstractions. Why have a "demux" object, when all you are trying to do is write some registers depending on user configuration? Why not design your software around what it is actually doing, rather than what the system's overall purpose is?

Interfaces are a different question. High level interfaces that reflect what the system actually does are very useful. I think this is born out in some modern OOP-ish languages like Go or Rust where interfaces are everywhere, but full scale OOP is mostly absent.

    camera_set_rotation(camera, 90);

There is also a big difference if you're working mainly on the backend where you shouldn't keep any state or the frontend to how useful many OOP concepts are to you.

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

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.

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.

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.

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

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

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.

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);

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

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

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

Then among the people who do know about it, an even smaller fraction learnt about it first, or in the same depth. Among those who did, very few learnt it in a practical way (Learning ML in college is unlikely to get someone to use FP to build production software, especially before ReasonML was a thing).

With all that, is it a stretch to think people don't use FP because they don't know about it? No, I don't think so. It could be 100% objectively superior in every way and people still wouldn't use it in those circumstances. And its' far from being "obviously" better.

To me this is the primary benefit (although the file mapping is convenient).

As to python... it is impossibly more flexible than C. I have done silly stuff like reading all the files in a directory, then i imported all the python files I found.

I think C is not very deep, but it is very well known.

Like you say pythons import is a different beast and it can run code at runtime when it comes across that statement. Some training is not clear on that. Like you point out import does not just import the file it runs the thing. If the file only contains def's then it effectively just defines a bunch of functions/objects and does nothing else But it can. C is not like that. It is more copy the whole file here and apply the current state of pre-processor rules.

* ability to reference other files in a manner other than copy/pasting

- allowing the compiler to understand when it should cache what it already knows, instead of having to set up and deal with precompiled headers for large projects

- ability to treat a header file as a single unit and not leak preprocessor defines

* treating many files as a single compilation unit, leaving LTO to only be needed when linking to a library

I do wish Java had made `final` the default for fields and variables. Lombok's `@Value @With` takes away a lot of the pain though.

Looking it up, I think I was wrong about that. Early OOP did in fact have implementation inheritance.

I guess what I should have said is, OOP originally had three legs. One of them turns out to be bad but the other two seem fundamental to large-scale systems programming.

> I'd also like to know why you think REST is disturbingly anti-OOP.

So, this is pretty abstract, but REST philosophy seems to put a lot of emphasis on representations of data while discouraging communication of operations on the data. The way to operate on the data is to GET the representation, modify it, and then PUT it back -- not to POST a message saying "please perform operation F". I've heard several hardcore REST advocates specifically argue against communicating operations, deriding it as "RPC" (which I guess they see as derogatory?).

In practice I think most people only follow this philosophy when it makes a reasonable amount of sense and ignore it when it doesn't.

I tried to make it clear that I do find high level taxonomies nice. Just the further you zoom in, the less useful a strict adherence to that will be.

I mean sure, this is mostly true of Go more than most other languages though. I didn't mean to pick on Java alone, C# which is a language I love has this similar problem, though they seem to be heading slowly towards a multi-paradigm language, though the emphasis on OOP is still there, it doesn't feel as restrictive as Java.

Heck, even Kotlin seems to be getting rid of a lot of what I call the ceremony of Java whilst still producing equivalent bytecode (I can only imagine most of it is just syntatic sugar).

https://tour.dlang.org/tour/en/gems/functional-programming

If the only reason is because the language doesn't permit otherwise (like Java) then it's essentially nothing but extra boilerplate. When you write a lot of code, this all adds up. Inevitably, over time, folk will grumble. There are simpler ways to express such things in other languages.

Sometimes less is more.

There is no reason you can't do this in C# or Java.