From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <94c2b292277a59c66ae80f4877e1ab8e@proxima.alt.za>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] GNU Make
Date: Thu,  3 Jun 2004 17:40:39 +0200
From: lucio@proxima.alt.za
In-Reply-To: <7359f049040603081676be64a6@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Topicbox-Message-UUID: 94219494-eacd-11e9-9e20-41e7f4b1d025

>> Because there is madness at the end of that road, too?
> 
> why?
> 
Well, not all error conditions require an unfamiliar user to attend to
them in great detail.  In particular, by making each error message
extremely "clear, helpful and detailed" one is targeting an audience
that may be thoroughly disinterested.

>> Yes, that is all extremely human-friendly, but one can't invest
>> infinite amounts of computing power in interpreting error messages
>> that do not reach the user.  Or that the user is going to ignore
>> anyway.
> 
> what are you talking about?
>  
There are very few instances where MS Windows error pop-ups actually
say "Press RESET".  Some of them suggest it indirectly.  Yet, largely,
pressing the RESET button is in my experience what the user does in
response to error message with the slightest technological slant.

>> Once again, my opinion is that errors ought to be reported as
>> concisely as possible within ambiguity constrains and that it ought to
>> be possible to request the additional details separately.  But I seem
>> to be in a minority.
> 
> as concisely as possible is '23'.  are you advocating that?

I would be, if it wasn't already taken.  What I don't want is a
message that requires me to use the google search engine (yes, I know
it's a cheap shot) to locate the knowledge base information that tells
me there is a bug in the program I'm using.  I'm suggesting that a
help system that can explain, on demand, what might have triggered an
error condition may be preferable to being offered two paragraphs of
explanations that I have little use or understanding for.  But
providing such a help system is very difficult if each error return is
subtly differently worded from its immediate neighbour that attempts
to convey the same information.

> the errors are there *for the user*, not for programs.
> corrupting a system that works hard -- and mostly
> successfully -- to deliver clear, helpful, detailed error
> messages, in order to make some bastard subsystem
> spend less CPU time *for users accustomed to unhelpful
> messages* (for such is unix's lot) is perverse.
> 
Oh, I have no doubt I'm perverse.  But that does not mean that there
aren't different ways to see this issue, depending on what one's
objectives and possibly principles are.

> APE can go jump in a lake.  
> 
It's a stepping stone, dropping it in depths of the lake is not going
to help in crossing the lake without getting wet (facetious reference
to ability to walk on water omitted).

++L