Re: [9fans] ... in the Kingdom of Sources

[Lucio De Re <lucio@proxima.alt.za>]

On Thu, Sep 11, 2003 at 08:48:43AM -0700, rob pike, esq. wrote:
>
> precisely.  the approach taken by the C standard implies you're
> supposed to error check the conversion and presumably yell about it,
> maybe exit.  but the great majority of text processing code is
> interactive - editors, browsers, terminal programs - and must soldier
> on.  the `error rune' solution not only solves the problem of
> soldiering on, it provides a way to yell and takes no code at all in
> the application.  (if you really want to stop processing on errors,
> it's still a simple check; it's just that you almost never have to
> bother to check and i can't think of a single program that does.)
>
I'm willing to concede rob's point.  In an interactive environment
error checking is counterproductive if a user response would be
preferable.  But you can't design a standard around "the great
majority of text processing code" without sacrificing the ability
to deal with the exceptions.

I've done a good deal of programming using Don Libes' Expect and
it's quite a lesson in the cost of relying in real intelligence to
deal with contingencies.  MS Windows programming really brings the
point home: there aren't many operations I would feel comfortable
automating unsupervised.  Whereas forgetting the "close" function
in a pop-up error message isn't too serious, being unable to detect
an out-of-memeory or out-of-disk-space condition in a background
task can be catastrophic.

I had a print spool completion pop-up appearing at the same time
as the screen saver Ctl-Alt-Del prompt pop-up: I didn't have to
identify myself before acknowledging the print completion, for
example.  Is something like that worth worrying about?  Not really,
but is not perhaps symptomatic of a programming style where all
contingencies are passed on to the user except when the user isn't
available, in which case they are merely glossed over until disaster
strikes, at which point the RESET button comes to the rescue?

Whereas in Plan 9 (and Unix) it is easy to distinguish between
interactive tools and command line utilities, in Windows the
distinction is very thoroughly and almost certainly intentionally
blurred.  In my experience very few Windows programmers actually
code with unattended, unsupervised operation in mind.

I think Doug's concerns, like mine, are in laying down rules that
make it possible to deal with the unexpected programmatically.
The ANSI-C committee, like the ITU-T, seemingly strive to remove
all possible ambiguity instead of relying on the human brain to
make a choice.  It is a sane approach to dealing with computers,
even though the compromises made in this quest may be atrocious
and, I'm sure, occasionally mistaken.  As compromises have to be,
when trying to address conflicting requirements.

What may help considerably is the acknowledgement that different
needs can be addressed by different solutions.  For example, Perl
is a prime example of a language designed to concoct one-off
solutions.  Some of us have to do this on a regular basis (I know
of one instance where data conversions from continually changing
formats is a daily occurrence) whereas others can indulge in
monumental works to be used for decades.  Writing monumental works
in Perl should be discouraged, I'm sure, while Limbo may be quite
unsuitable as an instrument to write short sysadmin scripts.

Another point worth raising (I think it was Geoff Collyer who first
pointed it out) is that graphic programming is still at the level
of assembly code.  A lot of the decision making in interactive
programming is similarly at a very low level and therefore seems
extremely cumbersome.  Somewhere, somehow - I'd expect rob to be
the likely genius to come up with something - somebody will have
the flash of inspiration that leads to second and third generation
graphic languages.  Until then, I think we have to accept that we
don't have sufficient grounds on which to construct "standards"
that address the real problem, we can only base our recommendations
on traditional principles that are undoubtedly obsolete.

++L