Why I hate XML for DSLs
theschemeway.blogspot.com
theschemeway.blogspot.com
The closest I've come to writing an XML-like DSL are the many Lisp-lites that I've hacked up over the years. Most of the rest are either Forthish languages (if it's primarily for my use to avoid writing large quantities of Java, C*, Haskell, etc.) or rough "business natural language" DSLs for power users who want to tweak a process, object, or flow.
In general, I wouldn't even consider XML as a DSL unless I broaden my idea of a "DSL" to mean "any representation of a state or set of operations used by a computer," in which case I've written a lot of XSDs for machine-generated documents, such as serialized objects, messages to be placed on ESBs or queues, etc. But I do not think this article pertains to that sort of "language" either.
I'd like to ask a favor as a fellow programmer: pretend you never saw this article. The fewer XML-based DSLs, the better.
In short, don't risk your or your coworkers' safety. Just say no to XML as a programming language.
Take for example XSLT. You are saying that all XSLT programmers are mad?
[edit: ok, I get it! :) ]
Sorry, I just had to find an example...
For some things, a visual DSL like a callflow for voice apps or musical notation for music probably has the highest information density, and therefore becomes the most pleasing interface for being creative.
The other is transforming XML documents (XSL) although this is quickly becoming more of a PITA than doing it natively as the various XML APIs start offering declarative syntaxes.
I admit that I've never done any serious Java development, but that's jumping from the kettle into the fire, is it not? As verbose as Java is, it seems to be less so than XML would be.
Reloading is possible with Java as well. And even an XML-document has to be reparsed and most likely be brought into an internal representation, a task which is very similar to a compilation. So, no difference here or any jsutification that xml is suited better for this purpose than other languages.
You might want to avoid rewriting history, or at least avoid commenting on things you clearly know nothing about.
XML Working Group design goal 6 (out of 10):
> XML documents should be human-legible and reasonably clear.
Human readability was a primary goal of the WG, and one of the big advocacy claims against binary or custom plaintext formats.
> Reloading is possible with Java as well.
Sure, anything's possible, you can even parse, compile and load C source code in a Java program if you have time to waste. How many JVM implementations let you trivially reload executed source files on the fly, and how often does that feature explode in your face?
> And even an XML-document has to be reparsed and most likely be brought into an internal representation, a task which is very similar to a compilation.
The point is that it's performed on the fly, easily, and can be re-executed as often as needed without bringing down the whole machine.
Yes, that's true, as stated in http://www.w3.org/TR/2008/REC-xml-20081126/#sec-origin-goals. Nevertheless, I stand by my point that human readability does not necessarily imply easy human comprehension. For that matter I believe that the working group introduces that design goal to ease problem tracking and not to imply that xml is suitable for human to human communication (which imho should be the main design goal of computer languages). I have great respect for your mental abilities but for me its difficult to understand larger ant scripts as xml is a data container and not a control flow language.
You would rather implement business logic in XML than in Java? Seriously?! Personally, whenever I see logic implemented in a markup language, it makes me wanna scream. That's simply not what they were designed for.
As far as I'm concerned there's only one time when you're better of programming in XML and that's when doing GUIs. That's because XML lends itself naturally to GUI programming. Concepts of nodes, parents, children, siblings and trees are very much at place in XML (or XML-like language), and can be easily used to describe the structure of the UI, whereas in imperative programming there are really no such concepts, and you have to sort of 'invent' them.
I think that people are finally starting to realize this - that we shouldn't indiscriminately use XML for just about anything, and especially not for tasks that require some sort of decision, branching and logic. But we should use it for what it's good at, and that's describing structure (of documents, user interfaces, models, etc).
The good people at Adobe, for example, came to this conclusion a couple of years ago, that's why when developing Flex applications you usually write your UI in MXML and your business logic in ActionScript.