Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!cmcl2!beta!hc!ames!orville.nas.nasa.gov!fouts
From: fouts@orville.nas.nasa.gov (Marty Fouts)
Newsgroups: comp.lang.smalltalk
Subject: Re: software ICs (was Re: C++ vs Object
Message-ID: <3235@ames.arpa>
Date: Tue, 27-Oct-87 12:33:01 EST
Article-I.D.: ames.3235
Posted: Tue Oct 27 12:33:01 1987
Date-Received: Thu, 29-Oct-87 22:55:30 EST
References: <3179@ames.arpa> <80500019@uiucdcsp>
Sender: usenet@ames.arpa
Reply-To: fouts@orville.nas.nasa.gov.UUCP (Marty Fouts)
Organization: NASA Ames Research Center, Mountain View, CA
Lines: 44

In article <80500019@uiucdcsp> johnson@uiucdcsp.cs.uiuc.edu writes:
>
>Saying that class libraries are like subroutine libraries is a gross
>misstatement.  O-o programming provides the benefits of code skeletons,
>reuseable abstract designs, and families of compatible components.
>It is possible to simulate all these things in conventional languages,
>of course, but nobody does.  That is what makes o-o programming unique.
>

The aspect of reusable source code isn't usually one of the reasons
given for the "sofware IC" analogy.  Even if it were, I disagree with
your strong statement.  I frequently reuse code skeletons; especially
on the event driven model required by most window systems.  In fact, I
suspect that "nobody does" is far too strong a statement, and that
many people do in this environment.  I also use the model when doing
device drivers, and Berkeley style network deamons.  "Plagiarize from
the best" has long been my motto.

>Smalltalk programmers can be very productive when they are working in
>an area for which there is a lot of prebuilt classes, such as in
>user interfaces.  When they have to stop to invent new abstract classes
>there productivity goes down to the level of other languages.  It is
>the library of well-designed abstractions that is important, not the
>language.

Right.  And how many user interface does the programming world need (;-)
I agree that there is anecedotal evidence for some zowie performance
improvements in certain areas.  The same is true for Fourth Generation
Languages (4GL) when doing data base queries; scientific subroutine
libraries when doing tractable problems; parser generators when
doing toy compilers; etc.  In the case of Smalltalk programmers
modifying classes, it is the library that is important.  In the case
of 4GL programmers writing queries, it is.  In my usual mode, the
debugger is the biggest productivity tool.

Of course, as you have pointed out, in this case the library is
important, and that is independent of the language.  As we all know,
'object oriented' is a language feature, so it can not be responsible
for the utility of the library. . . (;-)

Depending on which part of the elephant you are standing under, you
can make a claim for some feature as the solutions to the elephant's
problems, but you can't claim to solve them all, because it's a big
elephant.