Pippilangstromp you are so right - bad manuals can kill the best thing:
> ... it neglects instructions like how to edit
> something "Simply edit the ____ file to produce this result!" it says and
> never says how to carry out the suggestion! I've seen this in a few
> manuals, neglecting basic instructions such as how to find a directory,
> how to open/close applications and files, how to install/remove applications
> and files, etc. If DOS instructions were this arcane everyone would have
> to use Macs!
(and with that Mac you wouldn't get to know where the dang file is, or
if it's really on the diskette you'd want to take out - another good
example of bad manuals, not to given basic information...)
And *no*, Steven, this answer of yours turns around the pot: how ever
could I guess that
> The fstab file is the f-ile s-ystem tab-le
- if that's written nowhere ?! If even the principle of how files are
named is perfectly opaque ?
It's things like that trivial which can drive me (and probably other
people as well) mad.
It took me perhaps three years to "learn" DOS, arcane as it was indeed.
It had taken me some few weeks only to learn BASIC though - because the
absolutely clear and precise manual of the very first Basic dialect I
was confronted with ("MBasic (c) Microsoft 1981-1983" *but* the manual
was written by Olivetti), was just right and concise - I had the
comparison with the (then widely common) "BBC-Basic", sitting e.a. in
the Sinclair Z80s, and which just didn't tell you if or if not the
"line" was terminated with or without a CR+LF or any one of them:
Boolean smog, the way out of which consisting of frustrations by trial
and error; and perfectly avoidable such.
Or to try a perfectly "pc" comparison - I read a number of Linux
instructions by now which for me sounded like Chinese: if you wouldn't
know the precise pitch of the expression (or the presumedly perceived
knowledge of it) you'd never understand the meaning.
Whatever the reasons are (I suspect the predominance of programmers',
as opposed to users', angles of view, and years of in-group discussions),
the consequences are serious - it steers the development away from the
rationality of the Command Line Interface towards the seemingly more
easy (and certainly more bloated) GUI; and into a hopeless competition
on this field with that other bloatware emperor.
// Heimo Claasen // <[EMAIL PROTECTED]> // Brussels 1999-11-27
HomePage of ReRead - and much to read ==> http://www.inti.be/hammer
To unsubscribe from SURVPC send a message to [EMAIL PROTECTED] with
unsubscribe SURVPC in the body of the message.
Also, trim this footer from any quoted replies.
