doug@terak.UUCP (Doug Pardee) (02/14/85)
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!dougdarrelj@sdcrdcf.UUCP (Darrel VanBuer) (02/20/85)
The way to find multiple bugs in one run in an interactive environment is to
go even farther into an integrated interactive environment. A premeire
example is Interlisp (especially Interlisp-D on a workstation, but was just
as doable in Interlisp 10). The way that Interlisp acheives this (there are
probably other ways) is that all tools run in a single environment (primary
tools: editors, debuggers, incremental compiler, compatible interpreter, a
history list for commands [including results and how to UNDO many commands],
and an object inspector).
A typical scenario in testing new (pieces of) programs is
* write code,
* possibly compile all or part (the trade off is speed of execution versus
granularity of debugging; Interlisp can only break at the entry to a
function, so errors inside a compiled function back up to the entry point;
some other Lisp workstations can break in the middle of compiled code, but
this requires integrating a decompiler or disassembler into the debugger and
require the programmer to know both the language and the detailed machine
model used by the compiler--these are both legitimate design decisions)
* Invoke a test case (or run a loop against a file of test cases, etc)
* Something goes wrong, often causing an error (if not, set breakpoints
to create an artificial error, and use history to run again). These errors
may be "fundamental" like arithmetic on a character string, or programmer
checks (e.g. (if "malformed state test" then (SHOULDNT "Bad input to FOO"))).
As a result of the error, you are (normally) dropped into the debugger (it's
always there), where you can examine the entire state of the system, edit
and recompile pieces of the code. Because the debugger is a first class
component of the system, you can make multiple retries of the faulty
function without losing your place, "force" the right answer out of the
debugger as the return from any function on the stack. If the logical error
is "close enough" to the system detected error, you can often repair any
damage, fix code and resume (not restart) execution as though there had
never been an error, the system goes on and breaks on the next (unrelated)
error. I have occasionally repaired more than half a dozen errors in a
"single" run of a test case in a series of such diversions into the debugger.
The key features in making such debugging possible are:
1) A way to move from tool to tool (even csh job control would be
adequate)
2) A debugger which permits fairly radical repairs to the runtime state,
including flushing portions of the stack
3) The ability to dynamically link revised code fragments into the test
system
Beyond that, it's mostly a matter of making the tools easy enough to use
(e.g. a debugger which requires making all repairs in terms of absolute
octal addresses and data would hardly be usable above the assembler level,
and barely usable even at that level). As an example of convenience in
integration, the Interlisp D environment can get you into the editor on a
particular function by pointing to the function on the stack with your mouse
(you don't even have to remember which file contains it). The large display
and mouse make for an easier to use method of "job control" than csh because
most jobs correspond to logical windows on the screen, and you switch by
pointing at them. While this doesn't really change what you can do with
your tools, it can make it enough easier to use them that result tends to be
a qualitative change (like model T and rutted dirt roads vs contemporary
cars and the Interstate freeway syst).
--
Darrel J. Van Buer, PhD
System Development Corp.
2500 Colorado Ave
Santa Monica, CA 90406
(213)820-4111 x5449
...{allegra,burdvax,cbosgd,hplabs,ihnp4,orstcs,sdcsvax,ucla-cs,akgua}
!sdcrdcf!darrelj
VANBUER@USC-ECL.ARPA