Measuring language complexity: Do you need a debugger?

When people are asking for a debugger for language X, practically it means that the usage of language X has gotten sufficiently complicated that mere inspection is insufficient for diagnosing problems.

I alluded to this when I said that XML is code.  People want to be able to debug their XML: debug the XSLT transform process; debug the interpreter of the XML file, etc.  That's a statement about how complicate the XML input must be.

The debugging techniques are a useful metric for language complexity. Here's a possible (and likely very debatable) spectrum:

Technique	Description	Examples*
(simplest) Pure Inspection	Some languages are simple enough that issues can be resolved via just inspection.	Config files / .ini files
In / out testing and inference	Sometimes sending a lot of inputs through and analyzing the outputs is enough. This may be coupled with  some decomposition. The key here is that you don't need to actually "step through" the language and set breakpoints in it.	Excel spreadsheets, Regular expressions, HTML
Logging / printf-style	This is like in/out testing, but the execution of the program also logs intermediate state in addition to the inputs/outputs. Most languages of this complexity could benefit from more advanced debuggers; but the cost of developing the tool must not outweigh the benefit (else a more advanced debugger would have been developed).	.bat files, layout, C++ templates and macros (logging via build errors)
Basic debugging	This is primitive breakpoints, callstacks, variable inspection.	C++, VB, C#, Java
(most complex) Advanced debugging	This is advanced debugging techniques like time-travel, omniscient, Edit-and-Continue, etc. These lower the cost of developing in a language.

*= you can always wish that a language had more debug support. For example, sometimes I wish I could "step through" HTML layout. When a language does not have sufficient debugging support; it doesn't get used to its full computational potential. In other words, people shy away from features that they can't debug.

Comments

• Anonymous
  February 06, 2007
  So is Microsoft working on a back-in-time debugger or what? GDB is starting work on one, and there are a number of simulators. Green Hills Software already has a fully functioning product.

• Anonymous
  February 06, 2007
  No, there is no such tool for .Net. My point here is that by the time you want a back-in-time debugger for your language, that means the language has "achieved" a certain complexity level. It's a twist on measuring complexity. Traditionally, we measure language complexity by the computational power ("they're both turing complete"). Another way to measure it is by the toolset required to really utilize the language.