Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!sunybcs!bingvaxu!leah!uwmcsd1!bbn!husc6!cmcl2!phri!roy
From: roy@phri.UUCP
Newsgroups: comp.sys.mac
Subject: Re: Mac programmers shortage?
Message-ID: <2916@phri.UUCP>
Date: Wed, 30-Sep-87 10:48:43 EDT
Article-I.D.: phri.2916
Posted: Wed Sep 30 10:48:43 1987
Date-Received: Sat, 3-Oct-87 02:12:23 EDT
References: <616@sbcs.UUCP> <6375@apple.UUCP> <21020@ucbvax.BERKELEY.EDU>
Reply-To: roy@phri.UUCP (Roy Smith)
Organization: Public Health Research Inst. (NY, NY)
Lines: 21

In article <21020@ucbvax.BERKELEY.EDU> oster@dewey.soe.berkeley.edu.UUCP
(David Phillip Oster) writes:
> Also, proper mac software is higher quality that most of the software
> delivered with Unix.  In general, Mac software handles out-of-main-memory,
> and out-of-disk-space conditions gracefully. Most Unix programs just crash
> under these conditions.

	Actually, my experience has been that if you compare well-written
modern Unix and Mac programs (say, emacs vs. MacDraft), they both seem to have
about the same level of robustness in the face of resource exhaustion.  The
difference is that when the aren't robust enough, the Unix program gets a
segmentation violation and dumps core and the Mac program hangs the whole
system requiring a reboot.

	I havn't done any Mac programming myself, but I've looked at some Mac
code.  Yes, the algorithm is lost in the morass of window management code, but
that's not terribly different from most Suntools programs I've seen either.
-- 
Roy Smith, {allegra,cmcl2,philabs}!phri!roy
System Administrator, Public Health Research Institute
455 First Avenue, New York, NY 10016