In a discussion with some architects yesterday, I came upon the point that a new form of debugging is needed. So much development these days is data driven, and when something goes wrong you're back to trial-and-error poking at the problem. I'm sure this isn't a completely original thought, but I haven't seen much written about it.
Consider the following three scenarios:
1) You're writing an XSLT transform for some XML data. If you don't get the syntax just right, the cryptic error message often doesn't give much help.
2) You're using a highly templated class library such as STL. If you don't get the syntax just right, the cryptic error message often doesn't give much help.
3) You're writing a hairy SQL "select" statement. If you don't get the syntax just right, the cryptic error message often doesn't give much help.
It's easy to kill a lot of time "debugging" these problems.
The common denominator in these scenario is that your "code" is really just a data declaration. Some "engine" takes that data and performs "magic" on it, and you see the results, be it new XML, machine code, or a dataset. The problem is that there's little visibility into these engines. Wouldn't it be cool if you could "step" through the engine as all the conceptual processing take place?
As I see it, there's two ways this problem could be addressed. Feel free to pop in with others.
1) The engine (be it XSLT, the compiler or the database) could provide a debugger-like view of its processing, letting you see inspect the intermediate data and control each step of the processing. Obviously, writing something like this would be a lot of work. I have seen tools such as XSLT debuggers, but they don't appear to be totally in the mainstream. More importantly, it would be great if other engines could do something similar.
2) The engine could be "instrumented" so that it emits intermediate results in some usable format. For this to really work well, the engines should standardize on some sort of output format. For instance, database engines (be they SQL Server, Oracle, or MySql) should generate the same basic format so that you wouldn't need to wrap your ahead around a completely different format when going from one DB to another. Ditto for compilers.
I know I haven't proposed any actual workable solutions here, but it's a problem space where I often find my mind wandering.