Ten Things I Hate About Object-Oriented Programming

Filed under: Editorial — Oscar Nierstrasz @ 17:25

Boy, I some days I really hate object-oriented programming.

Apparently I’m not the only one. In the immortal words of Edsger Dijkstra: “Object-oriented programming is an exceptionally bad idea which could only have originated in California.”

Well, I’m not normally one to complain, but I think it is time to step back and take a serious look at what is wrong with OOP. In this spirit, I have prepared a modest list of Ten Things I Hate About Object-Oriented Programming.

1. Paradigm

What is the object-oriented paradigm anyway? Can we get a straight story on this? I have heard so many different versions of this that I really don’t know myself what it is.

If we go back to the origins of Smalltalk, we encounter the mantra, “Everything is an object”. Except variables. And packages. And primitives. And numbers and classes are also not really objects, and so on. Clearly “Everything is an object” cannot be the essence of the paradigm.

What is fundamental to OOP? Peter Wegner once proposed that objects + classes + inheritance were essential to object-oriented languages [http://doi.acm.org/10.1145/38807.38823]. Every programming language, however, supports these features differently, and they may not even support them as built-in features at all, so that is also clearly not the paradigm of OOP.

Others argue convincingly that OOP is really about Encapsulation, Data Abstraction and Information Hiding. The problem is that some sources will tell you that these are just different words for the same concepts. Yet other sources tell us that the three are fundamentally different in subtle ways.

Since the mid-eighties, several myths have been propagated about OOP. One of these is the Myth of Reuse, which says that OOP makes you more productive because instead of developing your code from scratch, you can just inherit from existing code and extend it. The other is the Myth of Design, which implies that analysis, design and implementation follow seamlessly from one another because it’s objects all the way down. Obviously neither of these candidates could really be the OO paradigm.

Let’s look at other paradigms which offer a particular way to solve programming problems. Procedural programming is often described as programs = data + algorithms. Logic programming says programs = facts + rules. Functional programming might be programs = functions + functions. This suggest that OOP means programs = objects + messages. Nice try, but this misses the point, I think.

For me the point of OOP is that it isn’t a paradigm like procedural, logic or functional programming. Instead, OOP says “for every problem you should design your own paradigm”. In other words, the OO paradigm really is: Programming is Modeling

2. Object-Oriented Programming Languages

Another thing I hate is the way that everybody loves to hate the other guy’s programming language. We like to divide the world into curly brackets vs square brackets vs round brackets.

Here are some of the nice things that people have said about some of our favorite OOPLs:

“C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do, it blows away your whole leg.”

It was Bjarne Stroustrup who said that, so that’s ok, I guess.

“Actually I made up the term ‘object-oriented’, and I can tell you I did not have C++ in mind.” — Alan Kay

“There are only two things wrong with C++: The initial concept and the implementation.” — Bertrand Meyer

“Within C++, there is a much smaller and cleaner language struggling to get out.” — Bjarne Stroustrup

“C++ is history repeated as tragedy. Java is history repeated as farce.” — Scott McKay

“Java, the best argument for Smalltalk since C++.” — Frank Winkler

“If Java had true garbage collection, most programs would delete themselves upon execution.” — Robert Sewell

But perhaps the best blanket condemnation is the following:

“There are only two kinds of languages: the ones people complain about and the ones nobody uses.” — Bjarne Stroustrup

3. Classes

Classes drive me crazy. That might seem strange, so let me explain why.

Clearly classes should be great. Our brain excels at classifying everything around us. So it seems natural to classify everything in OO programs too.

However, in the real world, there are only objects. Classes exist only in our minds. Can you give me a single real-world example of class that is a true, physical entity? No, I didn’t think so.

Now, here’s the problem. Have you ever considered why it is so much harder to understand OO programs than procedural ones?

Well, in procedural programs procedures call other procedures. Procedural source code shows us … procedures calling other procedures. That’s nice and easy, isn’t it?

In OO programs, objects send messages to other objects. OO source code shows us … classes inheriting from classes. Oops. There is a complete disconnect in OOP between the source code and the runtime entities. Our tools don’t help us because our IDEs show us classes, not objects.

I think that’s probably why Smalltalkers like to program in the debugger. The debugger lets us get our hands on the running objects and program them directly.

Here is my message for tool designers: please give us an IDE that shows us objects instead of classes!

4. Methods

To be fair, I hate methods too.

As we have all learned, methods in good OO programs should be short and sweet. Lots of little methods are good for development, understanding, reuse, and so on. Well, what’s the problem with that?

Well, consider that we actually spend more time reading OO code than writing it. This is what is known as productivity. Instead of spending many hours writing a lot of code to add some new functionality, we only have to write a few lines of code to get the new functionality in there, but we spend many hours trying to figure out which few lines of code to write!

One of the reasons it takes us so long is that we spend much of our time bouncing back and forth between … lots of little methods.

This is sometimes known as the Lost in Space syndrome. It has been reported since the early days of OOP. To quote Adele Goldberg, “In Smalltalk, everything happens somewhere else.”

I believe that the code-oriented view of today’s IDEs is largely to blame — given that OO code does not accurately reflect the running application, the IDE gets in our way instead of helping us to bridge the gap. Another reason I believe that Smalltalkers like to develop in the debugger is that it lets them clearly see which objects are communicating with which other objects. I am guessing that one of the reasons that Test-Driven Development is popular is that it also exposes object interactions during development.

It is not OOP that is broken — we just haven’t figured out (after over 40 years) how best to develop with it. We need to ask ourselves: Why should the source code be the dominant view in the IDE?

I want an IDE that lets me jump from the running application to the code and back again. (For a demonstration of this idea, have a look at the Seaside web development platform which allows you to navigate directly from a running web application to the editable source code. [http://seaside.st])

5. Types

OK, I admit it. I am an impatient guy, and I hate having to say everything twice. Types force me to do that.

I’m sure some of you are thinking — “Oh, how could you program in an untyped language. You could never be sure your code is correct.”

Of course there is no such thing as an “untyped” programming language — there are just statically and dynamically typed ones. Static types just prevent you from writing certain kinds of code. There is nothing wrong with that, in principle.

There are several problems, however, with types as we know them. First of all they tend to lead to a false sense of security. Just because your Java program compiles does not mean it has no errors (even type errors).

Second of all, and much more evil, is that type systems assume the world is consistent, but it isn’t! This makes it harder to write certain useful kinds of programs (especially reflective ones). Type systems cannot deal well with the fact that programs change, and that different bits of complex systems may not be consistent.

Finally, type systems don’t cope well with the fact that there are different useful notions of types. There is no one type system to rule them all. Recall the pain we experienced to extend Java with generics. These days there are many interesting and useful type systems being developed, but we cannot extend Java to accommodate them all. Gilad Bracha has proposed that type systems should not only be optional, in the sense that we should be able to run programs even if the type system is unhappy, but that they should be pluggable, meaning that we can plug multiple type systems into different parts of our programs. [http://bracha.org/pluggableTypesPosition.pdf] We need to take this proposal seriously and explore how our languages and development tools can be more easily adapted to diverse type systems.

6. Change

“Change is inevitable — except from a vending machine.” — Robert C. Gallagher

We all hate change, right? So, if everyone hates change, why do we all complain when things don’t get better? We know that useful programs must change, or they degrade over time.

(Incidentally, you know the difference between hardware and software? Hardware degrades if you don’t maintain it.)

Given that real programs must change, you would think that languages and their IDEs would support this. I challenge you, however, to name a single programming language mechanism that supports change. Those mechanisms that do deal with change restrict and control it rather than enable it.

The world is not consistent, but we can cope with that just fine. Context is a great tool for managing change and inconsistency. We are perfectly comfortable adapting our expectations and our behavior in our daily lives depending on the context in which we find ourselves, but the programs we write break immediately if their context changes.

I want to see context as a first-class concept in OO languages and IDEs. Both source code and running software should be able to adapt to changing context. I believe that many design patterns and idioms (such as visitors, and dependency injection) are simply artifacts of the lack of support for context, and would disappear if context were available as a first-class construct.

7. Design Patterns

Patterns. Can’t live with ’em, can’t live without ’em.

Every single design pattern makes your design more complicated.

Visitors. I rest my case.

8. Methodologies

“All methodologies are based on fear.” — Kent Beck

Evidently some of my students follow the Chuck Norris school of Agile Development:

“Chuck Norris pairs alone.”

“Chuck Norris doesn’t do iterative development. It’s right the first time, every time.”

“Chuck Norris doesn’t do documentation. He stares down the code until it tells him everything he wants to know.”

9. UML

Bertrand Meyer tells this story about always wondering why diagrammatic modeling languages were always so popular, until one day it hit him: “Bubbles don’t crash.” I believe his point is that OO languages are modeling languages. (AKA “All you need is code”)

There similarly appears to be something fundamentally wrong with model-driven development as it is usually understood — instead of generating code from models, the model should be the code.

By analogy, when FORTRAN was invented, it was sold as a high-level language from which source code would be generated. Nowadays we think of the high-level languages as being the source code.

I like to think that one day, when we grow up, perhaps we will think of the model as being the source code.

10. The Next New Thing

Finally, I hate the catchphrase: “Objects are not enough. We need …” Over the years we have needed frameworks, components, aspects, services (which, curiously, seems to bring us back to procedural programming!).

Given the fact that objects clearly never were enough, isn’t it odd that they have served us so well over all these years?


25 years ago we did not expect object-oriented programming to last as a “new” phenomenon for so long. We thought that OO conferences like ECOOP, OOPSLA and TOOLS would last for 4 or 5 years and then fade into the mainstream. It is too soon to dismiss OOP as just being part of the mainstream. Obviously we cannot feel passionately about something that does not interest us. The fact that academic and industrial research is still continuing suggests that there is something deep and important going on that we do not yet fully understand.

OOP is about taming complexity through modeling, but we have not mastered this yet, possibly because we have difficulty distinguishing real and accidental complexity.

I believe that to make further progress we must focus on change and how OOP can facilitate change. After all these years, we are still in the early days of OOP and understanding what it has to offer us.

Oscar Nierstrasz
[Banquet speech given at ECOOP 2010. Maribor, June 24, 2010]


  1. 1, 2, 10 & Conclusion: Solid points (+1 for being informative)

    Rest is all useless bashing (I’m sorry for using this term but I couldn’t find a decent word for being pessimist for the sake of it, complaining without considering the same points for the other side of things, …)

    Comment by Monis Iqbal — 2010/08/26 @ 21:33

  2. I see OO’s paradigm as “giving actions to data”. All the rest is variable in OO languages, but the common ground is that data has behaviour.

    Whatever you do with that, the way you protect data or behaviour, it’s up to the language. But from Perl to SmallTalk, data has behaviour and the name of that union is “object”.

    While Perl “bless” objects with “module descriptions” and C++ have “classes” to give types to “objects”, both do the same thing to “objects”: it gives them behaviour.

    From that, comes the concept of empty objects with only behaviour (helper classes), empty objects with empty behaviour but with style (interfaces), objects without behaviour (PODs), grouping of objects (inheritance, traits, templates). Everything those languages do is with objects, but the way you describe the grouping is via classes or modules, or whatever you want it to be called.

    In the end, there’s only one thing that survives: objects and its behaviours. That’s what’s all about OO.

    What you complain (and I agree) is how languages implement Object-Oriented design. Stroustroup went wrong when he first designed “C with Classes”, it should have been “Objects in C” to give the right weight to the right things.

    But well, that’s how things went because it’s more difficult to do what you say (run view in IDEs) than statically define everything, though it might not be the most logical view for the programmer.

    Comment by Renato Golin — 2010/08/29 @ 16:08

  3. You asked for “a single programming language mechanism that supports change”. I’ll give you two!

    1. Polymorphism: depending on how it’s used polymorphism can be the most important mechanism in OOP for supporting change. Not arbitrary change, to be sure, but at least those abstractions conceived of by the original programmer.
    2. IDE Refactorings: (not strictly a language mechanism, but the question was posed in the context of PL and IDE support for change). Modern IDEs increasingly support refactorings, both simple and more complex. The support is not always perfect, but it certainly aids the programmer in making changes to the design of software.

    Comment by @smalltalkhacker — 2010/08/29 @ 22:04

  4. I agree with you but I love OO too :)

    Comment by Jose — 2010/08/31 @ 17:32

  5. Thank you for the thoughtful reflection on objects. I agree that more context is often valuable when programming with objects. I do it with Java/Eclipse as detailed here: http://www.threeriversinstitute.org/ProgrammingInTheConcrete.htm

    Comment by Kent Beck — 2010/08/31 @ 18:57

  6. Thanks for this wonderful post. I wished I had attended ecoop this year to hear it real

    Comment by Alexandre Bergel — 2010/09/01 @ 01:28

  7. If you hate classes in the object-oriented concept model, then you’ll REALLY hate a Category-Theoretic mathematical understanding of computer science and software development (whether O-O or not).

    This prejudice usually indicates the triumph of training over education – you have learned to conceptualize in one, dominating paradigm to the exclusion of all others. Certainly, the same can be said of those who exclusively conceptualize in O-O, or AO or SO or …

    Comment by Ken Lloyd — 2010/09/02 @ 14:02

  8. > However, in the real world, there are only objects. Classes exist only in our minds. Can you give me a single real-world example of class that is a true, physical entity?

    public interface Car {
    public void toggleEngine();
    public void turnSteeringWheel();
    public void applyThrottle();
    public void applyBrake();

    public class DefaultCar implements Car { /*..* }

    public class HondaCivic extends DefaultCar { /*..*/ }

    public class ToyotaCamry extends DefaultCar { /*..*/ }

    and so on …

    It’s really a logical way to organize concepts.

    > In OO programs, objects send messages to other objects.

    /** car **/
    public void toggleEngine() {

    /** starter **/
    public void startEngine() {
    List pistons = /*…*/
    /* and so on */

    It’s really a logical way for concepts to interact.

    Comment by rhume55 — 2010/09/11 @ 19:49

  9. “If we go back to the origins of Smalltalk, we encounter the mantra, “Everything is an object”. Except variables. And packages. And primitives. And numbers and classes are also not really objects, and so on. Clearly “Everything is an object” cannot be the essence of the paradigm.”

    You are wrong. Variables are modeled as a either a Dictionary for global variables, eg: Smalltalk at: #VarName, or a positional mapping for local, instance, and other variables, eg: tempVarAt:/instVarAt:… as for packages, different systems model them in different ways, but always as objects, and numbers and classes are objects. Primitive methods are primitives, but still objects.

    Comment by kevin — 2010/09/11 @ 20:11

  10. Love the write up it shows that we are very often slaves to process and procedures.

    Comment by Bo — 2010/09/13 @ 04:39

  11. An object is a thing. Saying “everything is an object” is as meaningless as saying “everything is a thing.”

    What object oriented languages provide are user-defined abstract datatypes with our type discipline made less rigid via type polymorphism. That still leaves much room for the programming language designer to determine the details of the type system, picking a compromise between simplicity vs. safety vs. expressiveness/flexibility.

    The controversial part of OO is the mechanism for describing the implementation of one kind of object in terms of a related object’s implementation. The notion of inheritance combines implicit delegation (delegation from the object of the subclass to an unnamed implicit object of the superclass that it contains) with type polymorphism. I think language designers should have made this sort of implicit delegation more explicit (and flexible), and provided a separate, orthogonal construct for expressing the polymorphic subtyping.

    It seems that the pioneers of object-orientation were more concerned with behavioral semantics (“look at what my programs can do”) than with denotational semantics (“look at what these programming language features _mean_”).

    Related joke: “I learned reading via word recognition rather than by relying on phonetics. This leads to amusing errors sometimes, like when I confuse `data-warehousing’ with `data-whorehousing’. What is data-whorehousing, you ask? It’s a technique often used along with sex-object oriented programming.”

    Comment by fsilber — 2010/09/13 @ 17:31

  12. I really enjoyed reading this post, from the first to the very last word. Assessing “the model as being the source code” sounds a bit weird to me however – although I like what’s weird in general. It’s only a general feeling but I really don’t expect it to be the path OOP should go. Modelling is good for data, not for processing. The (only) design pattern I like to follow is the KISS one (Keep It Simple and Stupid). Optimization has long been forgotten for the sake of impressively useless complex designs and claim their beauty and pureness. After all we have so much resources now, why should we care about memory, disk space and CPU usage? What if “640KB ought to be enough for everyone”?

    One thing is sure on the other hand: Smalltalk is one of the only languages I don’t know yet (along with Lisp) and I’m now really willing to dive into it.

    By the way, you didn’t mention the OOP-like way of programming – the event-oriented one, may this be MS Visual Basic, MS MFC or Borland Delphi.

    Comment by Fabien Bouleau — 2010/09/13 @ 23:32

  13. Fabien Bouleau asked about the OOP-like event-oriented way of programming. This was another case in which hackers came up with a scheme that worked but couldn’t think of the right way to explain it. Thus, we get people overloading the word “event” to mean: (a) something that happened, (b) a notification that something happened, (c) a type of thing that can happen, for which your code can provide a handler to react when it does, or (d) a place to store your event handlers. The result is just meaningless jargon, as in one C# book which instructed readers to “add the delegate to the event” (you mean like “increment the explosion via the first-responder passed as the input argument”?). The only way a programmer could move from text-based systems to the presumably magical GUI-based system was by playing around with sample programs to see what happens when you do certain things.

    Instead, we should have had a description of the way the operating system converts GUI actions (events) into messages in a message stream while the program reads the message stream and, in response to each message, calls a procedure which may do any combination of (1) computing, (2) issuing commands to the GUI, or (3) adding its own messages into the message stream to be processed later. To someone who has programmed in conventional languages, that’s an explanation which makes sense.

    Comment by fsilber — 2010/09/14 @ 21:52

  14. “I challenge you, however, to name a *single* programming language mechanism that supports change.”


    Comment by Faré — 2010/09/15 @ 07:15

  15. … and YES, I have used it. See my ILC’2010 paper on ASDF 2.


    Other example: Erlang’s syntactic distinction between static calls vs dynamic calls, which supports hot upgrade of code.

    Comment by Faré — 2010/09/15 @ 07:20

  16. @Faré: Actually I mispoke. I intended the challenge to apply to *mainstream* programming languages. Both Lisp and Smalltalk support class extensions, for example, which are very nice mechanisms to support change. Other examples abound, but there are not so many in bread-and-butter languages.

    Comment by Oscar Nierstrasz — 2010/09/16 @ 18:14

  17. Dijkstra was clever, but he complained pretty much about everything. Find something about computers that you’re passionate about, and you can be damn sure he complained about it ;-)

    Some of the things you mentioned are flaws of specific OOP languages. Fragmentation and “my-language-is-better-than-yours” seems to have more to do with human nature. It happens with procedural and functional languages as well. And flamewars between fans of static vs dynamic typing are the norm.

    Finally, I don’t agree that OOP makes programs “harder to understand” than procedural programs. *Simple* programs are straightforward and easy to understand, of course — then again, so are *simple* OOP programs! Back in the real world, however…

    Comment by Andrés — 2010/09/19 @ 16:32

  18. Oscar: what about JavaScript, by the way? It’s a mainstream language for the web, with prototype-based OOP… which supports change!

    (though not a lot of people are aware of the full power of JavaScript)

    Comment by Andrés — 2010/09/19 @ 16:42

  19. Great talk!
    I especially like that it summarizes so well many of the ideas that new languages should try to avoid.
    Are you familiar with scenario-based programming (SBP) and the language of Live Sequence Charts (LSCs)?

    It is interesting to test in light of your mentioned points, since it is very different on many respects, and it avoids many faults that way.
    There is no paradigm yet, or you could consider the whole idea of SBP a new paradigm.
    Since OOP is so mainstream, it is still not widely used and therefore not condemned yet. Then again, maybe being condemned is a good think…
    It has the concept of classes, allowing to refer to groups of objects of the same class symbolically, which is closer to the idea of classes in our mind.
    Methods and types, still remain part of the language, but they are hard to get rid of, but methods in LSCs are used as messages between objects.
    The language is incremental and supports change easily.
    Design patterns and methodologies are not part of the language yet, but if it will be widely used, they will probably appear, since they are something that grows with the language, again, maybe not too bad…
    LSCs is taking a subset of UML, extending it, and making it executable. Making the model be the ‘source code’ or rather, the implementation.
    Is it the next new thing? Who knows, but to be that it needs to be combined with OOP at least as a transition, since OOP is around for too long.
    Thanks for this great summary.

    Comment by M. Gordon — 2010/10/05 @ 05:24

RSS feed for comments on this post. TrackBack URL

Leave a comment

Powered by WordPress