Thread by @NickFitz

Some people quote Kernighan’s “The most effective debugging tool is still careful thought, coupled with judiciously placed print statements”, but he said that in 1979. Modern debugging tools are to the tools available then as an ARM chip is to a 6502. (You still have to think.)

His preceding sentence was “The debugger adb is useful for digging through the dead bodies of C programs, but is rather hard to learn to use effectively.” Unix for Beginners 2nd ed. ualberta.ca/computing-scie… (PDF) p.23

Note: that version of the document has an abstract dated 1997. In fact, several online versions seem to feature this. But the introduction states “In cases of doubt, this paper describes Version 7 UNIX” which was released by Bell Labs in 1979: en.wikipedia.org/wiki/Version_7…

Here’s the tutorial for adb from 5 May 1977: wolfram.schneider.org/bsd/7thEdManVo… (PDF). This seems to correspond with the copy in the /usr/doc/adb/tut directory of the Version 7 UNIX source tree, at minnie.tuhs.org/cgi-bin/utree.…

The first procedure described involves debugging from a core dump: a file of the entire contents of memory at the point your program crashed.

Although you still might resort to this approach if you’re a systems programmer, very few developers nowadays would ever need to do this.

One of the difficulties of debugging from a core dump is that, as we all know, where your program crashed might be far from where you introduced a bug.

So if that’s all you have, thinking about how you got there and using judiciously-placed print statements isn’t a bad move.

One of adb’s limitations (in 1977) is that “it is currently not possible to plant breakpoints at locations other than function entry points without a knowledge of the code generated by the C compiler”. So you can set breakpoints, but with some difficulty.

OTOH, you can do things like only break on the nth time past, and automatically execute certain adb commands on break, and so forth. So *by the standards of the day* it’s actually pretty good.

But for a lot of problems, you’re still going to fix it faster with thought and print.

Now consider what I’m just about to do with a modern debugger - in today’s case, @phpstorm from @jetbrains, connecting to a remote PHP application (running on AWS) with Xdebug.

First, a couple of method breakpoints: I want know when those methods are entered, from my code or elsewhere AND either in the base class or my subclasses thereof, so I can check I’m passing the correct values in. But I don’t want to know when other stuff uses that method.

No problem; I know certain values I’m passing in, that willingly come from my code, so I add a condition to the breakpoint.

Print statement version:

if ($somevar==‘foo’) {
echo(‘Called bar with foo’);
}

…which I’d need to remember to remove once I’m done.

Separation of concerns. Remember that principle?

The fact that I’m interested in knowing what a function receives for the sake of debugging shouldn’t impinge on the actual source code of that function. It has nothing to do with that function. My business is not its business.

I really should actually be doing some debugging rather than tweeting about the history thereof, so I won’t bother going into the various other debugging techniques and tools I’ll be using today.

My point is just that Kernighan’s comment made sense back then, in the context of having adb as your only debugging tool (or one of few). But it’s not really relevant today.

Or rather, the bit about careful thought is still relevant, but the bit about judiciously placed print statements isn’t. Use the careful thought to decide how to deploy the powerful capabilities now available. Don’t stick print(), echo(), or console.log() all through your code.

Breakpoints, with or without conditions, logpoints (where available), watches, (when browser debugging) subtree mutation breakpoints - none of these things were available in any meaningful sense to Unix programmers in 1979.

Now, you have them. Learn how to use them.

If nothing else, it’ll save you the embarrassment consequent on accidentally committing a forgotten “log(`SUPER_SECRET_KEY`)” to a public repo on GitHub ;-)

And that, my friends, is how you accidentally research a bunch of Unix history then ramble away on Twitter for forty-five minutes when you’re supposed to be working, just because of something you were reminded of by a tweet from someone you don’t even follow 🙂
/end

s/willingly/will only/

Probably break the thread now 😕