Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!bloom-beacon!gatech!udel!rochester!crowl
From: crowl@cs.rochester.edu (Lawrence Crowl)
Newsgroups: comp.unix.wizards,comp.arch
Subject: Re: Large programs
Message-ID: <2946@sol.ARPA>
Date: Mon, 5-Oct-87 17:07:22 EDT
Article-I.D.: sol.2946
Posted: Mon Oct  5 17:07:22 1987
Date-Received: Thu, 8-Oct-87 05:31:51 EDT
References: <1046@ius1.cs.cmu.edu> <1130@gilsys.UUCP>
Reply-To: crowl@cs.rochester.edu (Lawrence Crowl)
Distribution: na
Organization: U of Rochester, CS Dept, Rochester, NY
Lines: 55
Keywords: UNIX LS HUMOR
Xref: mnetor comp.unix.wizards:4702 comp.arch:2518

In article <1130@gilsys.UUCP> mc68020@gilsys.UUCP (Thomas J Keller) writes:
]   I read quite frequently about how programs should be kept small, simple,
]single-purpose, and then tied together with pipes to perform more complex
]tasks.  This is all well and good from one perspective.  But it seems to me
]that it ignores ... the user interface.

I think you should be careful to distinguish between ignoring the user
interface and choosing a user interface you feel is inappropriate.

]   1)  entering a command which uses three to seven different small programs,
]all piped together, is a *PAIN* in the arse!  In many cases, a single command
]is much more desireable, certainly less prone to errors, and always eaiser and
]faster to use.

This problem is easily solved with a shell script.  This gets you a single
command and the convenience of not having to place all the filters in the
program.

]   2)  speaking of speed, we all seem to have forgotten that each one of those
]lovely small programs in the chain has to be loaded from disk.  Clearly, the
]overhead necessary to fork & spawn multiple processes, which in turn load
]multiple program text into memory, is **MUCH** greater than spawning and 
]loading a single program!  Waiting time is important too, you know?

You forgot an important speed difference.  In the pipe approach, each program
in the pipe does a lot of file I/O and string to data to string conversions.
A system which operates on the data values themselves without the intermediate
file representation can be much more efficient.

]   I would suggest, however, that mono-maniacal adherence to a so-called
]"UNIX Philosophy" which for the most part blatantly ignores the needs and
]convenience of the USERS is an error.  Sure, it's FUN to be a wizard, and know
]how to invoke arcane sequences which accomplish what are really fairly simple
]tasks, and to have unsophisticated users in awe of your prowess.  Fun and very
]satisfying.  But not very effective, and for my money, highly
]counter-productive.  

But the intended users of Unix are (or were initially) wizards!  They were
assumed to be doing weird things with consistent need for rapid, "hack"
solutions that a more structured environment might inhibit.

]   There is no reason that UNIX should remain a mysterious and arcane system
]which typical users are fearful to approach, yet this is the case.  Continuing
]promulgation of the "UNIX Philosophy", as it currently exists, can only ensure
]that fewer people will learn and use UNIX.  It is time for us to get our egos
]and our heads out of the clouds, and make UNIX a reasonable, effective
]environment for everyone, not just the wizards.

If you want to change the basic design premise of the system, fine.  But don't
get mad because someone else wants to maintain the original design premise.  I
believe there is a good compromise out there, but it is not obvious.
-- 
  Lawrence Crowl		716-275-9499	University of Rochester
		      crowl@cs.rochester.edu	Computer Science Department
...!{allegra,decvax,rutgers}!rochester!crowl	Rochester, New York,  14627