Collected Papers of Alexander A. Stepanov(stepanovpapers.com) |
Collected Papers of Alexander A. Stepanov(stepanovpapers.com) |
For example, there is a lot of fun in his famous interview on an Italian magazine [1], linked on that site. It includes the widely celebrated sentence "object orientation is a hoax":
"
Question:
I think STL and Generic Programming mark a definite departure from the common C++ programming style, which I find is almost completely derived from SmallTalk. Do you agree?
Answer:
Yes. 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. "
I did just that in my old days when there was no real OOP around. And said interface included data structures that along with regular fields also had pointers to functions with some extra scaffolding around it. I did all of it on my own without having any slightest ideas about OOP. Luckily the actual OOP compilers came out soon.
So here's to you Mr. Stepanov.
Of course, that's exactly what Alan Kay says, and why he's not a fan of statically typed OO, which seems to be the thing Stepanov criticises here.
As I understand it, he's saying that, in languages like Smalltalk, the method that gets invoked for a particular message is determined by the type of the receiver only, not by the types of all the arguments. This is also true of, for example, Java before generics. By contrast, consider what you need to do for multiplication and division in a world containing integers Z, rationals Q, and floats R. Multiplication maps (Z,Z) to Z; (Z,Q), (Q,Z), and (Q,Q) to Q; and everything else to R. Division maps (Z,Z), (Z,Q), (Q,Z), and (Q,Q) to Q (Python 3 notwithstanding) plus division by zero; and everything else to R. In particular, note that if an integer is the "receiver" of a multiplication message, it may need to invoke the integer multiplication algorithm, the rational multiplication algorithm, or the float multiplication algorithm, and the return type will vary similarly.
In dynamically typed languages you can just resort to double dispatch in cases like this, but if you are trying to statically compute the type of the inner product of an integer vector and a rational vector (from the type signature of the inner-product operator), things are a bit more difficult.
CLOS and Dylan do have multiple dispatch for cases like this.
But Stepanov’s generic programming work is not primarily about so-called ad-hoc polymorphism, but about the other kind, parametric polymorphism. You want to be able to say things like, “Given a vector type V, its corresponding scalar type S has a multiplication operator S·V returning V,” and ideally give a generic specification from which efficient implementations of the operation can be automatically produced for any concrete vector type.
> Of course, that's exactly what Alan Kay says
I'm not sure what Alan Kay says. Your post could be improved by providing a reference or quote so that I can read Alan Kay's take. Note that to varying degrees both C++ and Haskell allow for intensionality without resorting to dynamic types.
[1] https://en.wikipedia.org/wiki/Extensional_and_intensional_de...
Edit: clarity.
Also, Ben-Ari's "Mathematical Logic for Computer Science" and Pierce's "Software Foundations".
David Gries, the science of programming: