Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!amdcad!cae780!tektronix!reed!bart
From: bart@reed.UUCP (Bart Massey)
Newsgroups: comp.lang.misc,comp.software-eng
Subject: Re: Software Technology is NOT Primitive (LONG, of course :-)
Message-ID: <7597@reed.UUCP>
Date: Sat, 31-Oct-87 11:58:41 EST
Article-I.D.: reed.7597
Posted: Sat Oct 31 11:58:41 1987
Date-Received: Thu, 5-Nov-87 03:34:44 EST
References: <3405@ece-csc.UUCP> <638@its63b.ed.ac.uk>
Reply-To: bart@reed.UUCP (Bart Massey)
Distribution: comp
Organization: Reed College, Portland OR
Lines: 57
Xref: mnetor comp.lang.misc:840 comp.software-eng:46

Probably I shouldn't add to this discussion, since it seems to be basically
going nowhere.  But I couldn't resist putting in my 2-cents-worth...

The arguments being presented for primitive software technology, 
as I have interpreted them, are these:
   
   Hardware designs have gotten more general-purpose and reusable in
   the past 20 years.   Software designs haven't.
   
   Hardware has gotten more much more efficient wrt speed and size in the
   past 20 years.  Software has gotten less efficient in that time.

Seems to me that the most reasonable lines of counter-argument runs
like this:

    Hardware costs money to manufacture.  If a sufficient number of copies
    of a design are sold (as with ICs) the manufacturing costs swamp the
    design and distribution costs.  This isn't true of software.  An infinite
    number of copies may be manufactured for free, and design costs are
    generally the constraining factor.  Thus, much more design effort is put
    into a typical hardware project.  On the other hand, many more software
    designs are actually implemented.  This is why hardware is used for
    general-purpose tasks, and software for specific problems.  The
    major task of the hardware designer has been to do general-purpose tasks
    faster and smaller, at which s/he has succeeded admirably.  The major
    task of the software designer has been to do a wide variety of specific
    tasks, at which s/he has also suceeded admirably.

    It just isn't true that our knowledge about how to do small, fast
    software has *decreased*.  Anyone who believes this should look at the
    original 64K Apple Macintosh ROMs.  Certainly, the coding there was in
    the same range of size/speed efficiency as the 4K Tiny Basic I used 10
    years ago.  And yet there was 16 times as much of it.  What has happened
    is that run-time efficiency has been traded for design-time efficiency.
    At Reed College, there is an abundance of machines, and a major
    shortage of programmers.  Thus, we try to use the programmers
    efficiently, not the machines.  Contrary to some people's claims, we
    believe that there's no way to optimize both simultaneously.  Always
    choosing the people optimization makes good economic sense for us.
    And for most people.

In summary, 20 years ago, you couldn't do a lot of things, period.  The
things you did do, you did almost solely in hardware.  Today, a mixture
of general-purpose hardware and specific-purpose software is being used
to do a lot of new things more cheaply and easily.  

My personal opinion based on the above evaluation is that name-calling
software technology "primitive" or "20 years out of date" is a little silly.
Suggesting specific ways that either sofware or hardware technology could be
improved is not.  The recent discussions in this group about the extent to
which compiler syntax can reasonably be modified at run time, about the ways
in which languages can be optimized to make code-sharing easier without
significantly increasing design expense, about the costs and benefits of OO
programming, seem much more relevant and useful.  Let's take up those
topics and drop this one.

						Bart