Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!rutgers!uwvax!oddjob!tank!uxc!uxc.cso.uiuc.edu!a.cs.uiuc.edu!m.cs.uiuc.edu!wsmith
From: wsmith@m.cs.uiuc.edu
Newsgroups: comp.software-eng
Subject: Re: Cynic's Guide to SE #6: Forthcoming
Message-ID: <39400002@m.cs.uiuc.edu>
Date: 7 Oct 88 02:26:00 GMT
References: <9@helens.stanford.edu>
Lines: 25
Nf-ID: #R:helens.stanford.edu:9:m.cs.uiuc.edu:39400002:000:1319
Nf-From: m.cs.uiuc.edu!wsmith    Oct  6 21:26:00 1988


>A good rule of thumb I've observed is that anytime a project can
>be done by one or (maybe) two people, a PC is probably your best choice.

I don't believe this because of the lack of memory managment on all but the
most recent PC's.   If a bug causes my system to crash because of wild
pointers (which are easy enough to create on a Unix system and even moreso
on segmented architectures like the 80x86) I lose a good bit of time waiting
for the system to reboot.

Also, it is quite easy for one person to develop a project that won't fit
within the memory constraints of a PC (which could be solved by a large
virtual address space).

I agree with your premise that the tools should be selected so that they are
appropriate for the problem at hand.  My current project is 20k lines and 200+ 
source files and I think that without the simple facility of a core dump to 
save the state of the program when a fatal runtime error occurs, I would be 
still focusing on debugging instead of on future enhancements.  Also, the 
project is big enough that each module has its own directory.  I don't
have much respect for PC make facilities especially since a PC has limited
concurrent execution powers to allow for the nested makes needed for the nested
directory structure.

Bill Smith		uiucdcs!wsmith		wsmith@cs.uiuc.edu