Today I stumbled upon a great article about the Python debugger, pdb. As the author points out, finding easy-to-read introductions to pdb can be quite hard
Unfortunately, most discussions of pdb are not very useful to a Python newbie -- most are very terse and simply rehash the description of pdb in the Python library reference manual.
I'm a big fan of debuggers. I've previously worked with C# and the Visual Studio.NET debugger repeatedly impressed me. Jumping around code while changing it, deleting it and even moving backwards is quite impressive and it was a valuable tool for me at the time.
However, reading about pdb today made me realize that I've never actually needed that tool for Python.
I usually write Python with a bottom-up design as described by Paul Graham. Bottom-up programming combined with the interactive shell works pretty well for me.
The results are well-defined, small functions and such functions are easy to test. In fact I often start out by writing the doctests for my functions. This is easy when programming bottom-up.
The result is that I never need a debugger. I never have the need to step into and inspect a variable, change it and retry.
Graham has an interesting note on that other kind of program design, emphasis mine:
If some component of a program grows beyond the stage where it's readily comprehensible, it becomes a mass of complexity which conceals errors as easily as a big city conceals fugitives. Such software will be hard to read, hard to test, and hard to debug.
This made me think; could it be that the complexity in the .NET debugger is necessary because of the way we write .NET programs? I.e that the programs written in .NET are hard to debug and thus a powerful debugger is required?
I think I know the answer.