From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,924aad49bcf9e4e7 X-Google-Attributes: gid103376,public From: Brian Rogoff Subject: Re: Cumbersome Polymorphism Date: 1997/01/26 Message-ID: #1/1 X-Deja-AN: 212385814 references: <32E7ABE8.3BF3@eurocontrol.fr> <5c9put$48t@hetre.wanadoo.fr> <32EAA1A0.7C43@jmpstart.com> content-type: TEXT/PLAIN; charset=US-ASCII mime-version: 1.0 newsgroups: comp.lang.ada Date: 1997-01-26T00:00:00+00:00 List-Id: 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