donald (12/14/82)
**WARNING** FLAME ON **** PLASMA TORCH LIT **** NAPALM DISPENSERS OPEN **
Sigh. Let me engage in one last diatribe in reply to "RICHARD HPS
(on ERCC DEC-10) <okeefe.r.a.edxa@BRL>" before I quit this debate.
Smalltalk adherents are beginning to show signs akin to religious mania.
Don't any of those people listen instead of mechanically mouthing the gospel?
Look fellas, I agree that Smalltalk is a very flexible language in which
you can do lots of wonderful things. I never said otherwise. Smalltalk
achieves this flexibility not by being "inherently object-oriented", but by
by virtue of its emphasis on dynamic features. To do this, things like
static type-checking are sacrificed. Indeed, static everything is sacrified!
I am just tired of the "Emperor's New Clothes" aura that permeates the
Smalltalk atmosphere. Smalltalk acolytes identify "object orientation"
(whatever that means!) with their God, Smalltalk. Nonsense. Smalltalk
is not the One True Way, although it does contain some good ideas.
[Smalltalk classes] 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.
At the cost of static type-checking. Where other languages force you
to explicitly instantiate things, Smalltalk lets you do it on the fly.
Now whether Smalltalk's way of doing thing is GOOD or not is another
question. Messages defaulting to a the super(*)class of a class
reminds me of PL/I's attitude towards identifier declarations.
Moreover, is overloading good or bad? That's another question entirely.
Ada overloading is not that tricky (my opinion), and it does have the
sorta nice feature of being statically checkable (albeit this makes it
at lot less flexible than Smalltalk's overloading; what price compilation?)
... 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.
That depends on how your generic type mechanism works. Certainly in CLU
or Alphard it doesn't work the way you're thinking of.
I don't know about YOUR psyche, but I personally don't think it presents
that great a difference to me. Of course I may be wrong, but now we're
talking opinion.
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 have never NEVER had it coherently explained to me why it is "literally
false". Shall we try again sir? (By the way, has anybody here read
Hoare's "Communicating Sequential Processes" paper?)
... 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.}
Huh? My FORTRAN subprogram doesn't have to use all of its parameters
either.
... 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::).
Hmmm. For you Algol 68 people out there, consider a thing which is defined
proc IfThenElse = (proc void ThenPart, proc void ElsePart) void : ...
Need I say more? Or if you don't like static type checking perhaps
you'd care to pass a functional parameter in a Lisp program?
I'll admit that Smalltalk does things like that with a lot less syntactic
ugliness, but there is NO FUNDAMENTAL ADVANTAGE possessed by Smalltalk.
It just lets you do things in a nicer way because there's no static checking
constraints. How often do I have to repeat that???
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.
Yeah, I think we used to call it a "heap". The idea of block structure
was segregation of objects that don't have to know about each other,
and also to allow an efficient stack regime for allocating/reclaiming
storage. You don't have to have scope control if you don't *want* it.
Remember that ugly little detail called "garbage collection"?
Anyway, Ada lets you do an operation called "new". Sound familiar?
As for Ada objects being simply records, take a closer look at your
Smalltalk objects and you may notice something.
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.
Ex cathedra. Some novices like BASIC too.
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.
Garbage collection raises its nasty head! "What happens to such an object"
makes one *little* difference: you have to haul out those slow storage
scavengers when you run out of storage with all those dead objects.
... 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.
Amen. Let me send a "var" message to my Pascal compiler so it can create
an integer object on the stack at run-time -- var x : integer;
Beautiful! Great object-orientation there. Now, even better, let me
send a "new" message to the Ada heap manager so it can create a character
object -- c : access character; c := new character;
Beautiful! Isn't object orientation great?
... 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.
Interesting CLAIMS these Smalltalk people make. Shall we back them up
with something more than pontifical statements? Also, what people understand
this? Mental models vary - maybe this is only good for 'a few people at
PARC'.
SmallTalk is not just a programming language, but a programming
*system*.
Yeah, so what? C'mon now. The programming system has nothing to do with
the language per se. Smalltalk may provide a nice environment for its
users, but it could have been done in FORTRAN if you really want.
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.
I am not confusing Simula "virtual attributes" with anything, mainly
because I never mentioned them before.
I think you're talking about the Simula "class concatenation" mechanism and I
assure you, sir, that I am familar with it, though I've never actually
programmed in Simula (just like I've never actually used Smalltalk...)
You are also mistaken: Alphard's "form extension" mechanism is exactly that.
In previous postings people were extolling the virtue of Smalltalk wherein
the message "plus" could be used to add integers or polynomials. Now that's
just overloading combined with a generic routine facility.
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.
Hmmm. Seems your first statement contradicts your other claims regarding
the simplicity of Smalltalk for children and novices. That aside, multi-
ple inheritence subclasses seem to be a less structured way of doing
what parameterized (or generic) type definitions do.
I can have a class "window" and a class "paragraph", and I can then have
a class "paragraph-in-window" which IS a window ... IS a paragraph ...
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 ... 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.
Ada doesn't have particularly good data abstraction mechanisms, but even
so, I'll try an make a case.
First of all, instead of calling them wp'w and wp'p why not
wp'window_part and wp'paragraph_part? Hardly irrelevant, and it seems
natural, if more verbose. Secondly, if you've redefined some of the
routines of window, why not (i) recompile windows or (ii) define
another window-like type which has the flashing draw? Or even simpler,
make your draw so that flashing is a parameter?
It seems to me that you're defeating the purpose of type definitions
when you start patching individual objects of a type with odd routines.
Smalltalk's way might be more convenient, but at least Ada can be
compiled. (Does anybody REALLY think that Smalltalk can be reasonably
compiled without restricting the language suitably?)
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.
Amazing. A whole paragraph of ex cathedra statements. "Children and
novices", eh? "spectacular success"? That has yet to be seen.
Moreover, you're lumping Simula with Smalltalk. A decidedly ODD thing
to do, since Simula DOES NOT use the bloody Smalltalk jargon, and in fact
Simula is more akin to CLU, Alphard, or Ada than Smalltalk because Simula
was designed in the Algol tradition. The point is, all of these languages
are fairly easily understood in the traditional programming language
framework, even though the specific terminology differs.
I agree that LRG can make up whatever jargon they wish to describe Smalltalk.
The fact that they failed to communicate their intentions to the rest of
world (aside from letting everybody flounder in a sea of buzzwords) is
inexcusable.
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.
<Expletive deleted>. The good gentlemen seems to ignore the elementary
fact that ALL OTHER THINGS BEING EQUAL, compiled code runs faster than
interpreted code. As for the "real world", obviously the man hasn't
compared the speed of execution of the average C program with the speed
of execution of the average Franz Lisp program under Unix. Oh excuse
me, "real world" means single-user Xerox Altos and Dorados don't it?
By the way, it is my understanding that the Dorado is a bit slice ECL machine
with hand tuned micro-code designed to execute SmallTalk. I have seen this
claimed by people from PARC, so I think it best to believe it. I have seen
video tapes of SmallTalk programs running on a Dorado. They ran SLOW.
If this is not inefficiency, I would like to know your definition of
the word. (P.S. rumour has it that Xerox will sell the Dorado in '83 for
about $172K. How much does a 780 cost? How many users under 4.1?)
** FLAME OFF ** PILOT LIGHT BURNING **
Whimiscally,
Don Chan
P.S. Aren't people getting sick of this debate?? I am!