Path: utzoo!attcan!uunet!ncrlnk!ncrcae!ece-csc!mcnc!gatech!ncar!tank!mimsy!haven!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn )
Newsgroups: comp.unix.wizards
Subject: Re: cat -u
Message-ID: <9138@smoke.BRL.MIL>
Date: 11 Dec 88 05:18:29 GMT
References: <175@ernie.NECAM.COM> <189@wyn386.UUCP> <8910@smoke.BRL.MIL> <8160@bloom-beacon.MIT.EDU> <146@minya.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 21

In article <146@minya.UUCP> jc@minya.UUCP (John Chambers) writes:
>What ever happened to the original Unix Philosophy of lots of little
>programs, each of which did exactly one job well, and which could be
>fitted together to do bigger jobs?  I've noticed that lots of people
>seem to dislike this approach, but I've yet to see any cogent argument
>against it.

In the standard shell environment, it's obviously the best approach.
The only technical argument I know of is that if too many processes
have to be invoked simultaneously to get a task done, some system or
user limit may be exceeded.  I have almost never run into this in
practice, however.

In a Macintosh-like environment, the situation is radically different,
because there is no good way to combine independent processes into a
larger unit.  This frustrates the heck out of me when I'm using those
systems!  In such an awful environment, so-called "integrated
applications" with maximal number of imbedded features are practically
required to get the job done.  Of course, one useful integrated
application would be a UNIXy shell with pipes and a bunch of basic
UNIXy utilities.  So much for the icon interface.