[net.micro] Smalltalk, the Universe, and Everything

donald (02/03/83)

Once more into the fray...
Re: "RICHARD HPS (on ERCC DEC-10) <okeefe.r.a.@edxa>" and his article
    "It's only Smalltalk, don't sacrifice me to Moloch"

I must admit I didn't expect quite so much vehemence in his belated
reply to my reply to his article of December 9 (1982).
I thought I used a jocular (if slightly sarcastic) tone in my article.
While I admit to attacking his article, I certainly didn't intend for
my reply to be construed as a personal attack on him and it mystifies
me that he took it that way.
In fact, I was under the impression that I was addressing a
group, since he stated that "this a collation of some local messages"
in his first article.

I am sorry for any personal distress I may have caused him, but I
honestly don't think that I mounted a "violent verbal attack" on him.
I attacked his arguments, yes, but I thought that was fair enough.
I never called him a liar (as he implied) and I didn't suggest
that he had any personal faults.
An article questioning MY opinions in a tone similar to the one I used
wouldn't greatly upset me, but then maybe I'm thick-skinned.

"A bon chat, bon rat" is my motto.  Can't we be friends?
(By the way, you can call me just plain "Don"; "Dr Chan" is pompous and
 inapplicable, and plain "Chan" sounds Victorian)

Now on to the real stuff.

Look, we can go on forever dissecting each other's quotes, so I'll
try to strip away the peripheral issues and get to the point.
Otherwise this rebuttal would be ridiculously long (it already is!)

1)  The term "object orientation" has been thrown around in these
    discussions again and again.  What does it mean?  I've read
    several articles praising OOP, but they never do get right down
    to defining OOP.  It's not "data abstraction".  It's not
    "encapsulation".  It's not programming using "modules".
    Tell me, what do YOU mean when you say OOP?  I have my opinion
    of what it means; I doubt if it means the same thing to you.

2)  Richard refers me to the Smalltalk manual several times in his
    diatribe (implying I can't read, I suppose).  I and several of
    my colleagues would be delighted to get a real specification.
    All we have is that stupid BYTE issue and rumours that the Adele
    Goldberg book on Smalltalk is going to be published soon.
    There are no widely accessible papers known to us that describe
    ST in any more formal terms than the BYTE propaganda.

3)  Given what I think OOP means, it is obvious that Smalltalk is
    not THE OOP language, though many previous submitters strongly
    implied this.  Smalltalk is one of a number of languages which
    supports data abstraction/modular programming/whatever you want
    to call it.  Whether ST is "better" at it than the rest remains
    to be seen.  ST certainly didn't originate OOP, at least OOP as
    I understand it.  ST certainly encouraged OOP as a buzzword.

    Is ST a "good" language?  I never said anything either way.  I
    merely criticized some aspects of the language design (lack of
    clearly defined scoping, emphasis on dynamic binding, potential
    inefficiency, etc.)
    I NOT attacking ST as a language; it looks interesting to me.
    I AM attacking the conceptual folderol and fog that surround ST,
    the OOP cult, and the ST for children cult.

    The objects/messages doubletalk in ST is unnecessary.  ST "messages"
    are absolutely equivalent to routine calls.  A message in ST is a
    synchronous transfer of control with the caller halting until the
    callee returns.  A routine call by another name.  The terminology
    initially confused me because I thought of Hoare's CSP, but once
    you penetrate the jargon things become mundane.
    You say in Logo that you send messages to the turtle; well I'll
    call the turtle procedure.  As for the claims that objects/message
    is easier for novices and children to grasp, I'll wait for some
    hard evidence from cognitive psychologists.

4)  Re: efficiency.  Obviously any language can be made as efficient
    as you want, given enough architectural support.  This includes
    LISP, APL, ST, what-have-you.  All your arguments boil down to
    this.  But there will always be hierarchies of architectures, and
    the simpler ones will multiply and inherit the earth.
    You have the attitude of "I can microcode ST on a VAX and get good
    performance".  Well, I can get the C compiler to emit VAX micro-
    code and get even better performance.

    You say ST is compiled.  In what sense do you mean this?  It cer-
    tainly isn't compiled in the same sense as, say, C.  ST is pre-
    processed (compiled if you wish) into intermediate code which is
    interpreted.  I think ST is far too dynamic and "type-loose" to
    be compiled in the traditional sense (I may be wrong?)

    I am puzzled as to what you consider "efficient".  You praise
    the efficiency of Algol 68C and you think ThingLab was fast.
    I put up the Cambridge 68C on an IBM 370 some years back and
    ran some programs.  The compiler was slower than the PL/I optimizer.
    Moreover, my graphics colleagues saw the ThingLab film and thought
    it was SLOW.

5)  I see confusing a programmming language with its environment as
    dangerous. A PL is a notation for expressing an algorithm. A
    programming environment aids in entering this notation, main-
    taining, and debugging it.  Both are important, but quite distinct.
    A great support environment doesn't make FORTRAN a good PL.
    Conversely, APL is a neat PL with a horrible built-in
    line editor and terrible tools for workspace manipulation.

    The ST environment may be great, but it has nothing per se to do
    with ST the PL.  Your implication that the ST environment could
    not have been programmed in FORTRAN or that the Lisp Machine
    could not have been built without the flavours is false-- remember
    Turing Machines.  Of course it'd be more difficult in FORTRAN...

    Confusing the syntax and semantics of a PL is inexcusable.  It is
    a sign of poor faculties for abstraction.  Most people hate COBOL
    for its wordiness, but COBOL isn't really THAT bad.  It's actually
    quite livable if you have a macro preprocessor.
    If you can penetrate the cloak of oddness surrounding ST it would
    probably seem quite mundane.

END OF LINE (as MCP said).

					Don Chan