This is exactly the sentiment that led to us at QuickFuse (quickfuseapps.com) to skip creating yet another XML DSL for building voice apps. The voice dev ecosystem is overflowing with them, some new and some old (VoiceXML, TwiML, etc.), so we decided to move straight to a graphical representation that does the task.
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.
There are two times when you'll be better of programming in XML. One is if the language you would otherwise be writing in is Java. (Or WCF in the MS stack)
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.
> One is if the language you would otherwise be writing in is Java. (Or WCF in the MS stack)
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.
No, but Java is static, you have to recompile it every time you edit it. The draw of XML-based languages for the Java community is that you don't have to recompile them. Hell, it might even be possible to reload them on the fly.
Languages are mainly for humans, not for machines. XML is intended for transporting data machine to machine, not to be read and comprehended by humans. Computer languages must foster the comnprehension by (fellow) developers, this is their main task.
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.
> Languages are mainly for humans, not for machines. XML is intended for transporting data machine to machine, not to be read and comprehended by humans.
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.
> XML documents should be human-legible and reasonably clear.
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.
There are two times when you'll be better of programming in XML. One is if the language you would otherwise be writing in is Java.
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.
I have to say that I've never considered using an XML for a DSL. Most of the reasons I've written DSLs usually involve a desire to avoid writing more code.
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 have to say that I've never considered using an XML for a DSL. Most of the reasons I've written DSLs usually involve a desire to avoid writing more code.
I'd like to ask a favor as a fellow programmer: pretend you never saw this article. The fewer XML-based DSLs, the better.
I have created a programming language that is written in XML. With a decent editor (I use oxygen xml) and a good schema (I use Relax NG) there is almost no way to make syntax errors and typing is a breeze (auto completion). With schematron you can even make clever (semantic) error checking before compile time. So it always depends on the case.
I don't doubt that you could write a DSL that someone would be productive with. But then you'd need to keep a psychiatrist on staff to make sure the people using it don't go crazy. If we're talking about a full on, general purpose language, then you might as well start them on Thorazine ahead of time. Otherwise, you risk a programmer going postal.
In short, don't risk your or your coworkers' safety. Just say no to XML as a programming language.
The point I'm trying to make is that while I'm sure you could make an XML-based DSL that does its job, I don't think anyone would enjoy using it over an alternate way of implementing the language. Thus, being forced to program in it would drive them insane.
Most of my past experience with XML reminds of a certain saying. The one about how someone realized they had a problem and that it could be solved with XML. Then they had two problems.
26 comments
[ 5.4 ms ] story [ 60.5 ms ] threadFor 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.
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.
Sorry, I just had to find an example...
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! :) ]
http://en.wikipedia.org/wiki/Patrick_Bateman