Domain Specific Languages and XML

A couple of days ago Pascal Costanza wrote an interesting reply to Martin Fowler's post ParserFear. Like Pascal, I think Martin misses the point, and I agree that the problem is not that it's difficult to implement a DSL. The problem is that the bang/buck ratio favors other solutions (usually XML). But, I'd also like to point out that even when a DSL would prove useful it's still not enough to go and design your own language.

Creating a DSL from scratch is very likely to be, mostly, a duplication of effort. And it ought to be very difficult to justify the cost of that effort considering that there are so many well-designed, easily embedded, languages already. I'm thinking about languages like Python, Ruby and JavaScript to mention a few.

Don't get me wrong. I am a fan of the DSL approach (I try to stay away from XML whenever I can) but I think that it's a bit much to go to such lengths to create custom syntax instead of looking for a decent match in existing languages.

Even in situations where an XML parser is clearly sufficient, I find it better to expose a subset of an existing programming language (usually Python) to the users instead. That way I can grow the capabilities of the language easily and I can re-use all of the resources available (IDE plug-ins, tools, tutorials and other documentation) when instructing users.

The approach is similar to, or maybe exactly the same as, how Martin describes creating a DSL around a Semantic Model. The difference is that I use reflection to populate the model instead of a custom parser. I've found that this works really well with a language like Python. It's usually a lot less code than maintaining ANTLR grammar files or XML schemas/parsers and I think it usually ends up being a lot more understandable. But I guess it's really a matter of taste. You say tomato, I say tomato and all that.