Musings on An Interview with Alex Stepanov

I stumbled across this interesting interview with one of the creators of the STL for C++. Now, I haven’t used STL extensively, in fact mostly I’ve just seen it as a headache when porting other people’s software onto barely-supported platforms. And I am no big fan of C++ in general. But, there is some interesting stuff here.

Stepanov seems fairly skeptical of OO, and is mainly a proponent of C++. He created the STL as a tool for doing what he calls Generic Programming; As an example, he offers the example of implementing a simple max function in C++ using Generic Programming, and claims this can’t be done in Java:

My approach works, theirs does not work. Try to implement
a simple thing in the object oriented way, say, max. I do not
know how it can be done. Using generic programming I can write:

<tt>template &lt;class StrictWeakOrdered&gt;
inline StrictWeakOrdered&amp; max(StrictWeakOrdered&amp; x,
StrictWeakOrdered&amp; y) {
return x &lt; y ? y : x;
}

and
template &lt;class StrictWeakOrdered&gt;
inline const StrictWeakOrdered&amp; max(const StrictWeakOrdered&amp; x,
const StrictWeakOrdered&amp; y) {
return x &lt; y ? y : x;
}</tt>

(you do need both & and const &). And then I define what strict
weak ordered means. Try doing it in Java. You can’t write a generic max()
in Java that takes two arguments of some type and has a return value of
that same type. Inheritance and interfaces don’t help.

This is the sort of thing that I’ve always disliked about Java. Interestingly enough, this is pretty easily implemented in Objective-C. I also love his answer to the question, “What do you think of Java?”:

I spent several months programming in Java. Contrary to its authors prediction, it did not grow on me. I did not find any new insights – for the first time in my life programming in a new language did not bring me new insights. It keeps all the stuff that I never use in C++ – inheritance, virtuals – OO gook – and removes the stuff that I find useful. It might be successful – after all, MS DOS was – and it might be a profitable thing for all your readers to learn Java, but it has no intellectual value whatsoever. Look at their implementation of hash tables. Look at the sorting routines that come with their “cool” sorting applet. Try to use AWT. The best way to judge a language is to look at the code written by its proponents. “Radix enim omnium malorum est cupiditas” – and Java is clearly an example of a money oriented programming (MOP). As the chief proponent of Java at SGI told me: “Alex, you have to go where the money is.” But I do not particularly want to go where the money is – it usually does not smell nice there.

He also has some choice words about OO in general:

STL is not object oriented. I think that object orientedness is almost as much of a hoax as Artificial Intelligence. I have yet to see an interesting piece of code that comes from these OO people. In a sense, I am unfair to AI: I learned a lot of stuff from the MIT AI Lab crowd, they have done some really fundamental work: Bill Gosper’s Hakmem is one of the best things for a programmer to read. AI might not have had a serious foundation, but it produced Gosper and Stallman (Emacs), Moses (Macsyma) and Sussman (Scheme, together with Guy Steele). I find OOP technically unsound. It attempts to decompose the world in terms of interfaces that vary on a single type. To deal with the real problems you need multisorted algebras – families of interfaces that span multiple types. I find OOP philosophically unsound. It claims that everything is an object. Even if it is true it is not very interesting – saying that everything is an object is saying nothing at all. I find OOP methodologically wrong. It starts with classes. It is as if mathematicians would start with axioms. You do not start with axioms – you start with proofs. Only when you have found a bunch of related proofs, can you come up with axioms. You end with axioms. The same thing is true in programming: you have to start with interesting algorithms. Only when you understand them well, can you come up with an interface that will let them work.

The thing that strikes me reading this is that in spite of Stepanov’s hostility toward OO, I think that his concepts are really orthogonal to OO concepts, and that perhaps these ideas could be combined. In fact, I think that the problems he has with OO are based on a mixture of misunderstanding its uses, and exposure to inadequate OO languages. Let’s take those one at a time:

I find OOP technically unsound. It attempts to decompose the world in terms of interfaces that vary on a single type. To deal with the real problems you need multisorted algebras – families of interfaces that span multiple types.

Well, that’s not so hard to handle. Regular polymorphism as seen in all the various OO languages gets you part of the way; If you’re using Objective-C, the use of protocols gets you all the way! I don’t remember off the top of my head, but I believe this is handled quite well in Smalltalk and somewhat in Java as well.

I find OOP philosophically unsound. It claims that everything is an object. Even if it is true it is not very interesting – saying that everything is an object is saying nothing at all.

It seems that exposure to languages that are not “OO-complete” has blinded Stepanov to the possibilities of the technology. OK, turning data structures with associated specialized functions into objects amounts to little more than syntactic sugar. But the interesting things start to happen when language elements such as method names and implementations, chunks of code, and class definitions themselves are also represented as objects. C++ and Java offer very little in this way, compared to Smalltalk and Objective-C.

I find OOP methodologically wrong. It starts with classes. It is as if mathematicians would start with axioms. You do not start with axioms – you start with proofs. Only when you have found a bunch of related proofs, can you come up with axioms. You end with axioms. The same thing is true in programming: you have to start with interesting algorithms. Only when you understand them well, can you come up with an interface that will let them work.

I think this demonstrates that Stepanov has never had the opportunity to be knee-deep in an OO design project. “Starting with classes” is fundamentally unlike “starting with axioms”. A different analogy could be that classes correspond to proofs, and axioms correspond to complete applications. In any case, OO technology is generally used in a top-down approach for building applications that someone might want to use, so in a sense, yes, you are defining an outcome (the “axiom” you’re shooting for) before you work on the pieces (or “proofs”). But then, OO programming isn’t mathematics, and I think it’s not very helpful to frame it that way.

I may be going out on a limb here, but I think that for most OO programmers, the algorithms we were taught in school have little use in real-world applications. Certainly there are specialized algorithms for all kinds of specific uses (in finance, graphics, encryption, compression, etc), but IMHO most OO technology these days is used for moving and reorganizing data, and presenting it to the user. When you do need to massage data with any advanced algorithm, you’re generally dealing with data that is fairly homogenous (as far as type is concerned) and often packed into a structure you’ve designed specifically to optimize the algorithm in question; So what’s the point of genericizing algorithms?