Older blog entries for dwragg (starting at number 2)

When I wrote the first entry to this diary, I planned to follow it up reasonably regularly. I didn't, but that is partly because I spent most of December on vacation. The new year seems like a good time to try again.

So to begin with, a few impressions gathered during that vacation.

  • For two weeks, I played at being a tourist in London and England, the city and country I lived in for most my life, doing all the tourist highlights. England really is an expensive place to be a tourist, but overall seemed decent value for money.

  • I drove a lot. I hadn't driven for almost 2 years, and wondered how I would find it. It was fun. The roads were clear, the weather was good, and I was driving through some pleasant places, which probably had a lot to do with it being fun.

  • I spent Christmas with my parents in London. I wasn't there last year, and missed it greatly. There is something strangely magical about watching TV with a full stomach and a decorated piece of tree in the room.

  • I returned to Moscow, where I now live, shortly before the new year. Three weeks away was enough to restore the sense of foreignness I felt when I first came here, the feeling was short lived.

slamb has a point.

In my previous article, I was referring to debuggers as tools for single stepping a running program, inspecting data, setting breakpints and watchpoints, etc. When programming in C and C++, I did use debuggers as slamb describes: for obtaining stack traces upon segfaults. But in the last couple of years, the majority of my development has been in Java, where exception stack traces make use of a debugger for this purpose unnecessary. And before that, when I was mostly programming in C, I implemented a simple stack trace facility, a bit like the glibc libSegFault or the Linux kernel Oops reports, and used it in a few projects (multithreaded programs, since at that time on Linux, threads and gdb did not mix well, and multithreaded core files did not work at all).

So I was referring to debuggers in a particular sense, but in my defence, I think the same sense was used in the articles which I linked to.

Debuggers considered harmful

In a recent article, Bob Martin talks about the interaction of Test Driven Development and debuggers.

In an old post to linux-kernel mailing list, Linus Torvalds opines on the use of debuggers in kernel development. But I believe that his arguments, if they are valid at all, may apply more generally. Kernel development is not qualitatively different to the development of any large, complicated piece of software, with strong stability, performance, and compability concerns and real-time constraints, though it is special in the way that it brings all of these issues together.

The arguments presented by the two essays have a lot in common: Essentially, debuggers encourage the bad habits that lead to bugs (which reminds me of the argument that more roads mean more traffic).

I've very rarely used any debugger. I find that most bugs are either very easy to resolve, or very hard to resolve. For the easy cases, there is no need for the helpthat a debugger provides. For the hard cases, the debugger doesn't actually help: bugs are usually difficult to resolve because they are timing dependent, involve race conditions, or relate to subtle conditions in large amounts of data, where the cause is very distant from the immediate problem ("how did it ever get into that state?"). Maybe in the future, more sophisticated debugging tools will help with these difficult bugs, but I'm not optimistic: It seems more profitable to pursue design and programming techniques to make these bugs less likely to occur in the first place.

I think that Test Driven Development probably serves to separate these classes of bugs even further. Once the implementation passes a reasonably comprehensive set of tests, the remaining bugs are either really really easy, or really really difficult.

I would expect that the situation where debuggers are most legitimate is the writing of exploratory and "throw away" programs, where it is assumed that the the programmer will always be there to sort things out if the program fails, and a debugger is the ideal tool for sorting things out. It's interesting that in the world of scripting languages, where such programs are most common, debuggers do not seem to be widespread. For instance. while there are debuggers for Perl (ActiveState has one), they do not seem to be a part of the standard Perl development toolkit, in the same way that they are part of almost any C/C++ development suite.

On the other hand, the dynamic languages crowd (especially Lispers) advertise their ability to examine programs and their data at run-time, and modify both of them without restarting. In this case, the development environment does not merely include a debugger, but subsumes it into the language.

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!