There was an absolutely excellent essay by James Duncan Davidson, creator of the Apache Ant build tool for Java, about why XML was its configuration language, and why it was perfect at first but grew to be a huge problem. To summarize from memory:
- Ant’s config needs were modest: configs were static strings, numbers, booleans, and lists
- XML parser existed, was well tested, was supported by lots of tools, so was a quicker and easy way to parse configs
- As Ant became successful, the configs grew more complex and started to need to be dynamic and have “control flow”
- Once control flow was needed XML was no longer the best choice for config parsing, but it was too late. (The correct answer is that a scripting language is what you want here.)
Edit: I posted this quote from his essay on HN back in 2020 [1]:
> Now, I never intended for the file format to become a scripting language—after all, my original view of Ant was that there was a declaration of some properties that described the project and that the tasks written in Java performed all the logic. The current maintainers of Ant generally share the same feelings. But when I fused XML and task reflection in Ant, I put together something that is 70-80% of a scripting environment. I just didn't recognize it at the time. To deny that people will use it as a scripting language is equivalent to asking them to pretend that sugar isn't sweet.
Edit 2: The reason you’re not seeing an “improved yaml” is because the improved version is just Python/Ruby/JS/PHP,…
I was the first person to use Ant outside of Sun. I committed it to the Apache cvs repo after James donated it.
The initial use for it was to build the source code for what became Tomcat (also donated by Sun/James). At the time, Java didn't really have a build system. We were using Makefiles for Apache JServ, and it was horrid.
Ant was a breath of fresh air. At the time, XML was the hot "new" thing. We were instantly in love with it and trying to get it to do more. Nobody could have predicted what Ant was going to turn into. It was effectively an experiment and just a step forward from what we had previously. Iterative software development at its finest.
Similar to how Subversion was a better CVS. At the time Subversion was being developed (I was part of that as well), nobody could predict that a whole different model (git) would be so much better. We were all used to a centralized version control system.
It is entertaining watching everyone bork on about this topic, 24 years later.
By the way, Java still doesn't have a good build system. Maven and Gradle, lol.
I didn't always hold this opinion, but currently I believe general build (and deploy, integration, etc) engines should never be anything more than a logically controlled workflow engine, capable of transparently querying your system, but never directly changing it.
It should allow for any random code to be executed, but by themselves they shouldn't provide any further feature.
Ant is not like that. In fact, the Ant script was always a programming language. It lacked some flow control features, but if you have a sequence of declarations that should run one after the other, it's an imperative programming language already, you don't need loops and conditionals to qualify to that.
- Ant’s config needs were modest: configs were static strings, numbers, booleans, and lists
- XML parser existed, was well tested, was supported by lots of tools, so was a quicker and easy way to parse configs
- As Ant became successful, the configs grew more complex and started to need to be dynamic and have “control flow”
- Once control flow was needed XML was no longer the best choice for config parsing, but it was too late. (The correct answer is that a scripting language is what you want here.)
Edit: I posted this quote from his essay on HN back in 2020 [1]:
> Now, I never intended for the file format to become a scripting language—after all, my original view of Ant was that there was a declaration of some properties that described the project and that the tasks written in Java performed all the logic. The current maintainers of Ant generally share the same feelings. But when I fused XML and task reflection in Ant, I put together something that is 70-80% of a scripting environment. I just didn't recognize it at the time. To deny that people will use it as a scripting language is equivalent to asking them to pretend that sugar isn't sweet.
Edit 2: The reason you’re not seeing an “improved yaml” is because the improved version is just Python/Ruby/JS/PHP,…
[1] https://news.ycombinator.com/item?id=25385443