🚀 go-pugleaf

In article <1661@ppi.UUCP> cox@ppi.UUCP (Brad Cox) writes:

>. . . But the improvement has always turned out to
>be arithmetic in impact.  The geometric improvements needed to bring our
>productivity in line with that of hardware engineers will not result from
>better programming languages, but by focusing our attention outside the
>language.  For example, by learning to program by producing and reusing
>components from large libraries of pre-tested Software-ICs. Yes, these
>libraries are hard to build, and expensive. But each well-tested,
>well-documented library component provides a geometrical improvement to the
>productivity of each of its users, and the improvement is open-ended, unlike
>the productivity enhancement of features that are hardwired into a new
>programming language.

I have three problems with this comment.  The one that bothers me the
most is the standard marketing ploy of renaming something from its
original lackluster name (library routine) to something that sounds
exciting, like "Software-IC".  Libraries have been around at least as
long as programming languages; and have contributed their share to the
productivity improvement, but they aren't the glorious path to
geometric improvement, or we would have been seeing geometric
improvements over the decades.

The second problem I have is the analogy which isn't stated here, but
is frequently drawn between "Software-IC" and hardware IC.  If you
follow the component industry at all, you know that the age of TTL
7000 series ICs has all but ended and almost all serious design now is
being done with semicustom or custom components.  You also know that
hardware designers have long bemoaned their lack of productivity,
although they refer to it as "design turn-around time", and they
haven't been seeing geometric improvements either.  Finally, you will
realize that the use of off the shelf components has alternated with
the use of special purpose design, going back at least as far as the
early sixties when the first published circuit books came out.

The third problem I have is with the loose claims of 'geometric' as
apposed to 'linear' improvements in productivity.  I've been reading
about programmer productivity for a long time, since Marvin Minsky
first claimed that advances in programming languages would do away
with the need for programmers within a decade (about thirty years ago)
through James Martin's claims to the same effect ten years ago until
now.  Nobody even knows what programmer productivity is, yet alone at
what kind of rates it has been improving at over the last three
decades.  Further, various kinds of programming have received
differing amounts of attention, and ease of accomplishing tasks in
some fields has improved greatly compared to others; for instance,
using 4GL query languages like SQL, it is now possible to
interactively ask for data in a few seconds which used to require
hours of programming plus days of backlog waiting for a programer to
become available to accomplish.

All in all, many things are important in the improvements that have
been achieved and none of them alone are going to give the ultimate
performance improvement.  Careful implementation of languages for
maximum expressiveness has improved productivity, as has understanding
the way programs should be laid out to aid understanding; but so have
faster machines, interactive operating systems, and decent debuggers.
It all needs to be worked on, and none of it is going to give us magic
productivity enhancements.