Code as Screenplay

Giles Bowkett writes

Debugger support is like nail-biting support, or farting-in-public support. Its absence is a feature. You want to avoid supporting bad habits. If programmers have to break their bad habits, that's a good thing.

I have a confession to make: I bite my nails. That's a bad habit, and I readily admit it. I also use a debugger. That's not.

Let me explain. Giles' argument seems to rest on this point:

Debuggers are based on the idea that the code base has enough places bugs could happen that the work of locating the bug is involved enough to justify machine assistance. This is not true of well-tested code. It is not true of code you understand, either.

What Giles glosses over is how you come to understand the code in the first place. Nothing helps you understand code - whether you wrote it or someone else did - better than stepping through it in a debugger. Since Giles is a sometime screenwriter, maybe this analogy is appropriate: reading the code is like reading a screenplay. Writing tests is maybe like drawing storyboards (they help you visualize the final product). Using a debugger is like actually watching the damn movie. With a jog wheel so you can slow it down. And no matter how good a screenwriter you are, no matter how good your director's storyboards are, when it comes time to cut the film you're going to find out that you didn't understand the movie as well as you thought you did, and you're going to need to watch the footage, sometimes frame by frame, and modify the movie accordingly.

Programs are the same way. Writing tests and reading code show you your program the way you want it to be, but only a debugger shows you the way your program is. Maybe screenwriters sit around in bars in LA and talk about how real filmmakers just read scripts, and the movies themselves are a crutch - me, I guess I like crutches.

See also: Patrick Collison, Ben Matasar, and Slava Pestov.

Comments

[Rick DeNatale]

Giles seems to have stirred up the current and former Smalltalkers on this, a few more:

Pat Mueller: http://www-128.ibm.com/developerworks/blogs/page/pmuellr?entry=the_vice_of_debugging

And me
http://talklikeaduck.denhaven2.com/articles/2007/10/18/true-confesssions

[Amr]

This is one of the best descriptions of a debugger that I've seen so far... Brilliant!

I remember the euphoria of using a debugger to step through some vile compiler code (C) I'd written long time ago.. knowing I'd never have to mess with printf's again for the foreseeable future was a liberating feeling!

I didn't think I needed it either until the complexity of the project hit a certain threshold, and I decided to get over my phobia of the seemingly arcane incantations that were required to use the beast (it was on a VAX-8530 ! )

Sometimes, ignorance is bliss...

[TJIC]

Well said!

I can't believe that certain programming languages and frameworks don't have great debuggers. This annoys me about Rails, by the way.

It's like we're travelling back in time from 2007 to 1957. Debugging by printf and logfile?

WT*?

[Giles Bowkett]

"
Nothing helps you understand code - whether you wrote it or someone else did - better than stepping through it in a debugger. Since Giles is a sometime screenwriter, maybe this analogy is appropriate: reading the code is like reading a screenplay. Writing tests is maybe like drawing storyboards (they help you visualize the final product). Using a debugger is like actually watching the damn movie. With a jog wheel so you can slow it down. And no matter how good a screenwriter you are, no matter how good your director's storyboards are, when it comes time to cut the film you're going to find out that you didn't understand the movie as well as you thought you did, and you're going to need to watch the footage, sometimes frame by frame, and modify the movie accordingly.

Programs are the same way. Writing tests and reading code show you your program the way you want it to be, but only a debugger shows you the way your program is. Maybe screenwriters sit around in bars in LA and talk about how real filmmakers just read scripts, and the movies themselves are a crutch - me, I guess I like crutches.
"

This is an excellent comparison paired with illogical sarcasm. First the illogical sarcasm: Screenwriters don't sit around in bars in LA talking about how real filmmakers just read scripts. Screenwriters sit around cafes in LA talking into their cellphones and pretending the cellphones are actually in the process of sending and transmitting voice data. Also, screenwriters generally do not take part in the editing process under normal circumstances.

That's the factual errors, though. The logical flaw is that if the debugger is a jog wheel, screenwriters would be denigrating the editing process, not the film itself. You're conflating a tool which examines and executes code with the application itself. Although the two are tightly integrated in Smalltalk, they are certainly not the same thing. It's pretty easy to take the debugger out of the picture when you actually launch an app, and it's pretty easy to see the logic here.

I think the sarcasm lacks logic because making a point wasn't its intent. I think it was intended to show nothing but disrespect, and that disappoints me.

In terms of the comparison, I can't deny that the jog wheel metaphor makes the Smalltalk debugger sounds like a very powerful feature. I can't speak to that in any detail, unfortunately, as I'm not an expert there. I can mention that I posted about a Rails debugger written in Rails back in February, and posted yesterday about how to hack a ghetto Rails debugger out of RCov and Mongrel. Programmers are taking my post way too seriously, especially in the Smalltalk community. I'm not going to take your debuggers away from you. I'm just saying that I've seen a strong argument in favor of avoiding them.

"
Giles seems to have stirred up the current and former Smalltalkers on this
"

Yes, I have, as well as a small army of programmers on Reddit with some kind of general anti-Ruby axe to grind.

It's very frustrating, actually, because I'm wasting all my time on a post I don't care about and which people are taking much too seriously.

Worse yet, two people who knew me for a couple months apiece (I think) have posted on Reddit that they've seen me code and they don't think much of my skills. I disagree with them, and I think they really don't have a sufficient sample size to accurately judge, but the whole thing is just depressing.

I have no idea why this matters so much to so many people, but it definitely matters more to practically everybody who's commented than it does to me. I am happy to just say, fine, all you debugger fans are right. I just don't care that much. However, I'm mostly worn down by hostility, as opposed to logic. I'm definitely disappointed in the general community by that.

The irony, of course, is that Ruby recently acquired a debugger which is much superior to its prior debugger, in ruby-debug, and additionally may acquire Smalltalky debugging facilities via the Rubinius project.

[Rickon]

"I have no idea why this matters so much to so many people."

It doesn't. It's very easy to post comments and blog posts. Maybe you might not have thought enough about the issue before posting? One option you have is to actually listen to the people who are more experienced than you and maybe learn something.

[Giles Bowkett]

I assumed it mattered to people because the comments are so different from my normal comments.

I think the assumption's logical.

[Tarkan Yildiz]

It is not easy to stay calm, when people write obvious nonsense.

Thank you for your nice posting.

Tarkan

[Michael Latta]

I would say that a debugger as typically presented is a bad habit. A tool that allows you to peer through a peep hole at the current state of an application is pretty much a bad thing. Code understanding tools that allow you to see what is happening within an application are an entirely different beast. Having a jog wheel that can move the execution forward and backward would be invaluable in understanding what is happening within code (especially code not self authored). I have yet to see a system that could perform this feat on a reasonably sized application. Smalltalk had the advantage over many current environments in that the entire language was available at the point of failure. The command line ruby debugger and a few others also have this, but the GUI based debuggers all lack this important issue. When a real app has 1000s of objects to assess and validate against the human assumptions (the cause of all bugs) that test needs in general to be automated. If the language is fast enough the application can do this continuously and a debugger is not needed, discrepancies will be reported automatically. If the language is slow enough you need to do it on the fly, but still with code not eyeballs.