Path: utzoo!attcan!uunet!husc6!uwvax!tank!nic.MR.NET!xanth!mcnc!thorin!retina!coggins
From: coggins@retina.cs.unc.edu (Dr. James Coggins)
Newsgroups: comp.lang.c++
Subject: Re: Current O-O Languages as Software E
Message-ID: <5503@thorin.cs.unc.edu>
Date: 23 Nov 88 04:20:37 GMT
References: <5155@thorin.cs.unc.edu> <77300017@p.cs.uiuc.edu>
Sender: news@thorin.cs.unc.edu
Reply-To: coggins@cs.unc.edu (Dr. James Coggins)
Organization: University Of North Carolina, Chapel Hill
Lines: 76

In article <77300017@p.cs.uiuc.edu> johnson@p.cs.uiuc.edu writes:
>
>As I said before, it is the programing environment of Smalltalk that is
>more dynamic than that of C++, not the languages themselves. 

Certainly this is true, but the language differences are still significant.
Errors Smalltalk picks up at run-time are compile-time errors in C++.
Bjarne Stroustrup recently argued in this newsgroup that early detection 
of errors is a principal advantage of C++ over Smalltalk for large-scale 
real software development.

[I'm deleting a good description of how to do rapid prototyping in Smalltalk.]

>What you said was that you found an application where the particular
>Smalltalk implementations were not what you needed.  So build another one!

I did. In C++.  Where the nature of the implementation was under my control.
Where I could fit the implementation to the abstraction instead of the
other way around.

>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.

I saw very quickly that Collection was not what I wanted and neither
was anything else in the Smalltalk world. (I said I'm a GOOD
designer!) It was disappointing to spend the time to learn the
Smalltalk model and find it inappropriate.  

> 
>johnson 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 (this is amended somewhat from the original) 
>Because there is no "implementation" for arithmetic, of course!  
>As soon as abstractions are made computer-usable, they are bound to
>implementations requiring engineering decisions concerning
>tradeoffs of time/space, compilation effort/run-time support effort,
>etc.
We have no mechanism available for specifying the nature of
abstractions that is not bound up with some implementation. 
For rapid prototyping, something like Smalltalk provides default
implementations, and you correctly described how those should be
modified in response to real needs as a project develops.

But at some point you need to build the Product, not a prototype of
it.  From the prototype you might know how you would like the user
interface to work, what critical algorithms are required, and you
might know something about performance problems.  But if you have
expressed the prototype in a system of Smalltalk classes that is not a
good fit between the essential abstractions and implementations
thereof, then the prototype tells you less about the Product than you
thought. 

This all boils down to something I wrote once called "Object-Oriented
Design Considered Harmful".  The most negative effect of OOD is that
it encourages bottom-up design.  Top-down design remains the best
approach (though bottom-up realization makes lots of sense a lot of
the time). Huge class libraries might save some coding and typing
time, but we haven't even begun to fabricate the "silver bullet" until
we find an effective mechanism for divorcing the architecture of a
system from its implementation. Then we might be able to adopt and
reuse architectures like large class hierarchies conforming to
different conceptions of diverse problem domains while also
interchanging implementations. Then maybe the "software IC market"
will be less of a pipe dream and we will really be able to "Let the
implementation conform to the conception."

---------------------------------------------------------------------
Dr. James M. Coggins          coggins@cs.unc.edu
Computer Science Department   
UNC-Chapel Hill               Member of the Dreamer Fithp
Chapel Hill, NC 27514-3175    
---------------------------------------------------------------------