okeefe.r.a.edxa@BRL@sri-unix (12/09/82)
From: RICHARD HPS (on ERCC DEC-10) <okeefe.r.a.edxa@BRL>
--------
This is a collation of some local messages. I should point out that
I have used Simula and Algol 68 a lot, but have yet to get my hands
on SmallTalk or Ada. However, I have read the Ada manual, and even
(re)discovered a bug in the description, fixed in the 1982 manual. I
have used Edinburgh LCF, which includes a poplymorphic type system
(Milner, J Comp & Sys Sci, 1978?) so does a rather better job of
parametric data types and procedures than any other typed language
including Ada. (HOPE also uses the same ideas). Though I haven't had
a chance to use it, I have had a chance to read the SmallTalk-76 manual,
and I have talked to someone who did program extensively in SmallTalk.
1) The iAPX432 is unbelievably expensive . Therefore it would not make a
good SmallTalk machine, nor would it make a good paperweight. What is
more, having support for a lot of high-level features is no good at all
unless they are exactly the same as the features the language wants.
Try implementing Algol 68 on the B6700, which is a high-level machine
(for an extended Algol 60): too many of the things the machine KNOWS
about the languages it was designed for just aren't true of Algol 68.
Similarly, I suspect that the -432 knows a great deal about programs
that use "data encapsulation" which are just not true about SmallTalk
programs.
2) Multiple Inheritance Subclassing is not at all the same thing as
parameterised capsules, though they have something in common. Classes
in SmallTalk are *dynamic* : if I add a new method to some class, all
its subclasses *immediately* inherit that method, with little or no
extra overhead. SmallTalk has an extremely coherent model of overloading:
if you ask an object O to do something S, O asks its class "have you got
a method for S", and if so it uses it, otherwise O's class's superclass
(or superclasses in the case of multiple inheritance) are asked... In
Ada overloading is very tricky indeed, and in fact if an Ada package
uses several other packages that define an operation, it doesn't get
ANY of them.
There may well be some sort of formal equivalence between parameterised
types and subclassing, but I have never seen one published. What is
more important is that the different concepts lead you to write a
different sort of program. With generic types, you regard the types as
components of your new capsule, while with subclassing, your new
capsule is an Extension of some previous classes. The psychological
difference between seeing a string as a kind of sequence with a few
extra operations (e.g. print might be different) and seeing a string as
a new abstract object represented as a sequence (where you have to
explicitly re-export every sequence operation you want) is very great.
3) I too have had the "Aha! SmallTalk message passing is just procedure
call!" reaction, but I have come to realise that this is wrong in two
respects. The first is that it is literally false. I do not know
SmallTalk-80, but I do know SmallTalk-72 and SmallTalk-76, and it is
possible for a method to decide how much of the message it will read.
A "message" is very nearly a genuine object with operations on it.
{SmallTalk-76 reduced this feature, SmallTalk-80 may have come even
closer to the conventional model.} In effect, a SmallTalk message
pass is much the same as Object.Procedure(Arg1,...,Argn) in SIMULA-67.
But (thanks to what is effectively a sort of call by name) it is
also used for some of the control structures (like for:: do::).
An important difference between this sort of call in SmallTalk and
Simula and calling an operation in Ada is that SmallTalk/Simula
objects are independent of block structure/scope rules, and can hang
around as long as you have a name for them; Ada "objects" are in some
sense fictitious, simply records.
4) The Learning Research Group is interested in designing a programming
language for the DynaBook. They want something that anybody (even
adults) can use. Hence an *extremely* important aspect of SmallTalk
is the way it is described: it doesn't matter if some programmers are
offended that SmallTalkers don't use the jargon of Ada (which is
different from the jargon of CLU or that of Alphard ...; all of these
are LATER than SmallTalk, so the criticism should really go the other
way!!!!), what does matter is that people learning SmallTalk should
be able to form an accurate internal model from the descriptions. In
particular, novices find the idea of an object-with-a-state that hangs
around as long as you have a name for it quite straightforward. You
don't even have to say what happens when you lose the last name for
something: since you have no way of getting at it (and since it won't
do anything unless it receives messages) what happens to such an
object makes no difference. So all you have to say is "if you send a
'create' message to a class, it will reply with a new object belonging
to that class". Beautiful. Similarly, once you have the idea of an
object, the idea of sending a message to it is very natural indeed,
and the fact that it sends a reply back is equally natural. People
can understand this who have never heard of procedures, and can
accurately understand what is going on. It is noteworthy that the
"little man" model used to explain procedure calling to novices uses
*exactly* this metaphor!!
5) SmallTalk is not just a programming language, but a programming
*system*. The class/message concepts are really supported by the
editor, browser, debugger. The metaphors of classes and messages
really do describe what appears to be happening when you work the
SmallTalk machine. There is nothing corresponding to a type
parameter in SmallTalk (well, classes are object of class class,
so I suppose an object could have a class parameter. I don't know
what you would do with it, though), so that metaphor is of no use
to a SmallTalk programmer.
========================================================================
Single inheritance subclasses are a simple idea; Simula had them a long
time ago. NO other language since (Ada, Alphard, CLU, ...) has provided
them. I suspect that Don Chan may have no Simula experience, which is
why he confuses Simula "virtual" attributes with overloading.
Multiple inheritance subclasses are NOT a simple idea. The parameterised
data type idea approximates multiple inheritance by forcing an object
of the new type to INCLUDE an object of each of the relevant types. In
SmallTalk, an object of the new class does not include objects of the
old classes, it IS a member of each of those classes. E.g. in SmallTalk
I can have a class "window" and a class "paragraph", and I can then have
a class "paragraph-in-window" which IS a window (all the messages of
windows apply to it, and anything expecting a window will be happy with
one of these objects), IS a paragraph (all the messages of paragraphs
apply toi it, and anything expecting a paragraph will be happy with it),
and may have further specialisations. In Ada, I have to create a new
package which includes a window and includes a paragraph, and explicitly
re-exports any operations (e.g.
package window_paragaph is ... w:window; p:paragraph;
procedure draw renames w'draw; ....
) that I want. The trouble is, I can't pass it to anything that expects
a window or a paragraph. To be sure, I can pass wp'w or wp'p {but I
have to know the names of these irrelevant components}, but if I have
redefined some of the procedures (maybe a draw that flashes the screen
and then does an ordinary draw), there is no way of passing the object
as a window but with the new procedures. Yet this is a perfectly
disciplined thing to do. Ada doesn't even permit this for single
inheritance. Simula does.
Multiple inheritance does not conflict with typing. Simula shows already
that typing (not as strong as it might have been, alas) is compatible
with single inheritance. You simply have to ensure that each rebound
attribute is rebound to something of a suitable type.
I repeat, the LRG people are entitled to divide up their language
however they please, and to give the parts whatever names take their
fancy, provided they make sense. Simula and SmallTalk PREDATE Ada;
descriptions of SmallTalk were available before descriptions of CLU
or Alphard. It is the "conventional" languages which have ignored
an established terminology. But the whole point of SmallTalk was to
design a new language AND A WAY OF DESCRIBING IT which could be
learned easily by children and other novices. It is a spectacular
success.
Where Chan gets the idea that Lisp or SmallTalk is
"inefficient" I do not know. Certainly not from the real world.
It may be difficult to produce efficient implementations of these
languages on some antiquated machines, but Xerox and LMI/Symbolics
have shown that it is possible to produce new architectures on which
these languages are efficient. The B6700 is a very efficient machine
for Algol, but a very inefficient machine for BCPL, which is the
exact opposite of most machines, because of a clash in philosophy
between the language and the architecture. If we restrict ourselves
to languages which can be implemented efficiently on a 370 (even a VAX)
we are locking ourselves away from an important area: the area of USABLE
languages. Experienced computer programmers are not the only people
who are entitled to use computers.
--------