January 2011

Taboo “OO”

We should stop using the term “Object Oriented”.

I see two reasons:

• “OO” has many definitions, and we just can’t pick one. For instance, by Alan Kay’s definition, Erlang, a functional concurrent language, is more OO than C++. This alone should warrant a blanket ban on the term.

• There is a largely accepted definition of OO: roughly the style encouraged by Java (classes, encapsulation, inheritance, subtype polymorphism, and even sometimes genericity). However, while this sounds like typical OO, in practice it’s little more than syntactic sugar over plain old procedural programming. Hardly a whole new paradigm.

WTF?

On one hand, I have overwhelming evidence that “OO” is useless in technical discussions. No one readily knows what each instance of that term is intended to mean, and when we do, it generally isn’t distinctive enough.

On the other hand, many programmers are still uttering that term with a straight face. They’re still using it to describe programming languages and practices, to assess their merits, and to address their flaws.

Are they all nuts?

For quite some time, I refused to come to that conclusion, because it suspiciously sounded like some “they’re all wrong, I’ll show them” syndrome. Let’s face it, the prior probability that a majority of professionals have such a basic misconception about their own field is small. I was confused. So I looked. I asked. And I finally found the answer.

They are nuts

Or at least somehow incapable of changing their minds in the face of overwhelming evidence. It took me some time to understand what was going on. I now see several reasons.

One reason has to do with: “If a tree falls in the forest, and no one hears it, does it make a sound?”. Everyone should agree that in such a case there will be acoustic vibrations but no auditory experience, and be done with it. The facts have all been laid out, after all. Nevertheless, many can still feel the nagging question: “Okay, but does it make a sound?”. This feels like a real question. Actually, it’s a mere dispute over the meaning of “sound”.

The same happens with “OO”: we know for instance that C++ has classes and inheritance, but also primitive types, and no “top” class. We should be done with it, but since have the label “OO”, whether C++ is OO or not feels like a real question. Actually, it’s a mere dispute over the meaning of “OO”. OO is not some thing that exist independently of us, of which there is a natural definition we could find. We just failed to pick a definition among those we made up.

Another reason has to do with the aura of mystery that surrounds “OO”. I often hear “OO is hard”; “Few really get OO”. Wait a minute, are you saying this because you know OO, or because you don’t?

• If you do know OO, if you actually got it, Then I expect a technical explanation, so I can at least tell if any given program is OO or not, and to what extent. It may be hard, but I’m sufficiently full of myself to think I can take it.

• If you don’t, please do not treat your ignorance as strong evidence that OO is actually hard. It may be true, but there are other possible causes: lack of effort, poor teachers, bad books, or lack of a key insight. Sure, “OO is hard” is very convenient: it sounds wise, and often prevent further questions. It doesn’t explain anything, however. Parroting it back will only sustain the aura of mystery around “OO”.

Yet another reason is the popularity of languages that brand themselves “OO”. C++, Java, Python, Javascript, Self… New ones pop up daily. That doesn’t help define “OO”, but it does makes it ever more present. All these people around OO must me onto something, right? Upon reflection, I think not. I suspect this is just some kind of network effect.

Conclusion

OO is not some arcane knowledge that most of us don’t “get”. “OO” doesn’t intrinsically have a definition that we merely have a hard time to find. It has become a mere marketing term wrapped up in a fake aura of mystery, completely unsuitable for serious discussion.

I’d like the madness to stop.