Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!caen.engin.umich.edu!ejd
From: ejd@caen.engin.umich.edu (Edward J Driscoll)
Newsgroups: comp.lang.c
Subject: Re: Portability and the Ivory Tower (was Re: Book on Microsoft C)
Message-ID: <4255794d.b11a@falcon.engin.umich.edu>
Date: 30 Mar 89 14:46:00 GMT
References: <754@oravax.UUCP> <225800146@uxe.cso.uiuc.edu> <9937@smoke.BRL.MIL> <424ce87c.b11a@falcon.engin.umich.edu> <28587@ucbvax.BERKELEY.EDU>
Reply-To: ejd@caen.engin.umich.edu (Edward J Driscoll)
Organization: caen
Lines: 31

As a disclaimer, I'll note that my original position was, and still
is, that there are reasons to strive for maximum portability in some
cases, but they have to be balanced against the costs.

Jim Shankland (jas.Ernie.Berkeley.EDU) proposes that even if
the users don't care about portability, vendors who don't are
bound to finish last.

I agree with you in some cases, but how would your statement
apply to, say, the Macintosh family of computers?  While
the meat of the program could be written portably, I would
think that the entire interface would necessarily be system-dependent.
If you took portability to the extreme here, let's say by
making the thing entirely keyboard oriented, you'd be
laughed out of the market.  People who own Macs PAID for
the specific features of that machine, and they expect the
software they use to exploit them.  If you're willing to
disregard a market of this size, you've got more money than
I do!  

I certainly don't claim that people should program like
hackers.  I do claim that even a disciplined programmer
can be justified in using machine-specific code -- potentially
even large bodies of it, such as the entire user-interface
mechanism -- and therefore has every right to know about
the specific capabilities of his machine.

-- 
Ed Driscoll
The University of Michigan
ejd@caen.engin.umich.edu