Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!mit-eddie!uw-beaver!fluke!mce
From: mce@tc.fluke.COM (Brian McElhinney)
Newsgroups: comp.software-eng
Subject: Re: Speed versus whatever (vi versus Nisus; Unix versus Macintosh)
Message-ID: <1991Jan4.225943.540@tc.fluke.COM>
Date: 4 Jan 91 22:59:43 GMT
References: <470@eiffel.UUCP> <19413@yunexus.YorkU.CA> <5966@stpstn.UUCP>
Organization: Software of the Mist
Lines: 47

In article <5966@stpstn.UUCP> cox@stpstn.UUCP (Brad Cox) writes:
>
>Observation #1: Unix tools, such as vi, are remarkable (IMHO) for 
>	(a) their speed (adequate) 
>	(b) their user interface (terrible).
>
>Observation #2: Macintosh tools such as Nisus (a text editor with comparable
>	regular expression capability) are remarkable for 
>	(a) their speed (terrible)
>	(b) their user interface (adequate).
> [...]
>
>My question: Why does this pattern seem to recur consistently between
>comparable Macintosh versus Unix applications?

First and foremost there are fundamental user interface differences (textual
vs graphical).  Graphical user interfaces are much harder.  They take a
significant percentage of your development resources (time, personnel,
testing, etc).  You never have infinite development resources, so something
has to give.

The UNIX marketplace has fewer end users, and those users tend to be very
technical.  In the Macintosh market this subset of users corresponds to the
so-called "power" users, and is a small percentage of the total customer base.
Non-technical users are less sensitive to performance, and are less likely to
switch if higher-performance tools become available.  They will switch if
"needed" features are in your product.  So what do you make the higher
priority?  Getting features working, or making features work fast?  [This is
also, incidently, what leads to the "kitchen sink" effect so often seen in
Macintosh applications]

There are some technical differences, and though no one of them causes a
problem, they do add up.  Instead of byte stream files, MacOS has structured
files (data and resource forks).  Things that are hard-coded in UNIX programs
are often dynamically loaded resources in Macintosh programs.  The Mac does
not have virtual memory, instead using small heaps allocated via
doubly-indirected pointers (so heap compaction is a problem).  The Mac
community expects binary compatibility across OS versions and new hardware
platforms.  The Mac does not have memory protection, which makes debugging
harder.  What I'm getting at is that there may be more complexity for the
"same" job, leading to a problem similar to that of user interfaces: if it is
hard it takes more effort, and you always have limits on your development
resources.
 
 
Brian McElhinney		  "There is no magic.  There is only knowledge,
mce@tc.fluke.com		   more or less hidden"           --Gene Wolfe