Path: utzoo!attcan!uunet!wuarchive!usc!elroy.jpl.nasa.gov!ames!haven!adm!cmcl2!lanl!jlg
From: jlg@lanl.gov (Jim Giles)
Newsgroups: comp.arch
Subject: Re: How wrong is MS-DOS? (or: Tools Tools Tools)
Message-ID: <11255@lanl.gov>
Date: 13 Jan 91 04:16:35 GMT
References: <EGDORF.91Jan12184630@zaphod.lanl.gov>
Organization: Los Alamos Natl Lab, Los Alamos, N.M.
Lines: 63

From article <EGDORF.91Jan12184630@zaphod.lanl.gov>, by egdorf@zaphod.lanl.gov (Skip Egdorf):
> In article <11143@lanl.gov> jlg@lanl.gov (Jim Giles) writes:
>> [...]
> Ummm... But, Jim, weren't you just saying that the problem was the "muscle"
> required to run all the Unix stuff? doesnt wrapping a grep into EVERY program
> just make the problem worse?

No. Piping things together is about the _least_ efficient way of
incorporating a functionality into a tool.  Almost _anything_ is
an improvement.  The additional muscle required to support UNIX
is due in large part to preferential use of this least efficient
technique.

> [...]              The point of the Unix interface is (and was in 1975) that
> tools like grep are supposed to be seperate in order to avoid the "muscle"
> required when all those 'modes' are in EVERY program.

The paradigm you are describing was recommended to as a way of perfomrming
what we would today call "rapid prototyping".  It was a way of getting
a quick-and-dirty version of a new tool so you could play around with
the functionality before building a production quality version as a
single utility.

> [...]      The problem (my opinion) stems from lots of users moving to Unix
> from systems that do not provide multitasking ("Why would I ever need to run
> more than one thing on my single-user suystem?" shows up all over the net a
> lot ...) and then try to use the tools one at a time and are disapointed.

In the modern sense of the term, UNIX doesn't provide multitasking
either.  It provides multiprocessing.  Pipes are a weak subset of
the general concept of interprocess communication.

For the benefit of those that don't have a multitasking system, I will
describe the difference.  Multiprocessing is the use of timesharing
or other techniques to do (or at least simulate) several independent
processes simultaneously.  Such processes _may_ communicate with each
other through the operating system.  The standard model for this is to
treat interprocess communication as a type of I/O.  Multitasking is
the use of several CPUs on an individual process in order to speed
the turnaround of that process.  Differrent tasks communicate with each
other without having to pass the information through the system.  The
usual method here depends upon the mutual exclusion instructions and
general archetecture of the hardware in use.  The Cray, for example,
provides shared memory access between CPUs, shared registers, and
hardware semaphores.  To be sure, before the wide availability
of multiple CPU machines, the two terms were used interchangably.

> [...]
> I don't use a power floor sander to do the final smoothing on a picture
> frame, and I don't use a piece of 1x2 with 320 grit wrapped around it
> to finish an Oak floor.

Then why insist that a single tool (grep) is appropriate for all pattern
matching functionality?  It's as if the _only_ size sandpaper was the
1x2 and if you needed to do floor finishing you'd have to glue dozens
of sheets of such paper to the power sander.  It's possible, but the
appropriate size paper for each job is better.

The appropriate level of interaction between the components of a
software environment is very rarely a pipe.  The appropriate level
of interaction is _much_ more often a procedure call.

J. Giles