Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!cmcl2!beta!hwe
From: hwe@beta.UUCP (Skip Egdorf)
Newsgroups: comp.unix.wizards
Subject: Re: Large programs
Message-ID: <10908@beta.UUCP>
Date: Mon, 5-Oct-87 18:56:45 EDT
Article-I.D.: beta.10908
Posted: Mon Oct  5 18:56:45 1987
Date-Received: Thu, 8-Oct-87 06:12:06 EDT
References: <1046@ius1.cs.cmu.edu> <1130@gilsys.UUCP>
Distribution: na
Organization: Los Alamos Natl Lab, Los Alamos, N.M.
Lines: 74
Keywords: UNIX LS
Summary: But wait a minute...

(comp.arch has been removed from Newsgroups:. This is no longer dealing
with computer architecture.)

In article <1130@gilsys.UUCP>, mc68020@gilsys.UUCP (Thomas J Keller) writes:
> In article <1046@ius1.cs.cmu.edu>, edw@ius1.cs.cmu.edu (Eddie Wyatt) writes:
> > 
> > "In the absence of the ability to redirect output and input, 
> >	[ stuff about why ls shouldn't have lot's of options ]
> > authors of commands such as 'ls' to provide such a wide variety of output
> > options."
> > 
> >    Its seems very funny that they use 'ls' as an example since that
> > command now is so burdened with options.  The functionality of which
> > could be provided by piping the output of the command into other
> > UNIX utilities. It seems that someone lost sight of the original plan.
> 
>    Okay, now I am the first to admit that I am a relative neophyte to UNIX and
> its philosophy, but it seems to me that a crucial point is being missed here.
> 
>    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.

This is the statement that is deserving of flame. I hope, however, that
the discussion below provides more light than heat.

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

> -- 
> Tom Keller 

Having been around UNIX for a few years, I would like to point out
that this is a twisting of what I understand to be the Unix Philosophy.

The original idea of Unix, was to write a simple program (e.g. a naked
ls command with no options) and then profile it to find out how it
was used. The classic example of this was the early examination of
the ed editor that found that the single major use of the editor was to
search for text patterns with no modification via
  g/regular-expression/p
Finding this usage was common, it was packaged as a seperate command
very naturally named "grep".

Many of the command line arguments (and commands themselves) came to
be in this way. Most of the initial accounting on early Unix (V5, V6, ...)
was not for charging users, but to find how the system was used so that
it could be improved. This was viewed as the only REAL way to provide
for the user's needs, since some wizard would have, at best, a poor
understanding of those needs.

The whole Unix Philosophy was driven by examination of and support for
"the needs and convenience of the USERS" (to quote Tom).

It is unfortunate that a gaggle of hackers far less capable than a
Ken Thompson or a Dennis Ritchie ignored this philosophy, and produced
a set of commands with "features" added because the programmer thought
they were "neet" rather than in response to user's needs, and with
usage that made it harder to build and combine.

The often quoted lack of Unix "User Friendly"ness comes from ignoring
the Unix philosophy and building tools in the same old way as all the
OTHER systems do. The scene would much more attractive had the Unix
philosophy been heeded.

Don't blame a lack of Unix philosophy, rather work for its return.

					Skip Egdorf
					hwe@lanl.gov