Path: utzoo!attcan!uunet!hsi!stpstn!cox
From: cox@stpstn.UUCP (Brad Cox)
Newsgroups: comp.object
Subject: Re: code blocks (aka closures)
Message-ID: <5339@stpstn.UUCP>
Date: 6 Jul 90 21:50:13 GMT
References: <12396@june.cs.washington.edu> <1112@carol.fwi.uva.nl> <5319@stpstn.UUCP> <11013@alice.UUCP>
Reply-To: cox@stpstn.UUCP (Brad Cox)
Organization: Stepstone
Lines: 73

In article <11013@alice.UUCP> bs@alice.UUCP (Bjarne Stroustrup) writes:
>
>Software is not hardware. Further, there is little reason to believe
>that software is analogous to hardware in any strong and useful sense;
>had it been, we probably wouldn't have had a `software crisis.' Looking
>to hardware for solutions to software problems (except by using better
>hardware) is likely to be highly misleading and causes much confusion.

No, but software people are people, different in no important respect
from those who built the pyramids, fly to the moon, build computer
hardware, and repair their plumbing.  We're missing a great opportunity
and remain stuck in the software crisis so long as we continue to
emphasize the uniqueness of our materials at the expense of well-proven
organizational prinicples such as division of labor, interchangeability,
and the commercial incentives required to make any large-scale cooperative
approach work, be it for hardware components, pyramid-building, or
software development.

>I will happily agree that C++ isn't going to `solve the software crisis;'
>and hurry to add that neither is any other language/environment.

The silver bullet is not a technology, but a paradigm shift. It is a
*cultural* change, not a technological one, in precisely the sense that
Copernicus, Kepler and others forged a silver bullet for the astronomy
crisis. It was not some supercomputer or programming language for computing
epicycles more rapidly. It was a shift in that culture's viewpoint in 
which the astronomers realized that they (and the earth) were not the 
center of the universe, but a cog in a larger wheel circling round the sun.

>The problems with software are fundamental. They are primarily caused by
>increasing ambition on the part of individuals and organizations: As long
>as we are seeing rapid progress many of us will be working at the hairy
>edge of our abilities and of the capabilities of our tools. I hope and
>expect that this trend will continue. Our tools are quite adequate for
>solving yesterday's problems - meaning that we have made significant
>progress - but those are not the problems we are facing today or want
>to face tomorrow.

Software does have fundamental problems arising from fundamental differences
with tangible objects.  But the transition from the Age of Manufacturing to
the Age of Information provides a nearly infinite incentive for us to solve
them. I'm desperately afraid that we won't, that we'll stick with the old
paradigm that brought us the software crisis, and let our competition find 
the solution unopposed.

There *is* a silver bullet, and I believe that our competitors in the far
east are using it already. Even though they're far behind in software
technology today, they're *already* doing one to two orders of magnitude
than we are in software defect rates (some companies report 0.008 defects
per KSLOC, vs 1-3 defects/KSLOC typical, .01-.1 for critical software,
according to McGarry and Basili figures). Simplifying greatly, the
difference seems to be that they're focusing on the *product* whereas 
we're focusing on the *process*; which is one way of phrasing the paradigm
shift I'm referring to.

>The software crisis has been with us for at least 25 years and will probably
>be with us for at least another 25. Whether C++ or Objective C or something
>else provides and/or will provide the greatest amount of relief from our
>current problems and leverage for our new projects is for the users to decide.

What we, as software's present producers, believe is totally incidental.
It is the *consumers* of our products who's opinion governs the outcome.
It will be totally immaterial who developed them or whether they're coded
in assembler, Cobol, Ada, C++, or Objective-C.

I do admit to more than passing interest that we who view ourselves
as 'the software development community' not discover that our consumers
have done to us what they did to an automobile industry that proved
more attuned to its own interests, rather than its consumers'.
-- 

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