Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/5/84; site terak.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!princeton!lognet2!seismo!hao!noao!terak!doug
From: doug@terak.UUCP (Doug Pardee)
Newsgroups: net.works
Subject: Re: Returning to Batch Processing
Message-ID: <376@terak.UUCP>
Date: Thu, 14-Feb-85 13:40:38 EST
Article-I.D.: terak.376
Posted: Thu Feb 14 13:40:38 1985
Date-Received: Sat, 16-Feb-85 07:15:03 EST
References: <633@topaz.ARPA>
Organization: Terak Corporation, Scottsdale, AZ, USA
Lines: 50

Good heavens!  My original posting which indicated that I felt that
interactive programming was a significant contributor to program bugs
brought an unexpected (but I should have expected it) response.

Folks, I don't want to return to those "good ol' days".  No way!

What I'm suggesting is that the clouds of one-run-a-day batch processing
had some silver linings which blew away along with the clouds.  And
that perhaps we should find a way to combine the best aspects of both
current and past programming environments.

The most obvious ways in which interactive programming is worse than
batch are:
 1)  with interactive programming, you see 24 (or so) lines of your
     program at once.  Nobody keeps current printouts, and even they
     who do have current printouts use the "tube" for debugging instead.
 2)  with interactive programming, there is enormous temptation to "make
     a little change and try again", without thinking problems through.
 3)  since the programs are intended to be run under the watchful eye
     of a human, a much higher level of bugs and quirks is tolerated.

A less obvious aspect is that interactive programming encourages the
production of scads of "offspring" from each program.  That is, rather
than modifying the original program to deal with a new situation, the
program is simply copied and then modified.  Each copy then ends up
being maintained separately, and a bug fixed in one is left unfixed in
another.

Another not-too-obvious aspect is that interactive programs, by their
nature, process much less data in any one run than do batch programs.
With batch programs, we'd build up test files with everything we could
think of and feed it into the program in one run.  With most interactive
programs, you have to sit at a terminal and "spoon-feed" each test case.
So the amount of testing that gets done is limited.

And now for the point that'll certainly draw the most fire.  I've got
my flak jacket on, so here goes...

In interactive debugging, you find one bug at a time.  Seldom do you
find multiple bugs in one run.  Even in the "good ol' days", most
programmers were satisfied to find one bug at a time.  But it *was*
possible, if you were diligent and patient (which I, for one, was),
to dig through a memory dump and find many problems with one run.

I'm not looking to bring back the memory dump.  What I *would* like
to see, though, is some form of interactive debugging which promotes
the finding of more than one bug in a run.  No, I don't have any
suggestions.
-- 
Doug Pardee -- Terak Corp. -- !{hao,ihnp4,decvax}!noao!terak!doug