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