Path: utzoo!attcan!uunet!dino!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!m.cs.uiuc.edu!p.cs.uiuc.edu!gillies
From: gillies@p.cs.uiuc.edu
Newsgroups: comp.arch
Subject: Re: Speed Kills (long)
Message-ID: <76700236@p.cs.uiuc.edu>
Date: 13 Jun 90 06:01:00 GMT
References: <447@garth.UUCP>
Lines: 40
Nf-ID: #R:garth.UUCP:447:p.cs.uiuc.edu:76700236:000:2190
Nf-From: p.cs.uiuc.edu!gillies    Jun 13 01:01:00 1990


Martin Fouts has some good points, but I'm going to be a jerk and add
my 2 cents anyway.

First, "most software vendors spend all their time porting code".
This is a GOOD thing.  It makes all computers run (essentially) the
same software, reducing learning time.  Since the market for portable
code in n times larger than the market for machine-dependent code, you
may invest n times more money in a clean design, additional features,
and providing for posterity, by allowing the software to escape from
orphan machines.

Now some of the time porting code is due to overdiversity in UNIX.
UNIX should take a lesson from the IBM PC.  PC vendors have the good
sense to test new PC's for compliance (hardware, BIOS) with the PC
"standard" (whole companies have been established to provide testing
services and consulting).  This could be done with UNIX, and it would
save a lot of useless porting time.

>    As the rate of introduction and obscelences of new generations of
>    hardware increases the development of truely new software
>    functionality will decrease, dropping to zero.  [I claim that this
>    is an observation.  There hasn't been any "new" software since the
>    middle 70s.]

New [I/O] hardware always begets new software, and there is no
slowdown in the introduction of I/O hardware.  I don't know what you
mean by "new software", are you talking about productivity tools
[visicalc, 1979?].  I would say that a large part of the 1980's was
spent learning how to integrate software at a level that was
unthinkable in the 1970's.  Programs in the 1970's never talked to
each other in nontrivial ways.  Imagine starting Mathematica on
one of 20+ different machines, displaying some 3-D plots on the
screen, rotating the viewpoint with the mouse [talking about the
macintosh now], copy the picture to a conference paper in a WYSWYG
word processor, and print it out on a postscript printer.  Six
different programs have just talked to each other {math kernel, math
user interface, window system, word processor, mac printing manager,
postscript engine} using 3 separate protocols {math kernel, PICT,
postscript} and (upto) 3 separate machines {math kernel, mac, printer}.