The Human Problems of Debugging
Why is the current presentational model somewhat out-of-synch with our mental model? To explore that we need to look briefly (in this paper, more extensively in practice) at the human problems of debugging.
One of the more complex problems in program design is the notion of change-of-state. As human beings, we are not particularly good at managing complex state. When that state is temporal, we must essentially understand the state changes over time, and try to deduce the behavior of the system. We watch program flow in order to understand state, and study state to understand program flow. The existence of modifiable state is certainly a contributor to the complexity of software, hence the advantage of functional languages and non-procedural languages in terms of constructing clean, understandable programs.
But languages like ML Prolog, and F#, are not mainstream programming languages, no matter what their advantages might be. Programming is done in languages like C, C++, C#, and Visual Basic. These languages require various transformations of our mental object model into a syntactically correct compilable and executable representation. As Boehm pointed out, there is a feedback loop (long disparaged) between the design and coding phases of any project. This means that our original mental model is being constantly redefined during the coding process, often in ways that we lose track of. The imperative style of coding prevalent in mainstream languages means that our mental models, and our objects, tend to take on imperative shape. And from this resulting structure, we must, during the debugging process, reverse-engineer the original structure, follow the logic and control flow, and build a mental model of what is actually happening.