These “OOP is bad, here’s why” type of articles often can be simplified to the pattern of “here’s a terrible example of OOP, and here’s a very good functional solution of the same problem”.

On small scale, OOP just makes things way more complicated than it should be. On larger scale however, it works quite well, especially if you know where to break the rules.

Something doesn’t need inheritance? Don’t use it! I even use structs in D, which often speed up things by a lot, especially since they’re not ref by default.

One big issue I’ve seen to come up again and again is the programmer not knowing how to handle functions, that need to be called many times. By conventional OOP wisdom it’s done something like this:

class Foo {
    void doTheThing(Param p) {
        //doing the thing
    }
}
[...]
for (int i ; i < timesToDo ; i++) {
    foo.doTheThing(param);
}

However, we can move the iteration into the function of the class, so we will still have the power of class interchangeability:

class Foo {
    void doTheThing(int timesToDo, Param p) {
        for (int i ; i < timesToDo ; i++) {
            //doing the thing
        }
    }
}
[...]
foo.doTheThing(timesToDo, param);

Inheritance can replace complex condition statements. The class Foo in my example could be a basis for a thing, that has its own internal state, which is pretty common in game development. However most people are not being taught game development, but instead things that assumed to make money, which include the hottest new trend. When I was beginning to learn programing in college, I was told that we can say goodbye to .exe files, to say goodbye to installing programs to your PC, because everything is going to be web based, thanks to… Flash??? And Java applets??? Funny, it turned out to be JavaScript to be the winner, and now we have applications on our computers that are just glorified Chromium browsers running what are essentially interactive web pages, which got so widespread there are now coders not only afraid of all pointers, but also type declarations.

In my honest opinion:

1. OOP is okay. It’s not the catch-all solution as it was advertised back in the days, but neither if FP, aspect-oriented programming (was this even adapted?), etc. When structured programming came out and obliterated those awful goto statements, it was revolutionary. However, we might never replicate its impact yet again in our lifetime. Maybe it’ll never be replicated ever again. People are already failing to find the next iPhone, which are just nicer looking PDAs.
2. I’ve seen some some FP jank too. So far my favorite was a person, who managed to solve the use of atoms, by creating a struct they passed to each function, essentially creating a code that is as FP as it gets.
3. A lot of attempt at avoiding OOP often end up with an attempt of reinventing it without using the class statement.
4. Monoparadigmism, as I call it, is harmful. It makes its user to fall into the “when your only tool is a hammer” fallacy, and acting accordingly. It would be nice if we could have a single hammer that fixes everything, but that’s not the case. That’s why I love D’s multi-paradigm solution. You need classes? There’s a very friendly class system. You would like the same without being a reference value and the inheritance? You can just use structs. You need to ensure your data isn’t changing? Just add const everywhere. And so on, and so on, and so on.