Bad Engineering Properties
of Object-Oriented Languages

Luca Cardelli

Digital Equipment Corporation, Systems Research Center

Abstract. Object-oriented languages dominate procedural languages in certain software-engineering categories, but not in others. Further progress may involve adapting and reintroducing principles that are already well understood and widely exploited in procedural languages.

The object-oriented paradigm emerged in the 60's, roughly during the time that important notions such as data abstraction, polymorphism, and modularization were applied to the procedural paradigm. Eventually, object-oriented languages also acquired notions of data abstraction, polymorphism, and modularization, but not quite in the same way, and not quite as effectively.

In the last decade, object-oriented languages have been widely adopted as engineering tools because of their superiority with respect to software extensibility, which is a critical engineering property [4]. A large and growing fraction of software engineering is now carried out in object-oriented languages, taking over the domain traditionally covered by procedural languages. However, object-oriented languages have not incorporated all the engineering insights that have been successfully deployed in procedural languages. For example, they have emphasized code reuse at the expense of modularization, and dynamic inspection at the expense of static detection. Therefore, opportunities remain for applying important ideas that hopefully will result in even stronger engineering advantages for object-oriented languages.

I will begin by considering some obvious engineering metrics. For comparison purposes, I will first recall how advances in language design have resulted in the past in engineering improvements, according to these metrics. Next, I will review how object-oriented languages have yet to show similar improvements in some of these areas. Finally, I will discuss what remains to be done to integrate certain good engineering principles into object-oriented languages.

Consider the following (informal) metrics:

Let us consider first procedural languages. Over the course of many years, these languages acquired features that (more often than not) resulted in considerable improvements in engineering. This is of course not an accident: most language features were directly inspired or corroborated by engineering considerations. These engineering-friendly features include the notions of static typing, data abstraction, modularization, and parameterization, which resulted in the following improvements:

Let us now consider object-oriented languages, and see how they compare on these metrics.

These problems form obstacles to the further development of object-oriented software engineering, and in some situations are beginning to cause its outright rejection. Such problems can be solved either by a variety of ad hoc tools and methodologies, or by progress in language technology (both design and implementation). Here are some things that could or should be done in the various areas.

In conclusion, object-oriented languages still have to learn some engineering lessons from procedural languages. In fairness, designers of object-oriented languages did not simply "forget" to include properties such as good type systems and good modularity: the issues are intrinsically more complex than in procedural languages. Therefore, we have to work harder to produce object-oriented language designs that entail good engineering properties. We have to work even harder to produce good language designs.


  1. Dami, L., OO Type Theory web page, 1996.
  2. Goldberg, A. and D. Robson, Smalltalk-80. The language and its implementation. Addison-Wesley. 1983.
  3. Gosling, J., B. Joy, and G. Steele, The Java language specification. Addison-Wesley. 1996.
  4. Meyer, B., Object-oriented software construction. Prentice Hall. 1988. (Second edition to appear in 1997.)
  5. Odersky, M. and P. Wadler, Pizza into Java: Translating theory in to practice. Proc. 24nd Annual ACM Symposium on Principles of Programming Languages. 1997.
  6. Stroustrup, B., The C++ Programming Language. Second Edition. Addison-Wesley. 1991.