kh (12/04/82)
Yes, there are differences between the "object-oriented, message-passing" paradigm in Smalltalk and the more usual "data encapsulation, subroutines with paramaters". For example, if a class doesn't know how to handle a message, that function defaults to the super-class. Also, variable length messages are easy, whereas in most languages, it is difficult or impossible to do that directly. Surely some of the people at PARC read the INFO-MICRO list and can supply further details. Kenny Hirsch duke!unc!kh kh.unc@UDel-Relay Chapel Hill, N.C.
txr.usc-cse@Udel-Relay (12/21/82)
[ I apologize to any of you who get this twice. My mailer croaked in
the middle of the original submission, probably do due the long Cc:
list. If you know a Cc: person not on info-micro, you might ship him a
copy.]
_________________________________
Cc: harpo!ihnp4!ihldt!ll1!sb1!mb2b!uofm-cv!buzc at Ucb-C70,
decvax!utzoo!utcsrgv!donald at Ucb-C70,
mwm@Okc-Unix, GUMBY@Mit-Mc, Agre at Mit-Mc,
KELLY at Rutgers, decvax!duke!mcnc!unc!wm at Ucb-C70,
decvax!utzoo!watmath!mdrutenberg at Ucb-C70,
decvax!genradbo!mitccc!rpk at Ucb-C70,
decvax!utzoo!watmath!idhopper at Ucb-C70,
menlo70!nsc!freund at Ucb-C70,
majurski at Nbs-Vms, decvax!duke!unc!kh at Ucb-C70,
harpo!floyd!vax135!ariel!orion!lime!we13!otuxa!ll1!ihldt!ihnp4!ihnss!knudsen at Ucb-C70,
decvax!duke!bcw at Ucb-C70,
harpo!ihnp4!ihps3!houxz!hocda!tjt at Ucb-C70,
deutsch.pa@parc-maxc
Reply-To: txr@ecl
This has all the makings of being one *long* message, so if you're in a
hurry skip it and read it later when you have time. For those of you
who wonder whether you have the time to spare, at least let me say that
I hope to be informative, interesting, and to flame as little as
possible. [I realize upon reading the message in final form that I
flamed more than I planned. For the readers benefit square brackets,
such as surround the text you are now reading, surround flame-like
material. Even so I have tried to keep emotionalism to an absolute
minimum.]
(I apologize that my remarks are not more timely. I am not on
info-micro and so only recently became aware of the discussion touched
off.)
In going over the 50,000 (!) characters of messages on Smalltalk (oh,
note that it is "Smalltalk", not "SmallTalk"), there seem to be a few
topics which are confused from time to time, such as (1) is Smalltalk
good?, (2) is Smalltalk better?, (3) is Smalltalk different?, (4) how is
Smalltalk different?, (5) how is Smalltalk better? It is important to
realize that these questions (and others as well) are being asked, for
they require different kinds of answers. Generally I will talk about
things as ST is different, explain how it is different, and then
explain why this difference makes ST better.
(1) ST is germane to info-micro, even though it could just as well have
come up on other mailing lists. This is true not only because of the
iAPX432, which claims to "support the object oriented design
methodology," (from the Intel literature), but also because ST is meant
to fill the software need of a truly personal computer (and it seems to
me that's where info-micro is at, among other places).
(2) Somewhere along the line someone has gotten the idea that Smalltalk
is interpreted, ineffecient, and all those other bad things. Smalltalk
is compiled, compiled into byte codes like Pascal P-code or Mesa byte
codes. The one exception is that messages are bound dynamically, at
run time. This sounds awful, (and awfully slow), I know, but in fact
the looking of a messages in the receivers method dictionaries takes
only about 10% of the time of the ST virtual machine. So even if
method lookup was infinitely fast (as for example in a more
conventional procedure call mechanism) it would only speed things up by
10%, which is a negligible factor. Most of the time (near 50%) is
spent allocating and initializing contexts for receiving messages,
which happens because ST methods tend to be very short, and message
sending happens a lot. Any programming language where the style of use
is lots of very short procedures will have the same behavior, in fact
probably more than ST since the ST message sending / context allocating
mechanism is known to be central, crucial, and consequently has had the
h**l optimized out of it.
[(2') By reading between the lines, it is clear that the lack of
static typing is at least partially responsible for the feeling that ST
is slow. I know it's hard to believe, but it just isn't that expensive
to postpone the binding until run time. And context allocation, though
costly in small grain, may actually improve performance in the large,
due to reduced size of working set -- probably the computer you are
using right now is disk limited rather than processor limited. The
real question is not which system does an instruction faster (or even
which system executes a program faster) but which system allows me to
get my work done *better*, which has an element of (my macroscopic)
time but is also concerned with quality, creativity, etc.]
(3) To illustrate the difference between data encapsulation and object
oriented, here is a simple exercise. Write a small amount of code to
evaluate expression trees (with, say, the four classic operators plus,
minus, times, divide). You may suppose for simplicity that the leaves
are integers. Now change the code to accomodate real numbers -- how
much work is that? Now let me come along after the fact and add any
possible new data type for the leaves -- say, symbolic polinomials.
How much work is that? In Smalltalk, the amount of extra work is zero.
Not only does the original source code work without modification, but
the original *compiled* code bytes work without modification. Not only
have we saved a compilation (which is relevant, but not the most
important), we have saved on generated code. In Ada, for example, if
you were very clever, you could have used the generic mechanism to
parameterize the expression tree evaluator code and so avoid doing much
additional work to accomodate the new data types, but even if you had
you would have to instantiate the module for each data type and this
would produce more and more code for each data type added. In other
words, in data encapsulation (ala Ada, CLU, etc.) there is non-linear
code growth, whereas in ST the code growth for the same problem would
be linear. Actually, it's even more extreme than that -- other
examples point out non-linear *source* code growth for Ada et. al. as
well. As the source gets bigger, bigger faster than the problem, and
the compiled code gets bigger faster still, we find the "solution" to
the problem has enlarged beyond our capacity to understand it. If
instead, as in ST, the source and target code grew linearly with the
problem size, we at least have a hope of reading it (and using it on
our finite machine).
(4) Inheritance (the single variety) is more than
overloading + extension + generic, all roled into one. This is hard to
explain simply, partly this is the same as point (3), partly this is
because of the factoring principle (one thing being in only one place),
and partly it's because of the way "self" and "super" are handled.
Perhaps an example will clarify: in Smalltalk 76 Class Object was 5
pages of code, and a lot of that code was reused by essentially all
objects in the system. Say that 50% of the Class Object code was
reused on the average, and that there were 100 Classes in Smalltalk 76.
That's 250 pages of code done in 5 pages. Could that same kind of wide
ranging applicability be done in Ada? In Alphard? In Clu?
(5) Inheritance (the multiple variety) is clearly a generalization of
the single variety. Is it also parameterized abstract data types by
another name? Without being specific, both about the inheritance
mechanism, and about the par-abs-data-types (yes, different people mean
different things by this long, hard to type, phrase), this is a
difficult question to answer. Since the existing ST does not
(standardly) have multiple inheritance, I will skip this question. But
I would like to say that multiple inheritance is not easily explained
just as a generalization of single. I was part of the Star group at
Xerox that came up with the traits model, and, as one of the principals
later said, we were "groping in the dark." Not only that, but in
retrospect I think we did it wrong. Single inheritance has worked out
tremendously well, and it is only natural to try to improve it, but
just changing it (making it "more general"?) won't necessarily do that.
Another way of changing inheritance is to make it variable in time,
i.e., dynamic. How should that be done? How useful is it? How
expensive is it? These questions need to be answered before we say
that some proposed new inheritance scheme is "better."
(6) Because of the *lack* of typing in the conventional sense, ST
programs encourage (in some sense even require) you to leave the
interpretation of the "meaning" of a message up to the receiver. Is
this true in Ada? Remember, in Ada (Clu, Alphard, ...) you can
determine *at compile time* which procedure gets called by examining
the code at the call site. The same is never true in ST. So there is
less manipulation, more "call by desire." It is hard to escape the
prejudices of our past, be they static typing or manipulating data.
[The new paradigm doesn't map onto the rest of the universe because the
perception of the universe changes.]
[(7) I know essentially nothing about ORBIT and/or SCHEME, and I
appreciate the reference. In general, I think that grafting ideas from
one system onto another diffuses them to the point where the new system
is worse than either of the originals. I am extremely wary of systems
that claim to be the best of everything, having the best of feature x,
the best of feature y, etc. I name as an example PL/I.]
[(8) If I may express my personal prejudices, it pleases me no end that
"actors" have been mentioned not at all in these messages. From my
reading of the papers on actors, it is my guess that the ideas were
not original with the authors, and even at that not understood. Too
bad "actor" is such a better word than "object," but history's clock
only goes forward.]
(9) Note that "message passing," like "object oriented," means
different things to different audiences. In the context of operating
systems "message passing" has quite a distinct meaning from the ST
sense. In this sense the operating system meaning (for message
passing) is the "correct" one, i.e., it was in use first and more
generally. Anyway, this makes it hard to evaluate paragraph synopses
like "Procedure calls vs. Message passing in Operating systems."
(10) This really should be up near the top. It is really too bad, in a
way, that Xerox has not released Smalltalk in all this time. As a
consolation, it hasn't been all bad -- the current ST is much better
than the original done way back in '72, and the language has not been
watered down by lots of imitations. [The new ST also has blocks,
whereas the previous ST did not, which idea I think is the greatest
since sliced bread.] So it hasn't been a total loss. But it is a
crime that Xerox hasn't *even yet* released ST (not counting selling it
on their expensive hardware). And I think your local Xerox rep
deserves to know how you feel. Remember, Xerox is a company and wants
to make a profit, if the demand (that's you) is high enough it will be
available.
[(11) There is a certain religious sense to the understanding of ST
people. And with it comes all the bad things, like dogma, as well as
the good things, like enlightenment and understanding. I hope I won't
be accused of heresy if I confess that I have done object oriented
programming in (horrors) FORTRAN. But (!) it was arduous, and the
language was strained, and furthermore there are some ST mechanisms
that just don't carry over -- if I wanted them in FORTRAN I'd just have
to give up. (The same goes for Ada and the rest.) Avoid the dogma,
but seek the religion. Smalltalk (or even Alan Kay) is not the answer
to the ultimate question, but ST is better than the competition. {And
please don't anyone even THINK of saying that the answer to the
ultimate question is 42.}]
(12) Examples illustrating ST's goodness are hard to come by because
locally ST doesn't look too different from other programming languages.
Five lines of ST will do about as much as five lines of Algol. But 20
pages of ST will do about as much as 100 pages of Algol. And the ratio
improves at the program gets bigger. If this is true (and in my
experience it is) then something about ST is different -- and better.
--
Anyone who has read this far won't mind indulging me while I relate a
personal anecdote. I remember quite clearly my early listenings to
Alan Kay, and my reactions to them. I thought he was a fanatic, albeit
a rather harmless fanatic, but a fanatic nonetheless. "Here's another
guy," I thought, "who has a favorite programming language." I'd run
into this kind before, of the APL variety, and LISP as well.
"Programming languages are all the same," I thought, "so what's the big
deal?" Imagine my surprise when, upon trying some of the ideas that
Alan hinted at, I found that some of what he had talked about made
sense and actually worked in practice. Gradually (and it took more
than a year) I was won over to the new point of view, along the way
re-discovering the neat things by seeing them work in my own code (I had
some help).
The point of this story is that there really is some gold in ST, but
it's not so easy to explain. And if you want to find out what that
gold is, you'll try some forays into ST after working on them in YFPL,
to see how they go -- it'll help if you get a ST'er to go along.
ST is not "it" -- ST has shortcomings, and flaws too. But ST is closer
to it than the other stuff that's out there.
(For everybody, but especially Don Chan -- I take myself not to be your
opponent, but rather your co-inquisitor. I seek not to contradict your
views, but to explain my own.)
And may I end,
Up with understanding!
Tim Rentschmwm@Okc-Unix (12/22/82)
From: Mike Meyer <mwm@Okc-Unix> watmath!mdrutenberg at Ucb-C70, decvax!genradbo!mitccc!rpk at Ucb-C70, decvax!utzoo!watmath!idhopper at Ucb-C70, menlo70!nsc!freund at Ucb-C70, majurski at Nbs-Vms, at UDel-Relay "I've even written object oriented code in FORTRAN..." BINGO! That statement reveals that the object/message paradigm isn't a property of a language, but a veiwpoint one uses for solving problems. As such, any solution using said pardigm can be used in any language. The thing that makes smalltalk different from `conventional' languages is that it directly supports the object/message pardigm, whereas other languages don't. Whether this paradigm is better than the "data abstraction" pardigm or not remains to be seen. [=~ I suspect that they both will get swallowed in a `generalized data abstraction' =-] The only point that Tim makes that would support object/message over data abstraction is the question of code reduction. But here he suffers from some fallacies. To use his example, if you had a package that dealt with integers using plus, minus, times and divide in CLU, then the package would adapt to any type with those operators, providing the declaration had been properly made, like so: zot = PROC [a, b: t] RETURNS (t) WHERE t HAS +, -, *, /: PROCTYPE [t, t] RETURNS (t) ; with no work at all. (Whether this implies that several copies of the object code exist in the compiled form is a different question; I don't know how CLU does it, and it only matters to me as a time/space tradeoff.) I still remain unconvinced that ST has any features that don't exist in other languages. There may not be any language with all of ST's features, but they all exist in other languages. It seems that this is actually a proper state of affairs for a field that is exploring a new tool (data abstraction). <mike jejones
RWS@Mit-Xx (12/27/82)
From: RWS at Mit-Xx (Robert W. Scheifler) I have refrained up till now, but it appears that people who appear to know very little about CLU persist in making mis-statements about it. No, Virginia, parameterized types in CLU do not result in non-linear code growth. (I'm not sure how it could be non-linear in ANY language, but...) The code for a parameterized module is shared by all of its instantiations, and the cost of an instantiation is typically 2 or 3 words, hardly an important consideration. And yes, Virginia, CLU does have procedures and iterators as first-class objects, so it is NOT always possible to determine at compile-time what routine is being called. None of this is to knock Smalltalk; it's an interesting language, and I wish I had a few years to spare to try programming in it. -------
drs@bnl.UUCP (David Robert Stampf) (08/24/84)
I've been hearing the word "Smalltalk" crop up in a lot of conversations lately - mostly in reference to what was done right with the Macintosh, or in Sci. Am. articles and in a few network articles. I'm trying to learn more about it, but I am struck by two strange facts: 1) The only articles written about it (Byte Aug. 81 & the smalltalk books) are by those people who wrote the system and one has to be a little wary of their opinions, and 2) There do not seem to be any commercially available systems running smalltalk. Since I have only recently started looking into this, I could be all wet. On the other hand, I'm having a lot of trouble getting any further info on it. I would appreciate any pointers and/or opinions that may be out there. I can be reached on the net (bnl!drs) or by phone 516-282-4148 or through the mails, Dave Stampf, Applied Mathematics Dept., Brookhaven Natl. Lab., Upton N.Y. 11973 Thanks <dave