On the object-oriented myth

by Fred von Mame

It is often a common assumption in CS circles that object-oriented programming (OOP) is the holy grail of programming. It is the most popular programming paradigm today, and as such, it is unpopular not to like it. Whereas there have been many publications over the past 20 years devoted to the silver-bullet properties OOP, none of those publications were actually written by actual developers, because they were too busy writing actual code.

For some reason, it is also often implied that one’s dislike for OOP is rooted in one’s not understanding it. And more recently, the same argument has been made for managed memory, etc.. We have been told ad nauseam how much more productive developers will be if they use a the combo OOP + managed code.

But when I take a step back, look at the big picture and pose myself the question, “are we more productive today than we were 10 years ago?”, I can’t honestly say “yes”.

But before it is raised, I want to address the standard library argument. It is often argued that .NET (Java, etc.) will make developers more productive just by saving them the time it takes to rewrite a linked list from scratch every time. Now, seriously. I am yet to meet a C developer who will rewrite his linked list every time they need one. That argument is just rhetorical nonsense. If anything, C has way more linked list libraries than .NET will ever dream of having. And they come in every shape and size! So what’s the problem?

1. Libraries for common functionality (linked lists, hash tables, HTTP connections, graphics, …) do not ship with C. One has to go online and spend some time looking for one that will fit their needs, compare different ones, their pros and cons, etc.
2. These libraries often don’t talk to each other.

So the problem with C (and even C++) is not that they don’t have a standard library for common functionality. Is that they have too much of it – and it is too confusing. Imagine the following scenario:

Albert is a developer at SoftTacos. He works on a project being written in C. His boss asked him to find an HTTP library for their app to use, since they don’t want to write one from scratch. After some research, Albert found that there are 10 really popular libraries that they could use. Albert has to compare them for performance, size, licensing, prices, bugs, support, maintainability, etc.. Albert feels overwhelmed and anxious about making such a decision.

Albert finally makes a decision on which HTTP library to use. He chose a library that is fast, small, open-source and community-maintained. But it has a dependency on a string library they don’t currently use at SoftTacos, and it uses that string format to pass data back and forth. Now Albert has to go and write a wrapper layer around the HTTP library, converting between the in-use string format and the one the new code expects. Albert is feeling insecure at this point that his decision was even the right one.

This scenario described above is very common when dealing with C. So as I said above, there is a productivity hit for using C – not because it is procedural, but because it lacks a standard library that is integrated, organized and comprehensive, ready to meet today’s needs.

Back to the alleged productivity gains brought by OOP: if C had such a standard library as described above, I can’t see how writing applications in C++ (OOP) would be any more productive than C (procedural). And as a matter of fact, C++ (which also doesn’t have a comprehensive modern standard library) is usually regarded to be as productive as C.

Now hold on tight, for the next logical step seems to be a bit, ugh, illogical. If C and C++ are as productive as each other, their lack of productivity must come from the fact that they are both unmanaged languages. So the natural step is to add a managed layer on top of them, correct? </sarcasm> Of course not! It would’ve sufficed to have the class library.

Q: “What about the time saved by not having to debug pointer/memory issues?”
A: “What about all that time spent profiling the app to understand where that gigabyte of memory went? What about all that time spent trying to get performance to an acceptable point?”

Q: “What about the time saved by my nice little IDE?”
A: “What about all that time spent fixing bugs because you never thought about your design and architecture, and instead you just wrote code like a cowboy?”

Potok et al. have conclusively shown in a meticulous 1999 study that there is no significant difference in productivity between OOP and procedural approaches. Luda Cardelli (assistant director at Microsoft Research in Cambridge, UK) has published a famous paper titled "Bad Engineering Properties of Object-Oriented Languages”.

Here are some of my favorite quotes about OOP (my favorite ones are the ones by Richard Mansfield):

“Almost as much of a hoax as Artificial Intelligence”.
— Alexander Stepanov (the primary designer and implementer of the C++ STL) [ref, ref]

"The problem with object-oriented languages is they’ve got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle."
—  Joe Armstrong (inventor of Erlang) [ref]

"Like countless other intellectual fads over the years (relevance, communism, modernism, and so on — history is littered with them), OOP will be with us until eventually reality asserts itself. But considering how OOP currently pervades both universities and workplaces, OOP may well prove to be a durable delusion. Entire generations of indoctrinated programmers continue to march out of the academy, committed to OOP and nothing but OOP for the rest of their lives."
— Richard Mansfield (author and former editor of COMPUTE! magazine) [ref]

"OOP is to writing a program, what going through airport security is to flying"
— Richard Mansfield (author and former editor of COMPUTE! magazine) [ref]

Enough said.

UPDATE:
I got feedback that the lines between OOP and managed memory seem to be blurred. Whereas this post focuses primarily on OOP, in today’s development environment it is almost impossible to think of OOP without thinking of some level of managed memory. But still, I should’ve done a better job separating the two of them.