Path: utzoo!attcan!uunet!hsi!stpstn!cox
From: cox@stpstn.UUCP (Brad Cox)
Newsgroups: comp.software-eng
Subject: Re: Reuse and Abstraction (was: reu
Message-ID: <5131@stpstn.UUCP>
Date: 31 May 90 07:59:23 GMT
References: <4979@stpstn.UUCP   <102100009@p.cs.uiuc.edu   <80449@tut.cis.ohio-state.edu   <19614@duke.cs.duke.edu   <80685@tut.cis.ohio-state.edu   <19760@duke.cs.duke.edu   <80884@tut.cis.ohio-state.edu   <5122@stpstn.UUCP <19855@duke.cs.duke.edu>
Reply-To: cox@stpstn.UUCP (Brad Cox)
Organization: Stepstone
Lines: 144

In article <19855@duke.cs.duke.edu> crm@romeo.UUCP (Charlie Martin) writes:
>  The Smalltalk environment is one; the Objective-C System-building Environment
>  is another.
>... These >require that the systems be realized with only
>components from a particular "catalogue".  This is a problem that occurs
>over and over again with reuse by composition from a collection of spare
>parts: you can't merge parts from two catalogues.  Thus if one company's
>catalogue doesn't have what is needed, you have no other options.

The IEEE article argues that we should begin thinking of object-oriented
(and older) technologies, not as fancier ways of building things from
scratch, but modularity/binding technologies. And just as other domains
have become quite adept at deploying diverse modularity/binding technologies
in common (i.e. sheep herding, shearing, spinning, weaving, sewing, 
zippers/buttons/bows can all be viewed as modularity/binding technologies
at different, but thoroughly compatible levels), we need to stop viewing each
technology as a panacea (i.e. Ada vs Smalltalk, or Objective-C vs C++), but 
as a tool relevant to a specific level of the software producer/consumer
hierarchy, and usually irrelevant at others. For example, the fact that
C++ provides outstanding gate/block-level integration facilities is
relevant to those whose work demands a better C, and irrelevant to those
whose work demands a chip-level (Software-IC) modularity/binding technology.

In other words, think of Objective-C, not as a *language*, but an environment
that supports a modularity/binding technology analogous to socketed pluggable 
hardware ICs.  There are many ways of building chips that can plug into these
sockets, and many vendors who are doing so (many of whose work has been bought
repackaged, and is now being distributed by Stepstone). But as long as
the components abide by the socket standard, they do not need not be built
via Objective-C. They can be built in plain C, or C++, or even Cobol,
and Objective-C components can be used via any of these. Its only a matter
of abiding by the low-level socket standard...which brings me right
back to where we started, the need for specification/testing languages
capable of describing, and then verifying compliance to, these standards.

>Also, my experience with both Smalltalk and Objective-C (admittedly
>limited) has been that to use the libraries of classes available, one
>had to buy into a lot of architectural assumptions that might or moght
>not fit what was needed, e.g., garbage-collection or interpretive codes.
>(At a little higher level, things like model-view-controller.)  To use
>any other architectural assumption meant backing up and rebuilding the
>universe from primitives.

Software's abstract/concrete hybrid nature is simultaneously our curse, and
our blessing (in that it guarantees us higher salaries than those who work
in more concrete domains, like flipping burgers). But apart from this
fundamental difference, I'd argue that other domains experience exactly
the same kind of complications, but have grown thoroughly adept at mastering
them. For example, you might want to take advantage of a hardware store's 
new inventory in copper plumbing pipes, but in a house with existing iron
pipes, you'd face corrosion problems; a preexisting architectural decision.
But somehow mature industries like plumbing always seem to provide a way
of getting around incompatible architectures; i.e. by selling an suitable
adaptor. I grant you, we're far more immature an industry than plumbers,
and off-the-shelf adaptors are still rare and raise cultural objections,
such as thinking of such adaptors as kludges.

>  Re: academic types, please see Ralph London's formal specification (in Z,
>  as I recall) of the Smalltalk Set class.
>
>The Oxford people are an interesting case, because (for reasons I don't
>completely understand) you apparently get some sort of rewards for doing
>things that wouldn't be considered quite "research" over here.  Perhaps
>because if Tony Hoare and Robin Milner say it's good enough, no one
>would dare to object.  Or perhaps it has to do with the Oxford name on
>the box.

I get your point re: Oxford, but Ralph London is an American thru and thru.
Works at Tektronix Labs, I think in Beaverton. Wish I had a reference to
his article to give you, but it was beautiful work, and insightful into the
difficulty of applying a mathematical approach to well-understood piece
of concrete engineering effort. 

>In any case, this is good stuff.  There ought to be more of it.  Why
>isn't there?  Noting that there is one example doesn't make much of a
>case for it being a hot research area.

Because during any major paradigm shift, the conservatives *radically*
outnumber the revolutionaries. That is why the market for a better C is so
much larger than the market for off-the-shelf software components. That's why
the market for traditional academic topics is so much larger than the market
for what we're discussing. In choosing sides for yourself, be sure to keep 
priorities straight...believe me, the revolutionary life is not all that 
it's cracked up to be.

>I'm with you here, and I'm looking forward to seeing the paper you've
>mentioned.  Another part of this is the apparent insensitivity of the
>marketplace to issues of quality: you can't sell more correct, but you
>can sell faster or earlier availability.   (Even Stepstone is selling
>rapid prototyping not correct codes.)

Without disagreeing with you one bit that quality costs money that the
market can be reluctant to pay, be aware that although Stepstone's code 
started out as rapid prototypes (like any other code), after seven years of
improving it is considerably better than that. The same is true of Smalltalk,
except they've been at it longer (twenty years or so).  As to *correct*, 
we're back to the original topic...what can it even *mean* if I say Stepstone's 
*putative* Set is an *actual* implementation of some abstract definition of Set,
other than to point to our a of gauges that at least does verify compliance 
within some stated tolerance. Since we *have* gone so far as to define what 
we mean by *correct*, I'd claim (sticking neck waaay out) that our code is 
not mere rapid prototype, but also *correct* within a defined sense of 
"correctness". I'd be surprised if we'll ever be truly able to exceed that
level, based on the fact that other mature disciplines (bridge builders,
plumbers, space shuttles, etc) have never managed to.

>  Please take it from one who *knows*...
>Since I'm at an academic site, I think I need to throw in the obligatory
>complaint about the implication that we at academic sites don't *know*.
>Don't fall for that, lots of us at .edu sites have done substantial
>real-world work.

Point well taken. Was only trying to emphasize arrows in my own back; not to
imply anything about yours.

>But let's continue the war analogy a little further.  Outside of a few
>special cases (the British vs the Zulu, say) neither the weapons nor the
>desirability of the goal has really affected the way the war came out.
>What does seem to make a difference is the right tactics.

Didn't catch your meaning of British vs Zulu...do you mean like American vs
Vietnamese?

Not only tactice...also strategies, and determination, and a whole bunch of
other stuff. Weapons count too.

>So far, we seem to be agreeing that the right tactics are more "formal"
>or rigorous in some sense.  What I wish we could do is measure the
>effect of those tactics.

At the risk of picking this to death, what I'm actually saying is a lot
less crisp than that, which is best summed up with "Use the right tool for
the job". Sometimes the right tool is "formal" or "rigorous", but more often 
it is not. I've been exploring non-rigorous avenues (OOT, software components 
marketplaces) for quite some time, and seem to have made some headway there. 
But rather than getting hung up on the accomplishments, tooting horns re:
"the virtues of OOT", I've begun digging into where these approaches leave
holes, and backup approaches to fill them.


-- 

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