[comp.software-eng] Software-IC Catalog

cox@stpstn.UUCP (Brad Cox) (07/04/90)

In article <JGYLCCX@xavier.swarthmore.edu> gessel@cs.swarthmore.edu (Daniel Mark Gessel) writes:
>Is the NeXT community ready for a publication which would list specifications
>of objects for sale (or for free), and possibly have discussions of some
>standard interfaces for kinds of objects on top of NeXT Step?

That I would encourage such thought should be obvious to all concerned. But
I'd encourage you to think about pushing it much further than an ordinary
paper or electronic catalog.

Paper catalogs are sufficient for tangible components, like silicon chips
and plumbing supplies. But for intangible components like Software-ICs(TM)
I think that we must apply some technology to make intangibles observable.

A simple way of doing this (which soon leads to fascinating implications
regarding how the semantics of natural languages are established, with
direct implications to specification/testing languages) 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.

I'm not talking about anything high-tech here, folks. All that I mean by
'test procedure' is a C subroutine with a bunch of assert() statements
inside to determine whether a putative implementation provided as an argument
behaves as the test procedure expects.  Compliance of Stepstone's class
libraries to their abstract specifications are tested in exactly this 
fashion, and I've been trying to convince our development people that
these test procedures, and the specifications they embody, should be
released independently of Software-ICs themselves.
-- 

Brad Cox; cox@stepstone.com; CI$ 71230,647; 203 426 1875
The Stepstone Corporation; 75 Glen Road; Sandy Hook CT 06482

gessel@cs.swarthmore.edu (Daniel Mark Gessel) (07/05/90)

In <5320@stpstn.UUCP> cox@stpstn.UUCP (Brad Cox) writes:

>In article <JGYLCCX@xavier.swarthmore.edu> gessel@cs.swarthmore.edu (Daniel Mark Gessel) writes:
>>Is the NeXT community ready for a publication which would list specifications
>>of objects for sale (or for free), and possibly have discussions of some
>>standard interfaces for kinds of objects on top of NeXT Step?

>That I would encourage such thought should be obvious to all concerned. But
>I'd encourage you to think about pushing it much further than an ordinary
>paper or electronic catalog.

>Paper catalogs are sufficient for tangible components, like silicon chips
>and plumbing supplies. But for intangible components like Software-ICs(TM)
>I think that we must apply some technology to make intangibles observable.

>A simple way of doing this (which soon leads to fascinating implications
>regarding how the semantics of natural languages are established, with
>direct implications to specification/testing languages) 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.
. . .
>Brad Cox; cox@stepstone.com; CI$ 71230,647; 203 426 1875
>The Stepstone Corporation; 75 Glen Road; Sandy Hook CT 06482


Do you suggest that this library should be defined along with the standard
interface, and published along with (either in paper or electronically, or
both)? Or, should the "catalog" be a set of programs which actually exhibits
the compliance?

That is, I don't see why anything more than an oridinary paper or electronic
catalog is required.

What you are suggesting, it seems to me, is that specifications should also
require some method of "proof" of compliance along with the specification 
itself. I think this is a great idea, and I think it should be incorporated 
into any good specification.

It has been suggested that the NeXT User's Journal might be a good place to
publish specifications, although I would expect that they would need to be
developed by other organizations. Possibly a newsgroup or mailing list.

Standards will come about, I expect, as interfaces are defined for commercial
libraries that are marketed. There is the possibility (and danger of bad)
de facto standards, dependent on libraries which make it out early and
are used widely, although copyright issues may make for problems there
(another reason to create standards fairly early in the game).

Standards will be developed, by one means or another, but I think taking
the situation in hand directly will help to make standard interfaces
better from the beginning.

Dan
--
Internet: gessel@cs.swarthmore.edu         
UUCP: {bpa,cbmvax}!swatsun!gessel

scotth@boulder.Colorado.EDU (Scott Henninger) (07/06/90)

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

mitchell@community-chest.uucp (George Mitchell) (07/07/90)

In article <23113@boulder.Colorado.EDU> scotth@boulder.Colorado.EDU
(Scott Henninger) wrote:
` - 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.]

I suspect that part of the problem here may come from too literal and
narrow interpretation of the term "software IC".  It is my impression
that the term was chosen to reflect the advancement of engineering from
basic materials (metals/bits) to elementary components (resistors/
assembly language words) to (circuit boards/3GL words) to (SSI ICs/
FORTRAN libraries) to (MSI ICs/shrinkwrap COTS) to (LSI ICs/?) ....

If we were to look at the hardware portion of some system outside the
domain of software platforms, we should find examples of higher level
abstraction than that of the S/W component.  For example, the hardware
in a stereo system should include some standard complex components (not
custom parts used only in this particular system) in the controls,
display, amplifiers, power supplies, etc.  I would expect the same to be
true in any mass produced system today.

The individuals designing and implementing those systems are not working
in all domains (as some S/W professionals do) but specialize in audio,
RF communications, power, and even Brad Cox's favorite, plumbing.  The
problem with S/W then is not that we deal with so many domains, but
that we do not adequately discriminate among the many domains.
--
George Mitchell, MITRE, MS Z676, 7525 Colshire Dr, McLean, VA  22102
email: gmitchel@mitre.org  [alt: mitchell@community-chest.mitre.org]
vmail: 703/883-6029         FAX: 703/883-5519