🚀 go-pugleaf

All this drivel about what language xyzzy can or can't do is pretty
tiresome, since nobody is saying anything new.  The arguments are also
pretty pointless, since most of the languages discussed (all but ML,
Russell, and Quest), whether "statically" or "dynamically" typed, have
pitifully inadequate type systems (Eiffel too -- nice touch, leaving
that contravariance hole in there for procedure types), if they claim
to have type systems at all.

People are also attributing the qualities of current language
implementations to the languages themselves; in many cases, either
"customization" (Chambers & Ungar) or constant propagation over the
types themselves ("Data Types are Values", Demers and Donahue) permits
dandy optimization both at compile time and at run time.  Does anyone
care to explain why truly polymorphic languages *must* make certain
speed compromises, regardless of implementation technology?  (I
suspect it is true, but I suspect that none of the usual suspects can
explain why it is true.)

Of course, there was no need to mention these papers, because I'm sure
that all you experts have read them and not only understand them, but
could do a much better job yourselves overnight in C++.

By the way, how efficient is a buggy program?

To translate:  here are some new challenges:

(1) why must a truly polymorphic (undefined term) language be less
    efficient than a non-polymorphic language?

(2) does any "expert" out there care to explain how "data types are
    values"?  (Hans Boehm is not allowed to answer this question)

(3) if you had to use "void *" to program generically in C/C++, what
    does this say about the "type system"?

(4) what's the contravariance rule?

It seems to me that one ought to have thought about these questions in
some detail before spouting off about type systems and expressiveness.

David Chase
Sun