Beautiful Code [314]
Nonetheless, finding failure causes in program state was only a detour toward the ultimate end. It was Holger Cleve who gave this technique the ultimate touch. Since he knew the failure-causing variables, he would simply trace back their values to the statements that caused them—and presto! We would end up in the statements that caused the failure: "The statement in line 437 caused a loop, which again caused the failure." Now this was true magic—and this paper had no trouble getting published, either.
So, as we had a complete automatic debugging solution on our hands, why do people today still use interactive debuggers? Why didn't we go public and become millionaires with automated debugging?
Beautiful Debugging > A Prototype Problem
28.8. A Prototype Problem
There is a difference between what you can do in a lab and what you can do in production. The main trouble with our approach was that it was fragile. Very fragile. Extracting accurate program states is a tricky business. Suppose you are working on a C program that just stopped in a debugger. You find a pointer. Does it point to something? If so, what is the C data type of the variable is it pointing to? And how many elements does it point to? In C, all this is left to the discretion of the programmer—and it's awfully hard to guess the memory management used in the program at hand.
Another problem is to determine where the program state ends and the system state begins. Some state is shared between applications, or between applications and the system. Where would we stop extracting and comparing?
For lab experiments, these issues could be addressed and confined, but for a full-fledged, robust industrial approach, we found them insurmountable. And this is why, today, people still have to use interactive debuggers.
The future is not that bleak, though. Command-line tools that implement delta debugging on input are available. The ddchange plug-in for Eclipse brings delta debugging on changes to your desktop. Researchers apply delta debugging on method calls, nicely integrating capture/replay with test case minimization. And finally, through all these automated approaches, we have gained a much better understanding of how debugging works and how it can be done in a systematic, sometimes even automatic way—a way that is hopefully most effective, and maybe even "beautiful."
Beautiful Debugging > Conclusion
28.9. Conclusion
If by any chance, you are forced to debug something, you can strive to make your debugging experience as painless as possible. Being systematic (by following the scientific method) helps a lot. Automating the scientific method helps even more. The best thing you can do, though, is invest effort into your code and your development process. By following the advice in this very book, you will write beautiful code—and, as a side effect, also achieve the most beautiful debugging. And what is the most beautiful debugging? Of course: no debugging at all!
Beautiful Debugging > Acknowledgments
28.10. Acknowledgments
I'd like to thank the students with whom I have experienced beauty in debugging tools. Martin Burger took great part in the AskIgor effort and implemented the ddchange plug-in for Eclipse. Holger Cleve researched and implemented automated isolation of failure-inducing statements. Ralf Hildebrandt implemented isolation of failure-inducing input. Karsten Lehmann contributed to AskIgor and implemented isolation of failure-inducing program states for Java. Dorothea Lütkehaus wrote the original version of ddd. Thomas Zimmermann implemented the graph-comparison algorithms. Christian Lindig and Andrzey Wasylkowski provided helpful comments on earlier revisions of this chapter.
Beautiful Debugging > Further Reading
28.11. Further Reading
I have compiled my experiences on systematic and automatic debugging in a university course. This is where you can learn more about the scientific method and delta debugging