Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!rutgers!rochester!PT!ius1.cs.cmu.edu!edw
From: edw@ius1.cs.cmu.edu (Eddie Wyatt)
Newsgroups: comp.unix.wizards,comp.arch
Subject: Re: Large programs
Message-ID: <1048@ius1.cs.cmu.edu>
Date: Mon, 5-Oct-87 22:57:12 EDT
Article-I.D.: ius1.1048
Posted: Mon Oct  5 22:57:12 1987
Date-Received: Thu, 8-Oct-87 07:24:50 EDT
References: <1046@ius1.cs.cmu.edu> <1130@gilsys.UUCP>
Distribution: na
Organization: Carnegie-Mellon University, CS/RI
Lines: 54
Keywords: UNIX LS HUMOR
Xref: mnetor comp.unix.wizards:4712 comp.arch:2521

>    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 a perspective which is highly important (not altogether
> surprising, as UNIX has a well established tradition of ignoring this aspect
> of computing), specifically, the user interface.
> 
>    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.

   Is it??  What options to "ls" sorts by time last modified, time created,
prints in single columns, multi columns.....

   Having the interface to each command so large, makes it hard just to
remember what damn switches to set to get things done.  So in my opinion,
piping output around is no more complex than the "switch" aproach.
This fact does not justify the modular approach over the monolithic though.
You gain by using pipes in that

	1) Once you know how to perform some operation on some data
	   (like sorting the output of ls by file size) you can extend it
	   to any command (like sorting the output of df by size).

	2) From the implemation standpoint, modularity can reduce the
	   amount of duplicated efforted. -- Does ls bother calling
	   sort for its sorting of output or did someone implement yet
	   another sort in the ls code??

	3) Uniformity is achieved.  Does the -v switch for ls do the same
	   thing for cat?? Probably not. (Though I have to admit some
	   attempt at uniformity in switches is made: -i for cp, rm, mv
	   does basically the same thing)


> 
>    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?

   Admittedly, speed in execution is one of the prices you pay for taking
the modular approach, but things aren't all that bad.  Piped processes
get executed concurrently. If you had a parallel processor, who knows,
maybe each program could be executed on a different processor. The
pipes could provide a course grain break down of the computing needed. 8-}

-- 

					Eddie Wyatt

e-mail: edw@ius1.cs.cmu.edu