Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!mit-eddie!uw-beaver!uw-june!bnfb
From: bnfb@uw-june.UUCP (Bjorn Freeman-Benson)
Newsgroups: comp.lang.misc
Subject: software ICs vs. libraries
Message-ID: <3349@uw-june.UUCP>
Date: Wed, 21-Oct-87 17:01:58 EDT
Article-I.D.: uw-june.3349
Posted: Wed Oct 21 17:01:58 1987
Date-Received: Sat, 24-Oct-87 06:39:13 EDT
References: <3405@ece-csc.UUCP> <638@its63b.ed.ac.uk> <1811@watcgl.waterloo.edu> <1549@pdn.UUCP> <1661@ppi.UUCP> <3179@ames.arpa>
Reply-To: bnfb@uw-june.UUCP (Bjorn Freeman-Benson)
Organization: U of Washington, Computer Science, Seattle
Lines: 29

First, a disclaimer: I don't use Object-C or C++, I don't know their
terminology, and I don't own any stock in either company.

>...exciting, like "Software-IC".  Libraries have been around at least as
>long as programming languages; ...

I think that there is a difference between libraries and something
more general, say "software-ICs".  The libraries I have seen are
collections of routines that someone found useful, and then put
together for mass consumption.  A good example of this is the
Macintosh Toolbox routines: they are powerful, but they are
hopelessly complex, and have a questionable programmer improvement.

A "software-IC" would seem to be a more thourghly thought out, better
designed, unit of software that could be used for multiple purposes.
In other words, a design team would set out to design a software-IC,
rather than extracting little pieces of code from their final
product to place in a library.  The subclassing ability of Smalltalk
and its kin are a start.

>...7000 series ICs has all but ended and almost all serious design now is
>being done with semicustom or custom components.

However, one must consider that current software technology is at
the level of individual transistors and resistors, and that we could
use the step up to "7000 series ICs".  After that, custom and
semi-custom would be great.

				Bjorn N. Freeman-Benson