Path: utzoo!attcan!uunet!husc6!uwvax!tank!uxc!uxc.cso.uiuc.edu!m.cs.uiuc.edu!p.cs.uiuc.edu!johnson
From: johnson@p.cs.uiuc.edu
Newsgroups: comp.lang.c++
Subject: Re: Current O-O Languages as Software E
Message-ID: <77300017@p.cs.uiuc.edu>
Date: 21 Nov 88 18:17:00 GMT
References: <5155@thorin.cs.unc.edu>
Lines: 89
Nf-ID: #R:thorin.cs.unc.edu:5155:p.cs.uiuc.edu:77300017:000:4759
Nf-From: p.cs.uiuc.edu!johnson    Nov 21 12:17:00 1988


Let me make one thing clear: I am a Smalltalk programmer.  Smalltalk is
my favorite language and I consider C++ definitely inferior.  I have been
defending C++ (and will continue in this article) so I wanted to make
that clear.  I think that my comments are reasonably representative of
the Smalltalk community.

Smalltalk certainly has a more dynamic programming environment than C++,
but the language itself is not much more dynamic.  If you are trying to
send a message to an object that does not understand it then you will
get a run-time error.  If you want a procedure to work with any object
that understands Foo and Fee then you make an abstract class FooFeeable
and use multiple inheritance to make every class understand it that might
be an argument to that procedure.  (In my opinion this is the main reason
for multiple inheritance.)  Very few Smalltalk programs take advantage
of the fact that they can generate code on the fly.  Smalltalk programs
do sometimes check the class of objects.  This is often a sign of poor
design, but try defining a general equality procedure without it.  This
is the way I can see in which C++ is significantly less dynamic than
Smalltalk.  The major problem with C++ is that it is too much like C,
but then this is its major strength, too.

As I said before, it is the programing environment of Smalltalk that is
more dynamic than that of C++, not the languages themselves.  The
languages certainly have an impact on the environments.  Smalltalk makes
it easy to write browsers, debuggers, inspectors, and the like.  However,
given enough work, it should be possible to do it for C++.

I commented...
>>Smalltalk certainly does not force anyone to use existing classes.  
>>People use them because they are well designed. 

Dr. James Coggins commented...
>That's a correct Party Line response that is meaningless in practice.
>This is exactly the kind of conventional wisdom that should be
>examined more carefully.  Each of these classes in the Smalltalk
>architecture comes with an implementation bound up with it. Part of
>the price you pay for using Smalltalk is the tacit adoption of those
>implementations along with the nice architecture.

The important feature of the Collection hierarchy is the protocol,
i.e. do:, select:, collect:, add:, etc.  I usually start off a program
using OrderedCollection, Dictionary or Set.  Once I figure out what I
am doing I often discover that these are too inefficient.  Then I will
write a specialized class to implement the exact kind of Collection
that I need.  The advantage of using a standard protocol is that
  1) readers of my program will know what the new data structure does
     without reading the code
  2) I don't design an efficient data structure until I know that I need it
  3) I might luck out and be able to reuse the specialized class.
Most times that I use a Collection its efficiency is unimportant, so
I never have to reconsider what I've done.

I said
>>I claim that no good designer is going to find a class hierarchy a 
>>straight-jacket, because if it is not working then it will be changed.

Dr. James Coggins said
>I am a good designer (only a fair implementer, though), and I found the 
>Smalltalk hierarchy restricting when I needed to implement large objects
>like images and 3-D graphics models.  I wasted time trying to fit what
>I needed into what Smalltalk provided. 

What you said was that you found an application where the particular
Smalltalk implementations were not what you needed.  So build another one!
Maybe you were saying that the abstractions provided by Collection were
inappropriate for your problem.  This is a more fundamental design error,
and one that is not the fault of Collection.  In other words, you should
have realized that you needed a different abstraction.  Of course,
hind-sight is 20/20, the problem is how to get hind-sight.

I said
>>There should be much, much, much more reuse in software systems.  We don't
>>keep inventing new abstractions for arithmetic, why should we be doing it
>>for everything else?  

Dr. James Coggins said
>Because there is no "implementation" for arithmetic, of course!
>Computer stuff is bound to implementations requiring engineering
>decisions concerning tradeoffs of time/space, compilation
>effort/run-time support effort, etc.

Note that I said "abstractions" not code.  The abstractions are much
more important than the code.  If you made a mistake in the implementation
of a class then you can just write another one.  If you designed the
interface wrong then you will not only have to reimplement the class
but every client of the class.  Every language that I have used gives
the same definition for + on integers.  I want the same thing to be
true of sets.