discussion:Goals Round III

Mike Prince mprince@crl.com
Wed, 23 Nov 1994 17:41:38 -0800 (PST)



On Wed, 23 Nov 1994, Francois-Rene Rideau wrote:

> I only claim that there is no possible distinction between programming and
> using that would not be purely arbitrary, and inappropriate and useless.

I didn't mean to start a holy war over the distinction between 
programmers and users.  The line is completely arbitrary.

I wouldn't go so far though to say there isn't a distinction and group 
everyone together.  A million arguments can be made that users recording 
macros are programming, etc, but I think we all recognize the difference 
between creating an application and the limited "light" programming of 
macros and maybe even shell scripts by "users".

>    Most users don't write programs that need error recovery; or error recovery
> is straight-forward (i.e. if the computation is interrupted, go on when
> possible; if it eats all memory, then the algorithm is definitely wrong).

Every program needs error recovery.  Your program completes correctly or 
there is an error.  We've just been taught that if a program doesn't work 
it's our fault and we should try new parameters or somewhat.  Instead the 
program should guide us through with its error recovery routine and get 
the correct parameters to run.

> Programmers shouldn't mangle with failures that are not related to the
> algorithm they use. If network security is not good enough to ensure the
> integrity of the computation, then let the system not distribute the
> computation on the net; but do *NOT* introduce failure recovery where there is
> no need for one; let it be transparent.

We introduce one of my "new" directions.  I believe the programmer 
should be aware that the code is going to be distributed, and be aware of 
possible pitfalls.  Including that of creating a "thread" and having it 
never join.  From what I've read from Fare, he seems to favor very 
deterministic behavior from programs.  These are at odds, but not 
exclusionary.

The low level OS will deal with recovery mechanisms, on top of which 
other languages "exist".  A high level language which favors determinism 
may limit the risks it takes during execution by using a subset of the 
OS's capabilities.  Other languages may be braver (or more stupid) and 
distribute their computations to less savory parts of the network.  When 
the failures occur, someones got to deal with it, and I don't think 
having the program just stop running and a "bomb" appear of the screen is 
satisfactory.  But by the same token, different apps may employ 
different recovey mechanisms.  I am leery about an OS being capable of 
a having a general recovery rule which will satisfy all application 
requirements.  Unless of course that rule will be to let the app decide.

>    Now, if there *is* an intrinsic need for error-recovery in some program,
> then the programmer must foresee the possible errors anyway; and the language
> he uses should have capabilities to cope with them (or he chose a bad language
> for his task).

Exactly, let the programer earn his pay and deal with the errors.

>    As for programming distributed databases (which is quite different from
> math problems)

Up till now it's been different because computation has been limited to 
the same machine for most applications.  But what happens when most 
programs are broken into pieces and farmed out?

> Then, yes, different
> programmable policies should be available, and any willing programmer/user
> should be able to access them.

Bingo, apps may pass errors along to the standard recovery mechanisms, 
but the point is apps get to make those decisions, and none are forced 
upon them.

> > So.......In answer to the previous posting, users *may* become aware of 
> > failures (your videophone link fails due to the satelite being shot 
> > down), the programmer will probably become aware, and OS's job will be to 
> > take directed remedial action.
> In case of failure, let the system warn the user, and interact to recover
> (saving the program for possible future failures), and not ask the user to
> foresee all possibilities (unless he really wants to).

Back to my previous equation, the system tells the app, the app may tell 
the user.  BTW, a simple app would just feed the error to the standard OS 
error handler.  I stand by my opinion that the app should have first 
crack at handling errors.  Not every error can be recovered.

> > Am I confusing the issue more?
> I *think* you are.
Confusion is the first step in learning; to know what you do not know.

Mike