-The main deficiency of DDT is that, although is names include the word
-"dynamic", its operation is really static. The application program can
-run freely, but when the programmer wants to see what is taking place,
-the program must be stopped. Although the real interest may be about
-changes on a gross scale, perhaps thousands of program statements, if
-one does not know exactly where the program is misbehaving, one may be
-required to suspend execution of it every few instructions to examine
-variable in order to obtain a true picture of the program's behavior.
-This the programmers see *not what is taking place*, but *what has
-taken place*, and through small windows at that. This is inefficient,
-and the programmer can become bogged down in detail that hinders the
-discovery of the true problem. The situation can be improved with the
-use of breakpoints that allow the program is execute freely until a
-breakpoint is reached, at which point the program halts. DDT is a
-powerful tool but still leaves much to be desired in a debugging tool.
-
-ESP[^4][^5] (Execution Simulator and Presenter) is one solution to the
-static problem. It really is dynamic is that large amounts of data are
-constantly being displayed for the programmer while the program is
-being executed (actually, simulated). The information is presented in
-graphic form to improve readability and reduce confusion. A user of
-ESP may watch areas of the display where data of particular interest
-are being presented. One also has many options including control over
-the speed of execution, the type of quantity of data displayed, and
-special (more flexible than just a breakpoint) conditions for halting
-execution. In this way one can structure and control the picture
-presented to more easily understand what the simulated program is
-doing. And that is one key step in the process of debugging.
+The main deficiency of DDT is that, although is names include the
+word "dynamic", its operation is really static. The application
+program can run freely, but when the programmer wants to see what is
+taking place, the program must be stopped. Although the real interest
+may be about changes on a gross scale, perhaps thousands of program
+statements, if one does not know exactly where the program is
+misbehaving, one may be required to suspend execution of it every few
+instructions to examine variable in order to obtain a true picture of
+the program's behavior. This the programmers see *not what is taking
+place*, but *what has taken place*, and through small windows at
+that. This is inefficient, and the programmer can become bogged down
+in detail that hinders the discovery of the true problem. The
+situation can be improved with the use of breakpoints that allow the
+program is execute freely until a breakpoint is reached, at which
+point the program halts. DDT is a powerful tool but still leaves much
+to be desired in a debugging tool.
+
+ESP[^4][^5] (Execution Simulator and Presenter) is one solution to
+the static problem. It really is dynamic is that large amounts of
+data are constantly being displayed for the programmer while the
+program is being executed (actually, simulated). The information is
+presented in graphic form to improve readability and reduce
+confusion. A user of ESP may watch areas of the display where data of
+particular interest are being presented. One also has many options
+including control over the speed of execution, the type of quantity
+of data displayed, and special (more flexible than just a breakpoint)
+conditions for halting execution. In this way one can structure and
+control the picture presented to more easily understand what the
+simulated program is doing. And that is one key step in the process
+of debugging.