Mitch Walker provides an excellent screencast showing the use of components within XNA GSE. However, looking at it I kept thinking "Shouldn't this be a domain-specific language"? I have to be careful here because, obviously, drag-and-drop designers have proven to be successful. But using the design surface as nothing but a bag for instances and the Properties window as a declarative manipulator... I'm just not sure that's any clearer (and it certainly seems limited in flexibility) than a DSL.
This morning, even before coming across the screencast, I was thinking about the tension on this blog between: concurrency (the issue that I think is going to come to dominate professional programming), Ruby (a language which I think is coming to influence the mainstream), and Domain-Specific Languages (a technique that's one of the "lost treasures" of the 70s-80s programming era).
One of the most regrettable things about current mainstream languages is that exploring language possibilities is a huge task: you want to explore "what if sprites were first-class" and you have to start by defining whitespace and digit tokens. One of the reasons "Little Languages"/DSLs are not as common an approach as they were in the 70s and 80s is because, in those days, whitespace and digits were a lot closer to the problem domains! Dealing with weird character sets, packed data, and custom binary representations was a very customary part of problem-solving. Nowadays, those types of issues are rarely at the forefront.
This put me in mind of this post on Modular Compilers and even more so, LISP macros. Code generation goes a little way, but my big problem with tag-based code generation is that once you get into semantic complexity, the difficulty inverts and suddenly you think "Why am I not generating this with a compiler tool?" (Which, perhaps, points the way towards a possible answer based on refactoring?)
This is one of those "no conclusion" posts...