Path: utzoo!attcan!uunet!hsi!stpstn!cox
From: cox@stpstn.UUCP (Brad Cox)
Newsgroups: comp.object
Subject: Re: Objective-C review
Message-ID: <5286@stpstn.UUCP>
Date: 28 Jun 90 15:54:01 GMT
References: <1638@dinl.mmc.UUCP> <1690@kunivv1.sci.kun.nl> <5239@stpstn.UUCP> <55443@microsoft.UUCP> <5281@stpstn.UUCP>
Reply-To: cox@stpstn.UUCP (Brad Cox)
Organization: Stepstone
Lines: 62

In article <5281@stpstn.UUCP> andyk@stpstn.UUCP (Andy Klapper) writes:
>In article <55443@microsoft.UUCP> jimad@microsoft.UUCP (Jim ADCOCK) writes:
>
>>  ... A number of things on what he feels Brad Cox is saying when he talks
>>  about different levels of integration.
>
>I think you missed the point.

My point is really just common sense, but does involve a paradigm shift to
understand it. What's a paradigm shift? It is what Copernicus did when he 
moved the center of the universe from the earth to the sun. The silver bullet 
for the astronomy/calendar crisis of that era was not a technology. It was
a paradigm shift, which moved mankind from the center of the universe out 
towards the periphery.

The silver bullet for the software crisis is a paradigm shift that moves
the center of the software universe from *processes* to *products*, from
*producers* to *consumers*, from *languages* to *components*; from us as
programmers to our customers. Gasp, yes! That's actually what I said. Moving 
us programmers out of God's eye at the center of the universe to out there
at the periphery, revolving around our customers interests, not our own.

The terrifying thing to me is that I'm afraid that we're going to find this
so troubling, that we'll overlook that this is actually why the Japanese
are managing to build software right now, using extremely 'poor' software
development technologies by our standards, and are routinely beating us
on quality and time-to-market by factors of *one to two orders of magnitude*.

To see what I mean, notice the number of standards bodies screwing around
with standard processes (Ada, C++, 2167, Cleanroom), and the absence of
standards bodies defining standard *products* of these processes; i.e.
a standard Stack, Queue, Customer, Kahlman filter object, etc.

Notice the lack of a marketplace for such objects, comparable to the plumbing
supply marketplace.  And notice the lack of a commonly understood vocabulary for
discussing and understanding different software architectural levels, 
comparable to the understandings that underlie tangible products.
With a bolt, for example, we immediately understand that it will be used 
as a binding mechanism for something larger, like a tractor. And we 
immediately understand that the bolt is composed of something smaller, 
probably built by somebody else, such as a steel rod, which is in turn
built by somebody else, a steel refinery, which is a customer for steel
ore provided by somebody else. The bolt is produced by, and is consumed
within, a marketplace; a vehicle for distributing complexity over time
and space, which has no robust counterpart in software, where everything
tends to be built from first principles 'for efficiency'.

None of this is hard to understand, other than to accept that the common
sense mechanisms that apply in the tangible domain of everyday experience
can, *should*, and *must* be allowed to apply in the abstract/concrete
swamp of software development. 

Better standard *processes* will never eliminate the software crisis. But
standard *products* might.  This is precisely the difference between
Objective-C and C++. Objective-C is a name for an environment of standard
products, called Software ICs. C++ is the name for yet another of a long
line of standard *processes*, which will have the same impact on the
software crisis as its predecessors; which is none at all.
-- 

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