Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!brunix!iris.brown.edu!jcg
From: jcg@iris.brown.edu (James Grandy)
Newsgroups: comp.object
Subject: Re: The shape of software
Message-ID: <44669@brunix.UUCP>
Date: 10 Jul 90 01:48:50 GMT
Sender: news@brunix.UUCP
Organization: IRIS, Brown University
Lines: 57
References:<1638@dinl.mmc.UUCP> <1690@kunivv1.sci.kun.nl> <5239@stpstn.UUCP> <55443@microsoft.UUCP> <5281@stpstn.UUCP> <5286@stpstn.UUCP> <3814@kim> <1278@media01.UUCP> <5337@stpstn.UUCP> <1174@mtunq.ATT.COM>

In article <1174@mtunq.ATT.COM> psrc@mtunq.ATT.COM (Paul S. R. Chisholm) 
writes:
> In article <5337@stpstn.UUCP> cox@stpstn.UUCP (Brad Cox) writes:
> > But I absolutely do not agree that software's complexity has to be
> > greater than that of hardware. Admittedly, it certainly is today,
> > but isn't that precisely because we still invent and implement
> > everything from first principles, rather than by relying on and
> > supporting a marketplace in interchangeable software components?
> 
> Dr. Cox suggests (here and elsewhere) that we need a paradigm shift,
> from software *design* to software *construction*.  (Dr. Cox, if I'm
> wrong, please don't hesitate to correct me, by posting or personal
> e-mail [but note that I've moved slightly].)  Personally, I think that
> having a base of less primitive "primitives" would be nice; and, as Dr.
> Meyer does, I'd like to never implement a linked list or a table
> look-up again for as long as I live.
> 
> But I don't like Dr. Cox's analogy of electrical components (at various
> scales); that is, I don't think it applies to the problems he, or Dr. 
Meyer,
> or Dr. Stroustrup, hope to solve.  The design of electronic (hardware)
> systems works because there are standard components at *all* scales,
> and customer components at a greater variety of scales can be created
> and integrated.  Dr. Cox's efforts with Objective-C are aimed at
> supporting the creation (and dissemination) of software components at a
> higher level that C or C++.  He may be successful, and that would be
> nice; but it's still a single scale.

I couldnt agree more, but I would go further and say that the Software-IC 
analogy is
inappropriate for a large part of what OO design is good for: designing 
generic structures
that are intended for more than just reuse, but also extension. Most 
really useful OO systems
are designed to be reused in a dynamic way. The best example is an 
application framework,
which may export functionality, but which also exports a generic 
structural definition which
is meant to help the designer frame her own problem. An application 
framework includes
generic classes corresponding to the common elements of all applications, 
but more than that
it defines communication protocols and constraints between those elements. 
Reusing this
structure involves more than plugging in a component and connecting it to 
other components,
it means extending a generic structural definition to fit a particular 
need. I cannot think of
a good analogy for this process; but still the Software-IC analogy rings 
hollow to me.



James Grandy
(401) 862-1610                jcg@iris.brown.edu
IRIS Brown University
Box 1946, Providence, RI 02912