Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!hellgate.utah.edu!uplherc!esunix!rtrosper
From: rtrosper@esunix.UUCP (Robert Trosper)
Newsgroups: comp.object
Subject: Re: Overused metaphors - Software ICs, etc.
Summary: Not only overused, but older than Objective-C and still more
	 trouble than it's worth
Keywords: Software ICs
Message-ID: <2088@esunix.UUCP>
Date: 1 Aug 90 22:08:49 GMT
References: <23915@nigel.udel.EDU>
Organization: Evans & Sutherland, Salt Lake City, Utah
Lines: 66



Ah well, what goes around comes around again. We tried using this
"Software IC" concept as a metaphor for a CAD system implemented in
Mainsail back in '85 or '86. The system is still marketed by HP,
but that's neither here nor there. In any case, each object actually
had a required number of entry points (or methods, or messages, or
whatever you like), the same for each class to take the concept
of standardization further than is usually done.

So we used this software IC analogy to try to persuade the rest of the
world that they could indeed use our system as a development base.
Just pledge on your honor to provide these entry points and your
object will plug right on in.

There is a long, tangled and not necessarily pretty history here,
but the bottom line is that the concept never sold, and not because
of technical reasons. Part of it was due to the dreaded NIH
syndrome, part of it to the non-mainstream nature of the idea,
and part of it to the lack of adequate documentation we provided
because of lack of staff and lack of committment.

The other problem is that the analogy breaks down at so many levels
that it is really more useful as a marketing bleat (sorry, Brad) than
an actual metaphor for use by techies.

F'r instance - hardware IC's are specified down to the last n'th by a well
defined set of parameters including but not limited to :

truth tables
voltage
current
number and function of pins
fan-in and out
capacitance
packaging

Let's try the analog process here - software IC's are specified by

return values for a given input
Language perhaps for voltage and current? Operating system? Any ideas?
number and function of methods (procedures)
concurrency - or re-entrance?
Does it run slower when interfaced to certain other software IC's?
Again, perhaps language - like are they in a procedure library
or a method library - C or Fortran or Cobol ....

So - let's talk a little about that interface problem BETWEEN software
IC's - out there in the hardware world the interface parameters are not
neglible but within a family of implementation there is pretty
good standardization. If you can cobble up a +5V and a +12 -12 power
supply you can build a whole bunch of stuff. And the current ranges,
and most importantly the input or output states in digital logic will
be pretty simple (high, low, perhaps high impedance, or God forbid
unknown when you don't want it). Not quite so clean to feed the
"output" of one sofware IC to another - integer, real, string, boolean
to another expecting....

The best case might be a standard set of messages, but that standard
set can grow pretty large in a hurry once you're beyond the bounds
of simple logic.

Well - not to beat a dying horse. Let the Software IC myth go quietly
into it's own good night. Useless things all go there anyway.

				Robert Trosper