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

Internet Message Format | 1992-08-26 | 9.1 KB

Xref: sparky comp.misc:3366 comp.lang.c:12829
Newsgroups: comp.misc,comp.lang.c
Path: sparky!uunet!elroy.jpl.nasa.gov!ames!agate!dog.ee.lbl.gov!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]>
Followup-To: comp.misc
Sender: [e-mail]
Organization: Los Alamos National Laboratory
References: <[e-mail]>
Date: Thu, 27 Aug 1992 02:08:32 GMT
Lines: 174

Followups posted to comp.misc

In article <[e-mail]>, [e-mail] (fred j mccall 575-3539) writes:
|> In <[e-mail]> [e-mail] (Jim Giles) writes:
|> [...]
|> >What I said was that if a document were *persistently* misread, it's
|> >certainly an indication of a problem with the *document* - especially
|> >if there exist other documents which describe similar tools and which
|> >*don't* engender persistent problems.
|>
|> Or perhaps it's just a problem with the thing being documented being
|> very capable and complex?  [...]

Those are not necessarily synomymous properties.  UNIX tools tend to
be *unnecessarily* complex.  That is, their complexity is not justified
by the capabilities they provide.  Tools with the same capability can
be less complex, tools with the same complexity can be *more* capable:
both of these by a large margin.

|> [... irrelevant ad-hominem attacks deleted ...]
|> >Yes, but when you see reasonably good drivers have a disproportionate
|> >number of accidents on a given road or with a given car: that seems
|> >to indicate problems other than the driver.
|>
|> Put 'reasonably good drivers' on an Indy track and see what happens.
|> Is this because Indy cars are badly designed, or because they go so
|> much faster?

If UNIX were *really* more powerful, faster, or more flexible than the
*real* alternatives in *modern* system design, then you'd have a point.
It isn't.  You don't.  Well integrated GUI's placed on top of UNIX
demonstrate this point well - they provide the same (and sometimes better)
capabilities as the usual UNIX environment, yet are easier to use.  UNIX
on Crays is *slower* than what it replaces, consumes more resources for
system overhead, is harder to use, and is less capable for the tasks
people buy Crays for.  Etc..  UNIX is *promoted* for all markets, but
isn't suitable for all of them - and isn't *modern* in any of them.

|> [... more ad-hominem garbage elided ...]
|> >Based on my experience, this statement implies that UNIX documentation
|> >*induces* inattentive or lazy reading habits among otherwise competent
|> >and intelligent users.  The `gotcha' rate and the "it's in the manual"
|> >questions are higher in frequency for *all* classes of users - not
|> >just the lazy or the incompetent.
|>
|> That's because too many of your 'competent and intelligent users' have
|> gotten used to documentation where one need only read every other
|> paragraph because it's so loaded with mind-numbing fluff.  UNIX
|> documenation typically assumes you're paying attention.

No, they're used to documents which require considerably less reading
*at*all*.  And yet which describe more feature rich tools.  UNIX
supporters seem to be willing to read *reams* of stuff that's irrelevant
to their use of the tool, as well as *reams* of stuff about other
documents of *apparently* unrelated tools, before they can safely use
the default behavior of the tool.

|> [...]                              If changing something reduces the
|> >frequency or severity of error - do it.  A number of possible changes
|> >to UNIX would do just that.
|>
|> And just what do you LOSE when you make those 'possible changes', Jim?

*NOTHING*!!  With the alternatives I've seen, you *gain*: speed, features,
user productivity, etc..

|> [...]
|> [Exposition on simple tools that have simple interfaces deleted, since
|> it doesn't apply to tools with more power.

And since "tools with more power" is not a relevant topic when discussing
UNIX anyway.  The UNIX philosophy is _supposedly_ that tools have no
great power in themselves (this is true, they don't), but they pipe together
to give overall power (this would be true if they were actually orthogonal,
simple, and mutually compatible).  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.

|> [...]
|> >I've used tools which are written and documented well.  From
|> >experience at our consulting office, I can tell you that users
|> >actually prefer the manual for tools like this.  They seldom
|> >ask questions and few of those they do ask can be answered
|> >straight from the manual.
|>
|> Sure.  But what have you done to the power of the tool? [...]

Increased it!!  No UNIX word processor is as capable as the simplest
one available on other systems, for example (Oh, sure - emacs: if you
want to write the features yourself - I don't have the spare two
years to learn emacs - much less to write the features).  It is interesting
that the best word processors now available for UNIX are rewrites of
software written for MACs and MS/DOS machines - at double or triple
the prices of the same package on those other machines (increased
development and support costs)!  So, with respect to the narrow
field of word processing, the irrelevant alternative you keep offering
(MS/DOS) *is* actually better.  AT&T *also* selected MS/DOS for the
computer services contract it has with AMTRAC: because AT&T (the
inventor of UNIX) determined that training and system administration
overhead for a UNIX installation were unacceptable.

Just because AT&T agrees with me that UNIX takes more training and
administration overhead for the same capabilities shouldn't dissuade
you from claiming I'm just a lone "whiner".  After all, when you start
losing a discussion, the ad-hominem attacks are all you have left.
I don't mind, it's *your* credibility that suffers.

|> [...]
|> >This simplistic interface that you deride is actually responsible for
|> >well over 90% of all your activity.  Most of the options will be used
|> >perhaps only once in every few uses of the tool (if that often - if
|> >they are used nearly every time it's appropriate to change the defaults).
|> >These options are still available, they're just unobtrusive: you don't
|> >*have* to know them in *detail* to use the tool for its default purposes.
|> >That cotton wall is insulation, not isolation.
|>
|> But Jim, you miss the point.  MOST OF US DON'T WANT TO BE INSULATED
|> FROM OUR TOOLS.  We want to be able to get in and do things, not have
|> the tools decide.

The tools *don't* decide, the user does.  The tools are just laid out so
the choice is better structured and easier to make.  As well as being easier
to learn.  You don't have to know about options you aren't using in order
to use the ones you *are* interested in.

|> [...]
|> >In fact, for the most part the UNIX tools are often *less* capable
|> >than their better designed (easier to learn and to use) counterparts
|> >elsewhere.
|>
|> That's because tools in UNIX are designed to fit together on
|> pipelines, etc., so you can build more capable things out of what you
|> have instead of having to get a whole other tool.

And, if this really *happened* on a consistent basis ....
Yes, pipes are useful for rapid prototyping (or would be, if the UNIX
utility set was really complete, orthogonal, and mutually compatible -
they ain't).  No one said to give up pipes.  However, it would be
nice if the UNIX tools were *designed* to fit together - or designed
*at*all*.

|> [...]
|> >This is the primary cause of the success of windowing
|> >environments on UNIX, they *hide* the crummy interface.  A well
|>
|> Boy, talk about your stupider analyses of why GUIs are desirable.
|> Windowing environments are only popular on UNIX, Jim?  [...]

No, that's not what I said.  I said that windowing environments
are disproportionately desirable on UNIX.  This is because they're
the only part of the environment that's acceptable for day-to-day
use.  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).

Yes, windows are popular in other environments as well because they
are a good idea in their own right.  But, for UNIX, they're manditory.

|> [... more ad-hominem drivel ...]

Now, *if* you have a small, single-user (or few-user) machine; and
*if* the machine has considerably more speed and memory than you
need for your applications; and *if* security is of little concern
to you; and *if* you have some off-the-shelf GUI's and other
integrated tools available - *then* UNIX may actually be a good
choice for the system to run on your machine - if you don't mind
the longer learning curve.

--
J. Giles