
Collected Papers of Alexander A. Stepanov - mpiedrav
http://stepanovpapers.com/
======
enriquto
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](http://www.stlport.org/resources/StepanovUSA.html)

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

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

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

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

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

~~~
streetcat1
You might also want to check out

David Gries, the science of programming:

[https://www.springer.com/gp/book/9780387964805](https://www.springer.com/gp/book/9780387964805)

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

------
72deluxe
Thanks for all the templates

