Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!haven!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn )
Newsgroups: comp.lang.c
Subject: Re: Portability and the Ivory Tower (was Re: Book on Microsoft C)
Message-ID: <10004@smoke.BRL.MIL>
Date: 7 Apr 89 22:39:29 GMT
References: <754@oravax.UUCP> <225800146@uxe.cso.uiuc.edu> <9937@smoke.BRL.MIL> <8131@chinet.chi.il.us> <4278ff03.b11a@falcon.engin.umich.edu>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 30

In article <4278ff03.b11a@falcon.engin.umich.edu> ejd@caen.engin.umich.edu (Edward J Driscoll) writes:
>I claim that those reasons typically have something to do with making
>maximum use of the user's hardware, or using it in as efficient a manner
>as possible.

I think we need to be careful to reject such demands for enslavement to
the computer.  Almost anyone who has a serious need for computation will
have to have a particular application or applications available, and the
vast majority of the content of such an application lies in its software.
From that viewpoint, the hardware supports the software, not vice-versa.
One should therefore acquire the appropriate hardware to support the
applications that the users require.  This may include spiffy graphics
interfaces or it may not.  Taking the opposite approach leads to flashy
software/hardware combos that don't meet user needs.

For example, we acquired Silicon Graphics high-performance real-time 3-D
color graphics workstations to support our interactive solid modeling
system; however, the software works with a variety of hardware so we can
choose whatever best fits the need.  Not every application needs such
high-powered (and rather expensive) hardware.

For another example, the Locanthi & Pike "Blit" terminal and its
commercial descendants (AT&T 5620 and 630) was developed to support an
effective interface to the existing UNIX environment.  The UNIX tools
themselves remained blissfully unaware of the new hardware being used
to maximally exploit them.

By the way, I agree with the comment that this discussion doesn't belong
in the C newsgroup.  If I knew where it did belong, I'd direct follow-ups
there..