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

Internet Message Format | 1992-09-01 | 9.8 KB

Path: sparky!uunet!ogicse!uwm.edu!cs.utexas.edu!csc.ti.com!tilde.csc.ti.com!mksol!mccall
From: [e-mail] (fred j mccall 575-3539)
Newsgroups: comp.misc
Subject: Re: Giles' Manual Mania (Was - Re: About the 'F' in RTFM)
Message-ID: <[e-mail]>
Date: 1 Sep 92 20:19:59 GMT
Article-I.D.: mksol.1992Sep1.201959.17608
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Organization: Texas Instruments Inc
Lines: 181

In <[e-mail]> [e-mail] (Jim Giles) writes:

>In article <[e-mail]>, [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.

They call it bison, actually, it it acts very much like yacc.
Everybody is asking you for these better examples I asked you for
earlier, Jim.  You dodge them as you dodged me.  Why don't you just
answer the man?

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

Well, Ada and FORTRAN do the same thing, too, and they are
incompatible.  Which one should we dump?

>|> [...]
>|> >*NOTHING*!!  With the alternatives I've seen, you *gain*: speed, features,
>|> >user productivity, etc..
>|>
>|> 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
>which are useful in writing and maintaining software for applications
>*other* than system design or system maintenence.

You are undoubtedly thinking of /etc/rc.  It's not the same thing.
You keep talking about all this gain in speed, features, etc., but you
never name any tools.  Come on, Jim.  Name us these more powerful sed,
awk, yacc, lex, etc.  Name us the tools with more POWER than the text
formatting tools one typically finds on UNIX.  Name us the software
development tools.  The list goes on and on.  Just what is it that you
do that is so specialized that you think the rest of the world should
have to go your way?

>|> >[...].  The "pipe together simple tools" approach
>|> >has *some* merit.  Too bad UNIX didn't stick to it.  More precisely, too
>|> >bad UNIX didn't periodically winnow out all but the best tools and utilities
>|> >and rewrite them to be compatible and orthogonal.  Might be an interesting
>|> >system.
>|>
>|> 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
>as a single integrated tool which does *all* those word processing
>operations - and contains context sensitive help (even though it's
>already easier to learn than the UNIX stuff).  Especially since these
>integrated tools actually have MORE features than what you mentioned.
>If those tools were each *very* simple to learn, or if they each
>actually *did* more, the technique might be an acceptable alternative
>to integrated tools.  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.

As usual with the UNIX philosophy, Jim, one gets low-level control
(and the complexity that has to come with that).  You do indeed fail
to understand.

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

The two areas where I probably wouldn't use C/UNIX are business
applications (because the IBM COBOL legacy simply makes it
unrealistic to do so) and real time applications (because the UNIX
tasking and post-crash recovery aren't what you want for that).

>|> [...]
>|> 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).
>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.

And what language and environment have you used for that 25 years,
Jim?  It must have been the same one, or you wouldn't be so upset at
having to change now.

The man asked you for concrete examples.  You again fail to give them.

>|> [...]
>|> >[...]  Many businesses would never have even considered using UNIX
>|> >without something *like* windows (or alternative utility sets,
>|> >or alternative shells - anything to improve the crummy environment)
>|> >because UNIX is not cost-effective without them (too much training
>|> >and "guru" overhead).
>|>
>|> 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.  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.

No, that's not what you've been claiming.  You've been doing your
usual periodic 'bash C/UNIX' routine.  As usual, you look as foolish
as ever and are now having to change your words.  NOBODY said that
C/UNIX was the answer for EVERYTHING.  You impute that to people and
then tirade away from there.

As "the person" you "were responding to" (not!), let me say that I did
NOT say what you impute to me.  People can read, Jim, and their
memories simply aren't that short.

>|> [...]
>|> Again, you miss the point of UNIX entirely.  UNIX is designed for
>|> a networked environment.  It is designed for multi-user machines.
>|> It is designed to be modular, and text-based; there are few needs
>|> for 'off-the-shelf GUIs', whatever that's supposed to mean.  The
>|> toolset is integrated.   In fact, you can even *make your own
>|> tools.*  Try that under Windows. :)

>No, UNIX was basically designed and fixed in its present form before
>networks even existed.  The network protocol which is presently used by
>most UNIXes is a system independent protocol (deliberately so) designed
>by DARPA.  UNIX was designed at AT&T as a testbed for trying out experimental
>ideas of system design.  It was not intended, when first designed, to be
>seen or used by any but the researchers involved and their colleagues - all
>of whom were willing to endure the idiosyncracies of an ad-hoc system.
>It became widespread because it was free and open (neither are technical
>qualities - schools wanted some unimportant system which was simplistic
>enough to teach from and could be sacrificed to studen hacks and such;
>no one was foolhardy enough - in those days - to do anything really
>important on UNIX) and it is popular now because the students who
>learned under it are not willing to learn anything new (as is evidenced
>by the strong resistence and abuse from many on the net when it is suggested
>that there *might* be better ways).  UNIX retains its experimental, testbed
>character - as well as many of the experimental features (even those which
>are now thought to be bad ideas).

And now here you are back to saying it's bad for everything.  You
REALLY need to make up your mind, Jim.  If you can ever get it open,
that is.


--
"Insisting on perfect safety is for people who don't have the balls to live
 in the real world."   -- Mary Shafer, NASA Ames Dryden
------------------------------------------------------------------------------
[e-mail] - I don't speak for others and they don't speak for me.