Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site utcsrgv.UUCP
Path: utzoo!utcsrgv!info-mac
From: info-mac@utcsrgv.UUCP (info-mac)
Newsgroups: ont.micro.mac
Subject: Re: Slow and Impossible
Message-ID: <4455@utcsrgv.UUCP>
Date: Sat, 2-Jun-84 01:43:39 EDT
Article-I.D.: utcsrgv.4455
Posted: Sat Jun  2 01:43:39 1984
Date-Received: Sat, 2-Jun-84 01:51:08 EDT
Sender: peterr@utcsrgv.UUCP
Organization: CSRG, University of Toronto
Lines: 37

Date: Thu, 31 May 84 16:09:18 pdt
From: uw-beaver!hamachi%ucbkim@Berkeley (Gordon Hamachi)
To: wert.pa@Xerox.ARPA
Subject: Re: Slow and Impossible
Cc: info-mac@SUMEX-AIM.ARPA

    From: wert.pa@XEROX.ARPA
    Subject: Re: Slow and Impossible
    Cc: info-mac@SUMEX-AIM.ARPA

What you said sounds right on the mark.  If Apple didn't anticipate
more than 50 files per disk, don't you think they were being
pretty short sighted? Is this another problem that will go away
with 512K Macintoshes? It is a serious limitation for many
users who were planning to do real work on the Macintosh.

It seems likely that the Macintosh design team did NOT overlooked
this problem.  They were probably forced to rushed the 1.0 finder
out the door before it was ready.  Is the problem fixed in later
a version?

The Macintosh software seems to be full of simplifying assumptions
that make the machine look good for small examples, but fall somewhat
short for large examples.  Besides the finder, there is the
length limitation on MacWrite.  A preliminary version of MacDraw
(as demo-ed by its author at the West Coast Computer Fair) is
incredibly slow scrolling when there are large spline curves, even
when they are off the screen.

Don't get me wrong.  The Apple Macintosh design team has done so
many things RIGHT.  Conceptually, it is magnificent.  It would be a
pity to find out that a ``real'' system takes more memory, a faster
disk, or algorithms they decided not to use.

				-Gordon