Was object-oriented programming a failure? (2015)

Why are there still those who think any advocate of OOP is an advocate of "OOP or Nothing! All things are Objects! All things are an instantiation of a class! All things must derive from a root class! etc."?

OOP is a tool. And generally a useful one. Every new programming paradigm at its inception was going to Save The World and make programming A Better Place. Turns out, every one if these paradigms is a tool with uses at various times.

So OOP might only be useful in a limited number of cases. I find it comfortable for categorizing functions: "Here's all the stuff you can do with a String" or "All windows behave like this..." And if your language is dynamic enough, you can add functionality to all Strings, not just your String subclass.

I don't typically find OOP useful for processing many records of data. Perhaps I might compose an object from a record of data so that a user might edit their profile in a GUI, but batch processing doesn't usually lend itself to OOP. But that's my experience and opinion; I bet someone has a good use case for using OOP while dealing with copious amounts of data.

Back to the topic at hand: Was OOP a failure? No more than lathes are failures. Not every handyman needs a lathe; not every programmer needs OOP. But when you do need it, it's a useful tool.

Exactly. "Everything is an object" was an extremism (today's extremism is the crusade against 'mutable state'), but otherwise OoO has been useful. For example it has seen great success in GUIs.

I view OO as analogous to the earliest control structures added to programming languages. We all remember "GOTO considered harmful", including generations of programmers who weren't alive when the letter was written, and may not have read it. Around that time, language designers realized that GOTOs were used to implement the same patterns over and over: Conditional execution, looping of various kinds. And we ended up with if statements, while loops, for loops, and so on.

Similarly, unfettered access to state was seen to be problematic. If you are implementing a skiplist, you don't want users of the list to be manipulating the links directly. You want to expose only the operations, and have the state accessible only to the implementation. That's encapsulation and modularization. And then inheritance provides a way to modify modularization slightly.

OO is really just a few ideas about organizing code and data, and you are free to use them or not, just as you are still free to use gotos. The hype got out of hand. I think OO madness was the first vastly overhyped software trend. Things got bad with all the Janitor ISA Employee examples got trotted out to explain OO to managers, and then some people believed OO was claiming to excuse programmers from actually developing efficient code. Anyone using, say, Java to build a complex software system realizes that OO is used to model internal things that never get anywhere near a customer-facing API.

There were zealots, there were AbstractFactoryFactoryAdapterFactory nuts, and the backlash against them is totally justified. But the core ideas of OO are just obviously good ones, and usable in non-OO languages too.

Even the FP languages that managed industry adoption, support some form of OOP.

It seems like he is ranting about the properties that allows us to keep controll over larger codebase.

Data hiding (and immutability) are good thing even as they sometimes force you duplicate data. So is separation between public and private, no matter what exact syntax is used to achieve it. Interfaces when done right allows you to reduce cognitive overload.

I could go on, but really oop was huge improvement over whar existed before - especially when used where it fits well. Functional programming is improvement too - especially when used where it fits - which is often place where oop fits less. The problem is programmers who don't bother to learn them and then they complain about not understanding them.