Collected Papers of Alexander A. Stepanov | Hacker News Reader

Collected Papers of Alexander A. Stepanov

stepanovpapers.com

60 points_mtkq15 comments

Besides his great books and massive work in generic programming, the man has quite a sense of humor.

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. "

[1] http://www.stlport.org/resources/StepanovUSA.html

> To deal with the real problems you need multisorted algebras

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.

I believe that the distinction that Stepanov is alluding to is the distinction between intensional and extensional types.[1]

> 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.

The context here is, “I find OOP technically unsound. It attempts to decompose the world in terms of interfaces that vary on a single type.”

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.

"I have yet to see an interesting piece of code that comes from these OO people [...] It claims that everything is an object. Even if it is true it is not very interesting"

Do you think something in here is not intended seriously?

"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.

Sounds like he wants Common Lisp generic functions, which dynamically dispatch on the classes of all arguments, not just the first.

He was my next door office neighbor at SGI in the 90's. As a fairly junior programmer back then, learning about C++, it was awesome to go talk to Mr. Stepanov (never used first name with him), and then have your STL question answered with about an hour of contextual information for background. He was a little more measured in his hatred of OO in person, but all being said and done, our use of C++ was like using C with STL and RAII, no object hierarchies.

Elements of Programming seems to be approaching the limits of advanced programming techniques. It has the reputation of being mathematically rigorous. What else can you study at that point regarding the mathematics of programming? My concern is that software engineering will be slow to graduate into a science, and we will be stuck as merely an artform for the foreseeable future.

Perhaps Knuth's "The Art of Computer Programming" and Sedgewick's (Knuth's student) "An Introduction to the Analysis of Algorithms".

Also, Ben-Ari's "Mathematical Logic for Computer Science" and Pierce's "Software Foundations".

This is my first time hearing of any of these authors besides Knuth, thanks.

You might also want to check out

David Gries, the science of programming:

https://www.springer.com/gp/book/9780387964805

Another aspect of the mathematics of programming is the Categorical perspective. For a taste, I've been enjoying following along at home with MIT's course 18.S097: Programming with Categories:

http://brendanfong.com/programmingcats.html

Thanks for all the templates

Reply on news.ycombinator.com