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:
|(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.