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

Text File | 1992-08-29 | 10.7 KB | 215 lines

Newsgroups: comp.misc
Path: sparky!uunet!sun-barr!cs.utexas.edu!milano!cactus.org!wixer!rhodesia
From: [e-mail] (Felix S. Gallo)
Subject: Re: Giles' Manual Mania (Was - Re: About the 'F' in RTFM)
Message-ID: <[e-mail]>
Sender: [e-mail] (Felix S. Gallo)
Organization: Real/Time Communications
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Fri, 28 Aug 92 17:43:36 GMT
Lines: 203

[e-mail] (Jim Giles) writes:
>[e-mail] (Felix S. Gallo) writes:

>|> Okay, give some concrete examples of a better 'sed', a better 'yacc',
>|> and a better 'awk'.
>
>GNU has a better yacc (they may even call it yacc, I forget - I use LR)
>which is full LR and not LALR like normal yacc.  LR (a public domain
>parser generator) is also better than yacc.  However, if your research
>and development is scientific/numerical software, a parser generator
>is not really a central concern.

By 'better', I meant 'better in the senses you were indicating', i.e.
ease of use, ease of learning, and the spectral 'orthogonality'.  bison,
gnu's "better yacc", is not any easier to learn than standard yacc.  In
fact, "bison -y" is said to be completely indistinguishable from standard
yacc.  At least, I put YACC=bison -y in my Makefiles, fire and forget.

>Awk is a poor imitation of snobol.  The very fact that you mentioned both
>sed and awk is interesting also.  They do the same thing (or, to be more
>precise, there's a *considerable* overlap in functionality).  Yet they
>do so differently - incompatibility!  [...]

The tool does so differently, but the output is exactly the same -- a stream
of text terminated by an EOF, formatted according to your specifications.
That they don't work the same is unimportant; MS Word and Windows 3.1 notepad
don't work the same, either.  Neither do 'rn' and 'vi'.  They're different
tools entirely.

>If UNIX were true to it's creed
>(simple orthogonal tools each doing one thing *well* and piping them
>together), there would be one tool - or at least the two would have
>identical syntaxes for the overlapping parts of their operations.

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.  Or delete
both and just use 'tr'.  Or delete that and just use 'if' and 'echo' and
'cat'.  If you want to use a single interface to text, then by all means
use the 'sed family' -- ed, sed, vi.  The other tools are there for
your convenience, not as an ultimatum.

>|> Err, these 'GUI's you keep referring to are faster than /bin/rc?
>

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

>|> But they are.  sed, awk, perl, tr, pr, nroff, troff, ls, tbl, pic, eqn,
>|> rm, and all the other programs in my /[usr/]bin perform completely correctly
>|> and predictably when placed in pipes.  Maybe there's something integral
>|> to the process which you're failing to understand.

>Yes, I fail to understand why your list contains several tools (nroff,
>troff, tbl, eqn, etc.) which are individually as difficult to learn

Difficulty of learning was not the topic.  Orthogonality was the topic.
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.

>[...]  However, the low quality and long learning
>curve of these tools is probably the reason that the world is
>moving away from the piped-tools model and going toward integrated
>environments - for word processing anyway.

Which reminds me, TeX and LaTeX also pipe together just fine on my box,
and I get perfect camera ready postscript copy whenever I feel like it.
I have the utmost degree of control over the finished product.

By comparison, I have PageMaker 4.0 for Windows.  I consider myself very good
at PageMaker.  I do not believe that I can produce documents as exceedingly
correct and portable with PM4 as I can with TeX.  In fact, the margin of error
across several ported platforms is as much as an inch distance.  Can I correct
this with PageMaker?  No.  Can I correct it with PostScript and TeX?  Yes.

>|> The failure you're experiencing with UNIX is in thinking that it's
>|> a business productivity tool like Windows 3.1 or Quicken, to be compared
>|> with MSDOS color GUI programs.  UNIX and C are research and development
>|> tools.
>
>Yet, they're being promoted for use in production environments.  If they
>are research and development tools, let the researchers and developers
>keep them - hidden away and out of the rest of the public's way.  In
>any case UNIX and C are for research and development of systems and
>system maintenence tools - not for, say, X-ray imaging or groundwater
>flow or stock market analysis tools.

As it happens, UNIX is very good for large database applications such as
Geographic Information Services, especially with PD software like GRASS 4.0
floating around.  I bet it'd be great for groundwater flow and other large-
scale multi-personnel analysis tasks.

>It also makes a poor system in research and development environments
>if what's being researched and developed is not more system tools.

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.

>Supercomputers, parallel syatems, etc. are not appropriate for a
>minicomputer-level development systems.

Parse error near "parallel syatems, etc."

>|> [...]
>|> I've spent 13 years on computers now, and I must confess I have no idea
>|> what these secret tools you're referring to are.  Could you provide
>|> concrete examples of a tool that is as easy to use as, say, sed, that
>|> provides just as much power, but whose documentation is 'better laid
>|> out'?
>
>Sed?  Easy to use?  I don't use it much because it's *not* easy to
>use (and because most of what I do doesn't involve text filtering).

You dodged my question.  Please provide concrete examples of a tool that
is as easy to use as sed (or the standard unix tool of your choice),
provides just as much power, but whose documentation is better laid out.

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

>|> Right, there's your problem again -- assuming that businesses have a
>|> need for UNIX, or that UNIX was designed for use in the commercial
>|> marketplace.  I think Roell Piper has this misnotion too.
>
>No, Ive been claiming exactly what you just said: that there are
>environments where UNIX is not appropriate.

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.   What makes you right in particular and
them wrong?  In particular: why are you so excited about UNIX being so
bad, when you're absolutely free to use whatever OS you like?  Do they
make you program in COBOL at lanl.gov or something?

>  I'm arguing *against*
>the assumption you accuse me of making.  Since you are not recommending
>UNIX for environments for which it is not suited (like the person I was
>responding to), my comments don't apply to you.  I was responding to claims
>that UNIX *was* suited to these application domains - which is not so.

Unfortunately, you also seem to think that the only environment UNIX is
sufficient for is systems design.  In this, you're incorrect.  Ask uunet
for a list of .com sites sometime.

>|> I'm currently running a UNIX clone on a 386/25 with 4M of memory.
>|> This is hardly a massive workhorse, and, since the kernel is less
>|> than 1.2M large, I can also run X.  The cost to me?  $0.00.
>
>Gee.  I wouldn't want to use up a third of my memory on *system* overhead!
>And, I'll bet it uses 50M or more of your disk as well - at least if you've
>got all the bundled tools installed.  For a single user PC clone, that's a
>*lot* of overhead.  Further, X, TCP/IP, and several other things have
>*nothing* to do with UNIX or the bundled UNIX environment I've been
>talking about - they were designed to be system/hardware independent.

Actually, with all of the system tools installed, and a complete copy of
the source code, and all the man(1) pages, and 5M of my own personal code
and text, and LaTeX, and TeX, and fonts, and X, and X source code, and
X libraries, and GCC, and all the GCC libraries, and Groff, and all the
Groff libraries, utilities and fonts, and beta TCP/IP code, and UUCP, and
three editors, and sendmail, mail, elm, all the standard X utilities,
several X games, moria, nethack and sokoban, I come in at a hair under
30M on disk.  Dhrystones?  I completely crush a medium-sized VAX in all
but the floating point tests, and that only because I don't have a
coprocessor.

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!"

>---
>J. Giles
--
----------------------------------------------------------------------------
Felix Sebastian Gallo                              [e-mail]
----------------------------------------------------------------------------