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

> i am confused.  what about all that information you can have
> because it's a string, things that very from invocation to
> invocation?  unix says 'bus error'; plan 9 tells you the pc of
> the fault, or in other cases the file name that failed, the
> fp trap condition, and so on and so on. it's not some
> set of 23 errors; it's a huge informative space. why give that
> up?

Because there is madness at the end of that road, too?

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.

I guess my faith in artificial intelligence is not sufficient and my
impression is that computing devices are beginning to communicate with
each other and don't cope well with fuzzy completion messages.

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.

++L