Was object-oriented programming a failure? (2015)

I think it's usually the case that mutability and inheritance is overused leading to deep and/or unnatural abstractions and code that is hard to reason about. Working with a hierarchy many levels deep with overrides on every level means it's very hard to reason about the code as the call stacks ride an elevator up and down the class hierarchy.

Don't get me wrong - this is not an inherent drawback with OO, this is because it's applied incorrectly. Making bad abstractions or a class hierarchy 10 levels deep is bad, and it's possible that the same inexperienced developer would just make another mistake in another paradigm, leading to some other problem instead. My issue is perhaps more with the design of popular OO languages (Java, C#, C++) than with OO as a concept.

A very good OO language could be made by simply encouraging best practices and removing the biggest warts (no null, immutability by default, support for sum types, encourage pure functions, discourage deep class hierarchies...).

Experienced programmers can write maintainable code in any paradigm, but I think the paradigms should be judged by how well it helps average programmers write maintainable code.

Oortmessen/Aardappel's point here isn't that OOP is dead. I've seen his code (he runs the OSS Cube engine games and has made multiple hobby languages), he writes in C++ and uses objects where needed.

His point is in slavish love of OOP concepts. Of excessive abstraction and storing state everywhere. I've worked on multiple projects where I can only describe the code as "bureaucratic". Oodles of little classes imperiously demanding you work through them to get anywhere inspite of terrible mismatches and the overcomplication it creates.

Old school JavaScript was already OOP, given that prototype inheritance comes from Self, which was OOP.

You can apply principles like functional decomposition and modular design without necessarily having an object/class system. Instead of storing some state implicitly within objects and having some sort of this/self available when calling a method on an object, you create data-only variables to hold the state and then pass extra data into and out of your functions as needed instead of calling methods “on” some object.

Traditional procedural, structured programming works this way. You see it at a small scale in countless scripts written in languages like Perl or Python, and at a larger scale in big C programs.

Functional programming also works this way, but typically is even more explicit about it.

The key point is that usually you still want to separate the responsibilities of your program in a modular way, with clean interfaces and hidden implementations. You just use other tools to do it, typically by defining your data structures and algorithms directly, instead of bundling them together in a class or your language’s equivalent.

At first glance that might seem restrictive or less powerful, but in fact it’s the opposite, because it removes OO’s inherent bias towards algorithms where one object is special. I commented about this last point once before, if you’re interested: https://news.ycombinator.com/item?id=8690746

If it helps, you might consider that when you call a method on an object in a typical class-based language, what’s really happening under the hood is that (a) you’re passing an implicit pointer/reference to the object as an extra parameter to the function you call, and (b) which function you call may itself be determined by a look-up process based on the type of the object. If your language didn’t support those functions as built-in features, you could just as well pass any required data from the “object” in and back out again explicitly through function parameters and return values, just as you do for any other data you’re processing or generating in that function, and you could use some sort of look-up table to decide which function to call based on some form of tagging each object with its “type”. Indeed, plenty of people were doing this in C, before what we now call C++ came along and made it more convenient by building the pattern into the language.

I don't think that OO is wrong for all problems, but I do take issue with the fact that it almost always inherently means distributed state. If you have multiple objects, then you probably have distributed state.

Sometimes your problem is inherently a distributed state problem, and that's fine. But OO doesn't care if this is sometimes true. OO pushes people toward distributed state architecture, and it unnecessarily encourages excess state splitting even if the problem inherencies don't warrant it.