You Need a Debugger to Change the World

Following links from the latest Subtext demo, I came to Martin Fowler’s article “Language Workbenches: The Killer-App for Domain Specific Languages?”. It’s well written and thought provoking, like everything else Martin writes, but I think there’s one glaring oversight. Two thirds of the way through, he says:

…there are three main parts to defining a new DSL [Domain Specific Language]:

• Define the abstract syntax, that is the schema of the abstract representation.
• Define an editor to let people manipulate the abstract representation through a project.
• Define a generator. This describes how to translate the abstract representation into an executable representation. In practice the generator defines the semantics of the DSL.

That’s great—but #4 should have been:

• Create an inspector that allows people to debug their DSL's behavior in its own terms.

Now, you could claim that the debugger was implied by #2 (the editor), but i practice, it never works that way. Time and again, I see people struggling with systems that don’t provide tools for debugging: Makefiles, Antfiles, config.xml files for servlet containers, and on and on and on. When something goes wrong, the only options are (a) tweak it until it converges on what you wanted, or (b) debug the implementation of the nice abstraction you were just thinking in.

I think that the inability of today’s C++ debuggers to display something useful when confronted with templated code is the singlest biggest obstacle to their wider use. I think that Java made a horrible mistake in deciding to erase type information when compiling generics, so that what’s actually executing can only say, “Yup, it’s another Object.” Extensible languages could revolutionize software development, but it’ll only happen if we focus on closing the debugging gap.

So, anyone looking for a Ph.D. topic? ;-)