Xref: utzoo comp.sys.next:6872 comp.software-eng:3870
Path: utzoo!attcan!uunet!aplcen!uakari.primate.wisc.edu!zaphod.mps.ohio-state.edu!sunybcs!boulder!scotth
From: scotth@boulder.Colorado.EDU (Scott Henninger)
Newsgroups: comp.sys.next,comp.software-eng
Subject: Re: Software-IC Catalog
Keywords: Objects Standards Publication Objective-C
Message-ID: <23113@boulder.Colorado.EDU>
Date: 5 Jul 90 17:45:36 GMT
References: <JGYLCCX@xavier.swarthmore.edu> <5320@stpstn.UUCP>
Sender: news@boulder.Colorado.EDU
Reply-To: scotth@boulder.Colorado.EDU (Scott Henninger)
Organization: University of Colorado at Boulder
Lines: 63

In Article 3966, cox@stpstn.UUCP (Brad Cox) writes:

> A simple way of doing this [...] is to also publish, as an
> precondition to the catalog, a library of executable gauges (test
> procedures) that detect whether a Software-IC that purports to comply
> with some abstract specification, does in fact do so within some
> tolerance for non-compliance.

If only the life of a programmer were so simple.  I think the basic
problem is the omnipresent hardware metaphor.  It simply doesn't work
for software for (at least) the following reasons:

 - Hardware IC's operate within a single domain, software works in many

 - This causes the number of potential software IC's to escalate,
   causing a scaling problem in retrieving useful, usable IC's

Let's face it, hardware IC's work so well in part because they are used
to create only one kind of machine - essentially a general platform for
software.  [Note: Once you get into specialized hardware or analog
circuitry, you're working at a level of abstraction about equal to
programming languages, with similar problems.]  This isn't to say that
hardware designers have it easy, just that their problems are of a
different nature, one that is subjected to the fairly well-known and
constrained specifications imposed by microcoding needs (not to mention
the very well-known problems of circuitry).  Software, on the other
hand, works in a wide open world of concepts, often subjected to the
whims of end-users and clients.

One reason hardware catalogs work well is because the number of concepts
(uprocessor, I/O, etc) involved can be learned in a few years with some
experience.  The catalog serves to remind the designer of the specific
details, but the initial retrieval of concepts is largely performed
internally by the designer.  Scaling the number of concepts from the
hundreds to the tens of thousands (or more) won't work because human
capacity begins to reach its limitations.  A programmer working in the
domain of accounting is not going to know about the concepts in medical
applications simply because he is struggling to retain and acquire the
specialized knowledge needed for programming in the domain of
accounting.  And if he doesn't know the concepts, then the catalog is of
dubious utility.

This isn't to say that software catalogs wouldn't be useful or aren't
necessary for software reuse.  Its just that one must be aware of the
problem of scaling from the relatively constrained world of hardware to
the much more open world of software applications.  The bottom line is
that if one were to argue for software catalogs for specific domains,
allowing these domains to evolve by cataloging past solutions, then
they might be on to something.  But it should be recognized that having
a catalog isn't enough - people have to understand what's in the catalog
and where to begin looking.

Another problem software catalogs don't address well is that novel
design problems, of which there are many, aren't treated.  I would agree
that programmers have an inflated idea of the number of novel algorithms
they have designed, and that many algorithms and programs can be derived
from existing ones, but the question still remains: How do we support
solving the truly problematic design problems - the ones that haven't
been tried before?


-- Scott
   scotth@boulder.colorado.edu