Software Paradigms

In my youth there was a lot of support for object oriented programming. It was generally agreed that we had a software productivity problem: it was too hard to write programs. The solution was supposedly to adopt object oriented programming techniques. This was expressed in its purest form in Smalltalk, and was brought to the masses in Object Pascal (later Delphi) and C++, followed by Java.

Object oriented programming had a few different ideas, all of which centered around the notion of separating data into relatively small and independent units. Methods are defined independently of specific data, and a given method may be applied to different data units. Data units are grouped by sets of methods, and the method sets can be put into inheritance and abstraction hierarchies.

Object oriented approaches were greatly oversold, and it became clear over time that while they did have many good ideas, they were not the solution to the problems of programming. One of the problems of the object oriented approach is that it encourages you to focus on the relationship between sets of methods that apply to data, rather than focusing on the structure of the data itself. In C++ or Java terms, it’s easy to spend more time thinking about the inheritance relationships between classes than about the individual objects.

Over time, C++ shifted toward a somewhat different style of programming found in the Standard Template Library. This style is based on templates, and focuses on containers and algorithms. I’ve seen people advocate this approach to the point of saying that a good program should have no non-abstract loops: that everything should be done via an appropriate algorithm.

The issue I find with these approaches in practice is that they tend to lead to too much abstraction. Fundamentally all programs deal with data. The goal of a program is to manipulate the data in some way. The goal of abstraction and class inheritance is to permit you to write less code. The goal of data encapsulation is to make your program more maintainable over time. Abstraction beyond those points may make your program better by some artificial index, but it is not really helping you get things done.

If you find yourself asking yourself whether to introduce a new level in your class hierarchy, or you find yourself writing a new template which will only be instantiated once, then you may be falling victim to the abstraction penalty. Shake it off and return to focusing on what your program really needs to do.






3 responses to “Software Paradigms”

  1. anupam-kapoor Avatar

    my rule-o-thumb is to have a class with interface and a hidden representation if and only if i can think of an invariant for a class. invariant kind of justifies the existence of a class. and the class is responsible for maintaining that invariant. in other words, i think, invariant explicitly defines the relationship between different pieces of data in a class…

  2. Goat Avatar

    The biggest hallucination in programming is that is possible to turn bad programmer into good by putting new rules and constrains and more bureaucracy in the language. Until someone builds true AI there will be absolutely no way to guarantee good code. I don’t mind using OOP techniques when appropriate and it’s cool when language supports some way to separate code to more manageable parts and reuse patterns. Namespaces, functions, classes, macros, generics and other stuff are all good tools for managing complexity. The problem is when language forces you to shoehorn everything into objects when there is no need to.

    Java is by far the worst offender. You can’t even create function that’s not class member. And there is so much syntactic clutter it’s hard to see anything. Public. Static. Void. Main. String. Args. Insane. And you have to build new class any time you want function to return two or more arguments. I wonder if anyone who designed Java actually used it.

    And for the sake of god, put some dynamic features in language. Even with strong and static typing, you can make things more flexible by adding good support for dictionaries, good first class functions, good parser (for building mini languages) and so on.

    Hope Go will be better once it matures. It looks promising, but no one seem to be using it.



  3. Ian Lance Taylor Avatar

    Thanks for the comments.

    It’s hard to know how many people are using Go. There are a bunch of different pointers over at , but I don’t know how many of them are really active projects.

Leave a Reply