To everyone involved in writing XML-based programming languages, and by this I mean those languages where XML is the primary syntax, not useful things like ECMAScript that just happen to be applied to XML...
Please stop.
XML, when you get down to it, is a really verbose way to represent Lisp S-Expressions. XML's expressiveness is well-designed to mark up text, which is what it was designed to do. Any programming language based on XML, however, will just end up looking like a really clumsy attempt to rewrite bits of Lisp with angle-brackets. The world really doesn't need any more of these.
In contrast:
In one of my personal, never-see-the-light-of-day projects. One of the things I was delaying writing for this program was the configuration file: I just had a TestLauncher class that got all the right objects together and launched the application with some hard-coded defaults.
Last night, I decided that enough was enough, and started throwing together an example XML configuration file that I could use as a basis to building a real configuration framework for the application. It's a reflex, you see. We're trained to think XML whenever we have to put data anywhere. When I was halfway through, I started thinking about all the dependencies I was about to introduce: the chain of “Commons-Digester depends on Commons-BeanUtils” and so on. I'd much rather have something more lightweight.
I'd already been thinking about the connection between XML and Lisp. I was also realising that in converting my ‘launcher’ into a configuration file, I wasn't writing something that was configuring my application so much as something that was programming it. And you can get a self-contained, standards-compliant Scheme implementation for Java in a 200k download. So as a thought experiment, I re-wrote the configuration file in pseudo-Lisp.
Not only was it significantly less bloated and more readable, it opened up a number of doors that just weren't conveniently open before. SISC code can call out to Java objects, which meant that rather than having a configuration file and a Java framework to interpret it, turn it into objects and then use the objects to configure the application, the configuration file could configure the application directly.
Eventually, I compromised: the configuration system would consist of two Scheme files: the configuration file itself, and a library file that is parsed before the configuration, that maps expressions in the configuration to calls on the Java objects themselves (plus a few helper functions along the way). That way, adding extra configuration options to the system simply means exposing them as Java methods, and then writing the glue code in Scheme to allow the config file to set them. I suspect (without evidence so far) this will be faster than the other way by an order of magnitude.
The two-file means that the configuration file itself will not have to contain anything that looks like a program, just a series of assertions like...
; set up the user database (add-module UserDatabase "com.example.HibernateUserDB") (UserDatabase config-file "hibernate.cfg") ; initialise the command framework (command-search-order ( "org.pastiche.commands" "org.pastiche.util.commands")) (add-command "LoginCommand") (add-command "SetPreferencesCommand")
No, I'm aware this isn't a new idea. I'm just surprised it's not done more often.
The dynamic typing of the Lisp system helps as well: the configuration file is flexibly glued to the program instead of nailed on: which means less work maintaining it as more modules are added, whatever their types are.
Note, I haven't tried this yet, I'm just getting the idea down in ones and zeros before attempting it. If it turns out to be a total mess, I'll be sure to blog my failure.
That's actually a good idea. I like it.
I can look at most XML files and figure out what's going on pretty damn quickly. Will I be able to do the same with Scheme?
You're argument seems kind of backwards. You ask people not to invent a new mini-language with XML and then turn around introduce Scheme which really doesn't strike me as a big improvement in the usability department.
And what are some examples of these dreaded XML programming languages?
I agree. Making up a language based on any syntax just seems bad. I guess scheme is a real language, and so you can theoretically figure out how to use it, but I don't see that _configuration_ requires a programming language.
And, as for bad XML programming languageas, ANT is the absolute worst. It is the worst scripting language ever, and the most retarded build system I've used. Shell scripts would be better. But, it's cross platform. Of course, so is pyhton. Why not use that? Who knows.
Wouldn't the use of simple property files and/or resource bundles give you the same capabilities, without burdening you with yet another language to work with?
Examples of dreaded XML languages...
o:XML http://www.o-xml.org - Somewhat similar to ECMAScript in features and purpose.
Waterlang http://www.waterlang.org - Seems to be some kind of LISP, but with angle brackets.
Now, please execuse me while I go add these URLs to my NetNanny block list.
Ant wasn't supposed to be a full bore XML programming language. It certainly wasn't when I first hacked it together. The point was to express the tree nature of a project build. Over time however, and after it left the nest, it grew and expanded.
More at http://x180.net/Blog/Apache/Ant/WasntSupposedToBeAScriptingLang.html
Dave,
Ant isn't a full bore XML programming language. Ask any of the Ant core developers and they'll reiterate the common cliche 'Ant is not a Scripting Language!'
Alan,
I wonder how much programming you've done with either o:XML or waterland to dismisss them so readily. You can actually do some pretty neat things with o:XML where "everything is XML".
Regardless, I don't see what they have to do with the discussion. I've never seen anybody use o:XML or Waterlang as a configuration language.
The example I expected to bring up would of course be Jelly which is used in Maven. Had you brought up Jelly+Maven, I'd be willing to give you the benefit of the doubt. My limited experience with Jelly+Maven suggests that it's an abomination before God and Country.
But I'd still be willing to give Jelly the benefit of the doubt. Why?
Because there is a fundamental difference between what Jelly does and what Charles is doing above. What Charles is doing is simply defining new functions within a constrained language (in this case LISP) which, I suspect, just map onto java classes. In Jelly, not only do I get to define whole new functions I get to define entirely new language constructs. In fact, I think you could make the argument that Jelly is not a scripting language. By adopting XML as the 'syntax' there's really nothing you can't do in Jelly. It's a bit scary.
There are other cases like JSP where again, the use of XML adds a lot more than it takes away. Which leads me to the point: XML is explicitly NOT just a verbose way of doing Lisp expressions. Lisp expressions have well defined semantics. XML is completely semantic-free. I could imagine quite a few applications that would be easier with XML than with Lisp any day.
"In Jelly, not only do I get to define whole new functions I get to define entirely new language constructs."
Which reminded me of this...
"In Lisp, you don't just write your program down toward the language, you also build the language up toward your program." -- Paul Graham, "Programming Bottom-Up", http://www.paulgraham.com/progbot.html
In Lisp, there is no distinction between data and program, and the way that data becomes program is totally malleable. It's exactly the same concept as programmatic XML, except with different kinds of brackets.
So, for example, what I am attempting to do with my configuration file is start with _data_ that looks like a configuration file, and then building language constructs on top of Scheme until that configuration file becomes executable Scheme code.
Using XML as a scripting language is indeed horrible. Little per-app XML languages abound: JBoss is the first I've had experience with -- there's at least 2 or 3 in there. IBM's Beans Meta Framework is another. I'll admit I made one for a system I worked on. Each of these languages is pretty much unreadable.
But then again so is the Lisp-y thing outlined above. In the end what using XML or Lisp gives you is hierarchical arrangement of arbitrary data in text; plus (and here's the big win for me): I don't have to write a text parser.
And that last point is what makes XML (or Lisp) attractive. I don't have to write a parser, and an interpreter is trivial to create. That's why JBoss and IBM's BMF use XML, and why all these little XML languages are popping up all over. I don't believe there's anything more to the phenomenon.
This also occurred to me earlier this week, although I speculated about using Jython to do the config instead of Scheme, as its slightly easier to understand in a single pass.