A page built on heresy
The provocatively named page “Object Orientation Is a Hoax” is hard to pass by. It sits beside another called “Object Orientation Is Dead,” which gives a fair idea of its mood. What makes the collection more than a rant is that many of the anti-OO remarks come from people with serious credentials. Alexander Stepanov and Bjarne Stroustrup are among them.
Alexander Stepanov: STL is not object-oriented
Stepanov, the man behind STL, gave an interview years ago in which he was asked whether STL and generic programming represented a departure from the usual C++ style, a style the interviewer saw as largely derived from Smalltalk. Stepanov agreed, then went further: STL is not object-oriented. He described object orientation as “almost as much of a hoax as Artificial Intelligence,” a comparison he immediately qualified. AI, he said, had at least been connected to people and work he respected: Bill Gosper’s Hakmem, Stallman’s Emacs, Moses’s Macsyma, Sussman and Guy Steele’s Scheme. Whatever AI’s foundations, it had produced serious work and serious programmers. OO, in his experience, had not shown him interesting code from OO practitioners.
His objections were not merely stylistic:
- Technically unsound: OOP tries to decompose the world through interfaces that vary on a single type. Real problems need multisorted algebras—families of interfaces spanning multiple types.
- Philosophically unsound: it claims everything is an object. Even if that were true, it would not be an interesting truth. Saying everything is an object says nothing.
- Methodologically wrong: it starts with classes, as if mathematicians started with axioms. Mathematicians actually start with proofs; after finding enough related proofs, they formulate axioms. Programmers should start with interesting algorithms; only after understanding them should they extract interfaces that let those algorithms work.
Bjarne Stroustrup: OO is not a synonym for good
In a 1998 IEEE interview, Stroustrup took a less inflammatory but equally skeptical position. He began by rejecting the equation of OO with good. Not every good program is object-oriented, and not every object-oriented program is good. If both were true, “object-oriented” would just mean “good,” a vacuous buzzword that offers little help when practical decisions have to be made.
Stroustrup’s working definition equates OOP with heavy use of class hierarchies and virtual functions, called methods in some languages. Historically this is accurate: class hierarchies, virtual functions, and their associated design philosophy distinguished Simula from other languages of its time. Smalltalk, he notes, emphasized this part of Simula’s legacy most strongly.
Defining OO this way is practical because it gives some indication of where OO is likely to work. One looks for concepts with a hierarchical ordering, variants of a concept that can share an implementation, and objects that can be handled through a common interface without being exactly the same type. With examples and experience, this can become the basis of a powerful design approach.
But Stroustrup also set limits. Not every concept fits a hierarchy. Not every relationship between concepts is hierarchical. Not every problem is best approached by focusing on objects first; some problems are primarily algorithmic. A general-purpose language should support multiple ways of thinking and multiple programming styles because problems differ and solutions differ. C++ supports such variety, which makes “multiparadigm” a more fitting label than “object-oriented” if a label is needed.
The real problem is the halo
Whether OO deserves the word hoax is a separate question. What strikes me is not that Stepanov or Stroustrup are against OO, but that the debate exists at all. C++, OO, XML, SOA, grid computing, and similar ideas often arrive with a sacred glow. At first there is only praise. That single voice is what worries me, not the technology itself. It is frightening when our industry—or any society—promotes and believes something with no dissent at all.
I recognize the source of that discomfort: a black-and-white education that wants things to be all good or all bad. In practice, C++, agile development, CMMi, OO, design patterns, refactoring—all have strengths and weaknesses. The important question is how and where they are used. Some tools fit some problems; no tool fits every problem. Anything advertised as a universal solution starts to look less like engineering and more like religion.
So when I hear a single, glossy, television-shopping tone around a method or a technology—or the confident uniformity of a news broadcast—I feel a reflexive resistance. I will leave the final judgment to readers. This piece is dedicated to the OO-oriented, design-pattern-oriented, agile-oriented, process-oriented believers, and to every other faith that treats a programming technique as a creed.