okeefe.r.a.@edxa (01/19/83)
From: RICHARD HPS (on ERCC DEC-10) <okeefe.r.a.@edxa>
--------
-- Warning: this message is only of interest to people who have been
following the Smalltalk debate.
-- The "KEY POINT"s may be of general interest.
A while back I sent a message to this mailing list about Smalltalk.
I meant it to be a courteous and informative contribution, and was
careful to indicate at the beginning just what my qualifications
for writing on the subject were (not much, but non-zero). And then
along comes Chan and mounts a violent verbal attack on me.
I readily admit that my message was a bit waffly, and when I got over
the shock (Chan's message wasn't quite a blow in the face, but it made
a pretty good substitute) I found that I hadn't explained some things
clearly enough. I'm not going to bother much in this note either,
because if Don Chan takes the trouble to read a Smalltalk manual he'll
find much better answers there. (By the way, I *have* read Hoare's CSP
paper. And half a dozen later papers by other authors developing the
idea.)
When I sit down at a keyboard, I find my language becoming condemnatory
and vitriolic. This may be because a computer can't faint. I know that
I have this fault, and I make strong efforts to control it. (Not always
successfully. I have twice received well justified rebukes.) This
confession is intended to sweeten my rebuke to Dr Chan: "The tone of your
letter was quite unjustified. How would *you* like to receive a letter
like that?" I do not suppose that we are unusual in sharing this fault;
may I suggest as a general principle that messages in this list should
avoid violent language and any criticism of people? I'm not suggesting
that we should be ever-so polite and pat everybody on the back and say
how marvellous everything is, not in the least. Surely we can discuss
micros, personal computers, programming languages, or whatever, without
starting feuds!
Back to Smalltalk.
"Smalltalk adherents are beginning to show signs akin to religious mania/
... Smalltalk acolytes identify "object orientation" ... with their
God, Smalltalk."
If this is directed at me, it is wide of the mark. The reason I wrote my
message is that I thought Smalltalk and its designers were being criticised
unjustly. I haven't the slightest desire to use Smalltalk. I would much
rather use Lisp Machine Lisp (which supports object-oriented programming
in much the same way that Smalltalk does). I *do* use Algol 68C (which
is amazingly efficient; good work Cambridge (UK)!) and Simula, also Lisp.
If someone offered me a machine running Smalltalk, I'd grab it, mainly
because I would love to draw pretty pictures and play nice tunes.
"Messages defaulting to a (sic) the super(*)class of a class reminds
me of PL/I's attitude towards identifier declarations."
It shouldn't. It should remind you of dynamic binding in Lisp, APL,
file lookup on TOPS-10, the way Ada picks things out of packages...
"Ada overloading is not that tricky (my opinion), and it does have
the sorta nice feature of being statically checkable (albeit this
makes it a lot less flexible than Smalltalk's overloading; what
price compilation?)
But Smalltalk IS compiled. Ada is currently on its third attempt to
define overloading (if you want to bet that the new manual will be the
final definitive one and that no major problems will be found in the
scope/overloading rules, I'll *joyfully* take your money) so I guess
the implementors *are* finding it tricky. I agree fully that overloading
in a compiled language can be very clean indeed, Edinburgh ML does it
particularly well. The important thing in that paragraph was my claim
that "Smalltalk has an extremely coherent model of overloading". It is
very easy to knock Ada. And justly. But I couldn't do as good a job
of language design. I certainly don't want to deny that Ada has many
advantages over Smalltalk. The fact remains that Ada is (deliberately) a
much more complicated language than Smalltalk. It also has different goals.
KEY POINT:
in order to criticise any programming language, you must have read
the defining documents, you must know what it is meant to be used
for, and you must know what it is meant to be better than. Where
possible, you should also have used it, or at least discussed it
with somebody who has.
"That depends on how your generic type mechanism works. Certainly in
CLU or Alphard it doesn't work the way you're thinking of."
Point taken. As the rather horrible language (generic type, faugh!)
was meant to indicate, I was thinking of Ada. Had I been thinking of
the Algol 68 family, I'd have mentioned modals, other languages, maybe
"type parameters", another language "keys". I think the best approach
to "generic types" is in the CLEAR specification language, where their
analogues are called "theory parameters". Smalltalk isn't the only
programming language with its own names for things.
"My F-----N subprogram doesn't have to use all of its parameters
either."
I do apologise for explaining so badly. A F-N subprogram doesn't get
to decide how many parameters it has, whether they are evaluated, or
anything at all. Once it has had a parameter thrust upon it, it can
pretend it never happened. The CALLER gets to decide everything else.
I meant to convey that a Smalltalk method can decide how many arguments
it has, what order the come in, &c. In short, the caller and the callee
(metaphorically) *negotiate* what form the parameters take this time,
with no commitment that it will ever look like that again. I repeat
the comment from my old message: I do not know if Smalltalk-80 is still
like this. MacLisp and its descendents come pretty close to this, and
some versions of Logo. I was not claiming it as a virtue, nor that it
was unique. If you want a counter-example that comes closer to the point,
an argument record in MESA or the VAX machine comes pretty close to being
"a genuine object", certainly it is a thing you can copy and point to.
READ THE SMALLTALK MANUAL.
"I'll admit that Smalltalk does things like that with a lot less
syntactic ugliness, but there is NO FUNDAMENTAL ADVANTAGE
possessed by Smalltalk."
KEY POINT:
A programming language is not the class of algorithms which can
be programmed in it. Seemingly trivial syntactic differences
can have large effects on error rates and understanding.
In short, doing something with less syntactic ugliness IS a fundamental
advantage. Programs don't write themselves. I agree that a really
competent programmer familiar with a lot of different languages (I have
written programs in 20+ languages, not counting dialects, and know about
10 more I could use if I had access to them) sees past the syntax, but
there are an awful lot of people who refuse to leave BASIC. To the majority
of programmers the syntax and the language (COBOL) are indistinguishable.
I'm sure Dr Chan can write object-oriented programs in anything that takes
his fancy. I'm sure he is an extremely good programmer, who has learned how
to learn new programming languages very fast. That's really where we disagree,
I think; because we can distinguish ideas from languages, he may not see the
peculiar value of a language which concentrates on a few ideas. (In
Smalltalk, they are OOP and dynamic binding.)
KEY POINT:
Programming languages which concentrate on a few basic ideas
are valuable. They are not panaceas. Embedding such a language
in a conventional language is nullifies the benefits of both.
Why do I say they are valuable? Because when we try to write programs
using those ideas, but lacking our favourite tools, we discover new uses
for these ideas. APL taught us an awful lot about what you can do with
arrays. If APL had had records and lists as well, we might never have
known what you can do without them. BASIC taught us that interactive
debugging can be a good substitute for static analysis, provided there is
a clean "machine state" you can debug from. LISP taught us that you can
do amazing things with lists, functions, and associations. BCPL taught
us that you can write decent programs without types at all. (And also
that you'd rather not.) Prolog is teaching us what can and cannot be
done with pattern-matching and backtracking. (Icon isn't, because it
mixes in other ways of doing things.) After enough experience has been
gained, such a language becomes obsolete, because the ideas are well
enough understood to be employed in other languages.
I think OOP has matured enough in Smalltalk's greenhouse to be allowed
into the world outside. I do not think we would have learned as much
without Smalltalk.
"Yeah, I think we used to call it a "heap". .... "
Again, this misses the point. I can manage a heap in C without any pain.
The point was not that a passive data structure can hang around. OS6
used that idea, and it was written in BCPL! The point is that an *active*
object can hang around, complete with environment. This also happens in
Simula, CLU, Conniver, Interlisp, any Lisp with closures, ... In fact
the nearest analogue to a Smalltalk object IS a closure. A Smalltalk
object is not just a record (though it contains one), it is basically a
frame. As for garbage collection,
KEY POINT:
if a language is designed with garbage collection in mind, there
is no reason to be frightened of GC.
GC is another of those features that can't really be retrofitted to Fortran.
I regularly run Simula programs, and if GC takes 10% of the time I am
astonished. I'll gladly pay that price for a decent language. This message
was edited using an EMACS-like editor written in a Lisp-like language. I
know it GCs, but I can never tell when it is happening. {I could ask it to
tell me, but why should I care?}
"Ex cathedra. Some novices like BASIC too. ... Interesting CLAIMS these
Smalltalk people make. Shall we back them up with something more than
pontifical statements? Also, what people understand this?"
Don't EVER tell someone he's a liar. Ask him to produce evidence.
I have never had anything to do with Xerox. I have never been to PARC.
I ***have*** seen a videotape showing some programs *running* that were
written by 12-year olds. I have seen on the same tape some of those
children changing their programs. I have talked with someone from PARC
who had been involved in teaching Smalltalk to children. Ok, my evidence
is hearsay. But I trust the people I heard it from. Furthermore,
Edinburgh has been working on LOGO for years, and children manage to cope
with Terak Logo. Even to like it. Generally, they master the graphics
first. How do you do graphics in Logo? You send messages to an object
(the turtle). The success of Logo is corroborative evidence that Smalltalk
probably is mastered easily.
"[Me] Smalltalk is not just a programming language, but a programming
environment."
"[Chan] So what? 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 F-N if you really want".
I don't know that I believe this. Certainly most of the Smalltalk system
is written in Smalltalk (though some of it used to be in BCPL). The only
similar environments are InterLisp-D and Lisp Machine Lisp. According to
the Lisp machine documentation, the Lisp machine graphics system contains
a million characters of Lisp code and "COULD NOT HAVE BEEN WRITTEN WITHOUT
THE FLAVOUR SYSTEM". (The flavour system is the LM's analogue of classes
and message.) When you have written such a system in F-N, I will believe
you. At the moment, all the evidence I am aware of is on the other side.
KEY POINT:
the only evidence that proves that something can easily be written
in a given language is a working program.
KEY POINT:
if there is only one implementation of a language, distinctions
between the language and the environment mostly misleading.
Pointless too, unless you're developing one of the two.
I would not willingly do without Fortran. Access to the NAG library, or
LINPACK, or FUNPACK, ... is worth the price of sticking with a language
that was well designed for conditions that no longer exist. (Though I
can call the NAG routines from Simula.) The DoD evidently think that the
environment is as important as the language (APSE). I love C, but much
of that affection really belongs to UNIX. In fact a good environment
(system) costs a lost more to build than the compiler.
"[Me] Multiple inheritance subclasses are NOT a simple idea."
"[Chan] Seems your .. statement contradicts your earlier claims."
Sorry. Different languages. Multiple inheritance subclasses are
actually a late addition to the language. When I said how simple
Smalltalk was, I wasn't thinking of this new feature. I have no idea
how well children cope with it, and should have said so.
"I am not confusing Simula "virtual attributes" with anything,
mainly because I never mentioned them before. I think you are
talking about the Simula "class concatenation" mechanism, and
I assure you, sir, that I am familiar with it..."
No, I was **not** talking about prefixing. If you don't know what
"virtual" means, you don't understand prefixing either.
KEY POINT:
to improve your understanding of OOP, get hold of "Simula
Begin (Birtwhistle)", or the Simula Common Base manual, or
the Simula manual for your computer (Dec-10, Dec-20, IBMs,
UNIVACs, ICL2900s...) and READ IT.
"You're lumping Simula with Smalltalk. A decidedly ODD thing
to do."
Not at all. I was talking about chronological order. Also, less
than odd, since Smalltalk is *based* on Simula (according to its
designers).
"<Expleteive deleted>. The good gentleman 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. ... [He then points out that the
Dorado is dearer than the VAX]"
KEY POINT:
other things are never equal.
KEY POINT:
the price of a computer increases with cost of development and
decreases with expected market penetration.
The idea I was attacking is that Lisp or Smalltalk is inherently
inefficient. Pointing out that Franz Lisp (which I use, though nowhere
nearly as often as I use C) isn't particularly fast misses the point.
I did NOT claim that EVERY Lisp system is efficient. In fact I have
heard rumours that Franz Lisp is the slowest of the compiled Lisps
running under VAX/Unix. I do not know if they are true, but it casts
doubt on the validity of Chan's comparison. The C compiler could do a
lot better, too, so his comparison might still be fair. But let's look
at the two arguments a little more clearly:
[Me] several companies have built machines to run unconventional
languages. On *these* machines, those languages are about
as efficient as conventional languages on conventional machines.
{I apologise for the intemperate adjective "antiquated".}
[Chan] one Lisp system is less efficient than one C system on a
machine that was designed to run C-like languages.
Chan is so far from refuting my argument that I will supplement his
comment with some figures:
(defun fib (n)
(cond ((< n 2) 1) (t (+ (fib (- n 1)) (fib (- n 2)) )) ))
runs at around 2500 calls to fib/second. {I had done this test before
reading his message, by the way.}
The current expense of Dorados compared with VAXes is beside the point.
The development costs were probably less, but the expected market is a
lot smaller, which is sufficient to explain the price. The Lisp
Machine LM1 is already on sale and costs around $80k. Give me the
Smalltalk sources, a VAX 780, and a microcoding manual, and pay me for a
year, and THEN we'll see whether Smalltalk is inefficient on VAXen.
As the Dorado runs Smalltalk, Interlisp, BCPL, and Mesa, it doesn't
sound as though Smalltalk requires anything dramatically special from
the hardware. I would expect maybe a factor of 4 degradation going from
the Dorado to the VAX. Of course the VAX doesn't have that great big
bit-mapped screen.
"I have seen video tapes of Smalltalk programs running on a Dorado.
They ran SLOW."
There is a question of interpretation here. The Dorado screen is
roughly 2k across by 1k down. Assume 1bit/pixel. A graphics program
*might* be recomputing the screen for every redisplay, which is
2Mbit/30th?sec = 60Mbit/sec = roughly 8Mbyte/sec. I can make a VAX 750
do interesting things at 20kbyte/sec, so a 780 ought to reach say 40kbyte/sec.
Any Smalltalk demonstration tape is likely to concentrate on graphics
programs doing interesting things, so the speed of the programs you saw
MAY have been dominated by data transfer rates. I can't tell because I
don't know what you saw. I have seen a videotape of Alan Borning's
Thinglab in action. It is not primarily concerned with graphics (though
it uses graphics well), and it runs quite fast.
KEY POINT:
when comparing machines or languages, make sure you are doing
the same thing in both.
KEY POINT:
the most important thing about a programming language is that
its users should understand it.
The second most important thing is that they should be right.
--------