NetNews Usenet Archive 1992 #19/NN_1992_19.iso/spool/comp/misc/3407

Text File | 1992-08-29 | 12.0 KB | 240 lines

Newsgroups: comp.misc
Path: sparky!uunet!elroy.jpl.nasa.gov!sdd.hp.com!caen!hellgate.utah.edu!lanl!cochiti.lanl.gov!jlg
From: [e-mail] (Jim Giles)
Subject: Re: Giles' Manual Mania (Was - Re: About the 'F' in RTFM)
Message-ID: <[e-mail]>
Sender: (null)@(null) ((null))
Organization: Los Alamos National Laboratory
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Sat, 29 Aug 1992 00:45:10 GMT
Lines: 228


In article <[e-mail]>, [e-mail] (Felix S. Gallo) writes:
|> [...]
|> Nobody's forcing you to use sed and awk at the same time.  In fact, if
|> you like, you can delete awk from your disk and just use sed.  [...]

Well, since I (like everyone else) spend most of my time using
other-people's-code, I have to learn *both* sed *and* awk to
work on UNIX - as well as a huge number of other tools with
largely overlapping functionality - yet which are each mutually
inconsistent in how that overlapping functionality is done.
I don't personally have anything much that I need any of these
tools for.  But, I have to know them in order to understand
and use what others have done (because no one bothers to document
their scripts and/or make scripts they distribute robust).

The choice is to use the UNIX environment (and *have* to learn
how all that stuff works) or to use a different environment in which
well integrated tools are sufficiently capable that everyone uses
the same ones - and you only need to learn *one* tool for each
functionality.

The truth is that, as you say, I don't have to use either sed *or*
awk: and I *don't* (for my own stuff).  I still have to *know* both
in order to be a UNIX user.  So does every one else who uses UNIX.

|> [...]
|> >The /bin/rc I have access to is part of the system boot sequence and is
|> >not a part of the naive user envoronment at all.  What relevance to does
|> >it have to a discussion about user-level tools?  I'm talking about tools
|>
|> /bin/rc on most sane, happy computer systems is the RC shell, written I
|> believe by Rob Pike et al.  It provides a very small, very compact and
|> elegant C like shell which starts up, on my computer, in about .3 realtime
|> seconds.  By comparison, X takes about 3 minutes.  Maybe you're confusing
|> /etc/rc with /bin/rc?

There is only *one* utility called rc on my SunOS machine.  It
sounds, however, as if you're agreeing with me - you are recommending
an environment *different* from the one which is conventionally bundled
with UNIX.  One that is better integrated, fast, and (I hope) better
documented.  Good for you.  And thanks for the confirmation that I'm
right.

I don't *insist* that alternatives to the usual UNIX environment be
GUI's, they can actually be *anything* and probably still be an
improvement.  By recommending something that is *not* the UNIX bundled
environment, you are supporting my position.

|> [...]
|> Difficulty of learning was not the topic.  [...]

Yes it was!!  That's the basis of the subject line of this thread.
Don't instruct *me* about the topic of a thread with *my* name in
the subject line (:-).

The topic is: ease of use - and in particular - ease of *learning*
the usual UNIX bundled environment.  We aren't discussing the kernel,
add-on tools like perl or rc, or anything like that (and which might
just as well be on some other system).  We are talking about the tools
which are in the UNIX command reference manual (all the things with the
(1) mark on their man pages) and have been essentially unchanged for
more than a decade now.  Are the tools mutually consistent, clean,
orthogonal, compatible, etc.?  And we are discussing that document -
is is easy to read, understand, find stuff in?   I say no.

|> [...]                                     Orthogonality was the topic.

That's one of the important components of making something easier to
learn.

|> You claimed that these commands do not pipe together, and that they do
|> things in different ways -- I presented a list of commands which not only
|> pipe together, but together form an extremely powerful development environment,
|> given correct selection.

Development of *what*?  The tools you mentioned mostly only do text
manipulation.  Very little of computing is text manipulation.  Much
more is word processing (which the tools you listed *aren't* all that
easy to learn and use for).  The vast majority is neither text nor
word processing.  Yet, in order to use UNIX, no matter *what* you do,
you must learn a large percentage of all those tools - even if they're
*completely* irrelevant to your real job.

Meanwhile, try piping C source code through your favorite example: sed.
Sed is a line oriented tool and will foul-up royal with C source since
line boundaries are *just* whitespace to C.  Any pattern you're trying to
filter which the author of the C source *happened* to split across a line
feed will be missed by sed.  This looks like a pipeline incompatibility
to me.

|> [...]
|> Years of reality have proven you wrong.  UNIX is really *great* for
|> systems tools, but it does other things very well as well.  It might not
|> do what you want it to do, but you're perfectly free to buy another OS
|> and not get upset over UNIX, you know.

No, I'm not free to buy what I want.  I work on what the management buys
off on.

|>
|> >Supercomputers, parallel syatems, etc. are not appropriate for a
|> >minicomputer-level development systems.
|>
|> Parse error near "parallel syatems, etc."

Huh?  UNIX has *NO* features which are even *relevant* to parallel
processing.  Like many other system, such features are being
experimentally *added*.  UNIX has no particular advantages in
this area.  Fortunately, most such features relate to the kernel
and the languages, so the question is independent of the topic of
this thread - which is the ease of learning the bundled UNIX software
tools.  However, while I'm doing the difficult work of parallelizing codes,
I'd just as soon not be constantly distracted by all the `gotchas' of
the UNIX environment.

|> [...]
|> >In the 25 years I've been programming, the only system I remember
|> >to *compare* with the difficulty of learning and using UNIX is OS/360.
|> >And for the same reasons: *lots* of arcane trivia and poorly organized
|> >manuals.  The terms `arcane' and `user friendly' are mutually exclusive.
|> >UNIX is arcane.
|>
|> Given.  So are most important professional products.  Tried to use
|> FrameMaker without looking at the manual set yet?

Never even looked at the manual on the word processor I have at home - it
produces documents easily (in a few minutes) that it would take *days*
just to learn *how* to do on troff, eqn, tbl, et. al..  And it's just a
cheap off-brand processor that someone gave me (ETG I think it's called).
Want to change fonts?  No funny directives with periods in the first
column and a requirement that I look up the font catalog for the name
(or whatever troff makes you do): just select the font entry in the menu
and select the specific font I want.  Want to center text?  Select the
formatting menu item and then select the entry for centering - no funny
dots in the first column, etc..  Want your spelling checked?  No need
to pipe through a separate tool, it beeps and presents a menu box of
alternative spellings automatically.

Similar tools from other vendors have similar properties and can
send output to film, slides, all common printers etc. and/or convert
documents to TeX or Postscript if that's your fancy.

Sure, these tools differ from *each other*, but individual users
only have to learn their favorite - which is easy.  They can share
documents because these tools include the capability to read and/or
write mutually compatible intermediate formats (like TeX and Postscript)
or they should!  (Actually most do support at least one of those forms now.)

Are troff, eqn, tbl, et al more powerful?  No, they take longer to
learn than word processing functionality - in its entirity - is worth
to me.  Something I don't use is *not* powerful - no matter *what*
features it has.  The other word processors take a few *minutes*
to begin using productively and the menus *lead* you through any
of the arcane stuff.  There is no reason such an interface cannot
be built on *top* of troff, eqn, tbl, etc., but I've never seen it
done - probably because *other* integrated tools exist which are
already *better* than the UNIX bundled tools and are even available
on UNIX if you insist.

|> [...]
|> Actually, you've been claiming that UNIX is archaic, arcane, useless,
|> built from improper tools, non-orthogonal, incomprehensible, worthless,
|> huge, bloated, hard to learn, poorly documented, and out of date.  There
|> is a world of difference.  Hundreds of thousands of people use UNIX daily
|> and are quite happy about it.  [...]

Millions of people drove Model T's for years and were very happy with
them.  In fact, they're free to continue to drive them as far as I'm
concerned.  As long as they don't make *me* drive one; as long as they
put proper modern mufflers on them so I don't have to hear about it; and
as long as they meet modern pollution control requirements.

The analog of the muffler and pollution control requirements in UNIX
are: stop telling non-UNIX users that everything they do is wrong
and stop claiming UNIX has clear advantages when it's really just
a matter of opinion whether it's even *good* or not.

Claims about convenient piping through sed are irrelevant to whether
you can parallelize a lattice guage theory code or not.  In fact, the
difficulty of sed distracts from that other topic - because using UNIX
does not afford the luxury of NOT learning things you don't care about.

|> [...]
|> Unfortunately, you also seem to think that the only environment UNIX is
|> sufficient for is systems design. [...]

*I* wouldn't use it for systems design.  I would prefer to use a well
designed language (like, say, Turing) for systems design and this is
discouraged by the way UNIX is structured.  Systems designers can use
whatever they want though, as long as they don't insist I have to use
the same thing they did when they present me with their finished product.

|> [...]
|> Let me relate to you a little story:
|>
|> A man comes in to a massive warehouse.  Mechanics are hurrying back and
|> forth, working on enormous pieces of machinery.  Huge cranes ferry molten
|> iron vats from one end to the other.  Overseers chart the progress of their
|> factory from catwalks above.  The entire right wall of the factory is covered
|> with tools -- Allen wrenches, 5.2" socket bitwisters, screwdrivers, ice
|> mallets, lathe press drill molds, shearing tweezers -- all alphabetically
|> organized, all within easy reach.  Bulldozers and tractors move concrete
|> blocks with precision into the assembly lines.
|>
|> The man complains, "hey!  None of this can balance my checkbook!"

Yes.  But no one is lobbying his management with claims that all
that stuff *can* balance his checkbook!  And no one in congress
has passed laws that National Science Foundation money cannot
be given to anyone who uses something *else* for checkbook balancing.

Further, the analogy to UNIX is more clear when you realize that
alphabetization of the tools is a poor way to organize them - just
like the UNIX tools are poorly organized.  They should be organized
by function.  There is no *subject* index for the UNIX documentation
set!  Nor is the documentation ordered by functionality.  The documents
are ordered alphabetically by the tool name.  So, you can't find the
tool which does what you need done unless you know its *NAME* already!
(Gee, if I already knew what I was looking for, I wouldn't need to look.)

Try doing `man -k slides' sometime.  I get `slides: nothing appropriate'
even though I *know* my workstation has several tools for making all
sorts of film images - including slides - and even though I *know*
the man pages for these tools are online.

--
J. Giles