Re: Cumbersome Polymorphism

[Brian Rogoff <bpr@best.com>]

On Sat, 25 Jan 1997, James O'Connor wrote:
> Robert A Duff wrote:
> > The problems of allocation and deallocation are hidden from the
> > Smalltalk programmer (and from the Ada programmer, if you can find a
> > garbage-collected implementation of Ada, which isn't easy).  But the
> > pointers are not hidden in either language: The fundamental thing that
> > makes a pointer a pointer is that two pointers can point at the same
> > thing.  This is what makes pointers useful.  And this happens in both
> > languages, despite the fact that dereferencing the pointer is always
> > implicit in Smalltalk.  
> 
> That's actually a big difference in approach (IMHO).  While it's true
> that pointers are not hidden in Smalltalk, they are also not viewed as
> such.  Since every variable is really a pointer and every pointer is
> automatically derefrenced, you stop thinking in terms of pointers and
> just end up think in terms of the objects they point at.  There is no
> 'non-pointer' syntax to deal with.

	There are many applications where the perceived performance
penalties of this approach are far too great. 

> > In Ada, you are forced to use a pointer if you
> > have something that changes size, and this is indeed unfortunate from
> > the functionality point of view.  In Smalltalk, you are forced to use a
> > pointer ALWAYS, and IMHO that's even more unfortunate.
> 
> I'm curious, why do you consider that unfortunate?  It certainly makes
> the sytanx very clean and alleviates a lot of headaches from
> developers.  Like I said, you stop thinking in terms of pointers.

	I won't presume to speak for Robert Duff, but as I said above,
there are many applications, particularly those of a numeric nature, where 
performance constraints force one to think in terms of values. Would you 
write a polymorphic matrix class in Smalltalk, and expect it to have
similar performance characteristics to a generic matrix type in Ada,
Eiffel (using expanded classes for the matrix elements), or (gak!) C++? 
Perhaps you think such applications are but a tiny fraction of all
applications, but I would disagree. Numerics and signal processing codes 
are found in lots of software.

	Perhaps someone will now mention the excellent Stalin compiler for
the dynamic language Scheme, which ameliorates this problem by using
agressive type inferencing. I'll reply that while I find this work very
promising, it is still research, it adds considerably to compile time, and 
hasn't been used with really gigantic codes.  

	IMO, the Dylan language approach of allowing optional type
information to be added to a dynamic "all objects like Smalltalk" language
designed from the start to be optimized for performance, seems like a 
good idea. We'll have to wait until real compilers are available to see 
how good it works in practice.

	None of the above is meant to imply that I think Smalltalk is not 
an excellent programming language (languages, really ;-) for a large range 
of applications. I would *much* rather use ST than Visual Basic or Tcl as 
high level glue, and use Ada 95 for the high performance compute engine. 
Alas, current industry practice seems to favor VB and C++.

-- Brian