IDL interfaces

[Kragen Sitaker]

Jonathan Shapiro writes:
> Each time I have looked, I've groaned at the pain of getting code generated
> that would match up efficiently with the EROS IPC system. This is a very
> minor objection. I kept deferring because none of the EROS capability
> invocations really call for a stub generator. There are no complex
> pointer-linked structures to move around; mostly it's a matter of getting
> the arguments to the stub procedure arranged in the right order. This was
> easier to do when there were fewer capability types, and it would now be
> very helpful to have an IDL-based stub generator for any number of reasons.

IMO, when you begin to need a code generator, it's a very strong sign
that your underlying interface is too complicated.  Code generators are
for messy interfaces what helpful girlfriends are for alcoholics: they
clean up your vomit and put you to bed, insulating you from the
knowledge of how low you've sunk.

Your comments about how EROS objects are not standard OO objects with
inheritance reminds me of Aleksandr Stepanov's comments on the OO
paradigm in his recent interview; the interview can be found at
http://www.stlport.org/resources/StepanovUSA.html.

Briefly, Stepanov says OO with inheritance and overriding is not the
ultimate programming paradigm.  Your experience with EROS is another
indicator that this is the case.  :)

The rest of this message consists of quotes from the interview.

 Q: This mean a radical change of mind from both imperative and OO thinking.    
 What are the benefits, and the drawbacks, of this paradigm compared to the     
 "standard" OO programming of SmallTalk or, say, Java?                          
                                                                                
 A: 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:                                               
                                                                                
 template <class StrictWeakOrdered>
 inline StrictWeakOrdered& max(StrictWeakOrdered& x, StrictWeakOrdered& y) {
   return x < y ? y : x;
 } 
 . . .  [const version omitted] . . .

 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.

. . .

 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.

. . . 
 Generic Programming has nothing to do with run time vs. compile time.
 The problem that I find with OOP is not just that it is slow, but that
 it does not allow me to express simplest possible algorithms. Again,
 the signature of max is:

max: T x T -> T

 It is not expressible in Java, because the inheritance from some class
 or interface T changes it into:

max: T' x T -> T

 You need covariant signature transformation and an ability to obtain
 types from types, a notion of a virtual type if you like, a v-table
 containing type descriptors.

. . .

 I got a very serious case of food poisoning from eating raw fish.
 While in the hospital, in the state of delirium, I suddenly realized
 that the ability to add numbers in parallel depends on the fact that
 addition is associative. (So, putting it simply, STL is the result of
 a bacterial infection.) In other words, I realized that a parallel
 reduction algorithm is associated with a semigroup structure type.
 That is the fundamental point: algorithms are defined on algebraic
 structures.  It took me another couple of years to realize that you
 have to extend the notion of structure by adding complexity
 requirements to regular axioms. And than it took 15 years to make it
 work. (I am still not sure that I have been successful in getting the
 point across to anybody outside the small circle of my friends.) I
 believe that iterator theories are as central to Computer Science as
 theories of rings or Banach spaces are central to Mathematics.  Every
 time I would look at an algorithm I would try to find a structure on
 which it is defined. So what I wanted to do was to describe algorithms
 generically. That's what I like to do. I can spend a month working on
 a well known algorithm trying to find its generic representation. So
 far, I have been singularly unsuccessful in explaining to people that
 this is an important activity.

. . .

 Generic programming is a programming method that is based in finding
 the most abstract representations of efficient algorithms. That is,
 you start with an algorithm and find the most general set of
 requirements that allows it to perform and to perform efficiently. The
 amazing thing is that many different algorithms need the same set of
 requirements and there are multiple implementations of these
 requirements. The analogous fact in mathematics is that many different
 theorems depend on the same set of axioms and there are many different
 models of the same axioms. Abstraction works! Generic programming
 assumes that there are some fundamental laws that govern the behavior
 of software components and that it is possible to design interoperable
 modules based on these laws. It is also possible to use the laws to
 guide our software design. STL is an example of generic programming.
 C++ is a language in which I was able to produce a convincing
 example.