"I know, I know — everyone raves about the power of separating your code and your data. That's because they're using languages that simply can't do a good job of representing data as code. But it's what you really want, or all the creepy half-languages wouldn't all evolve towards being Turing-complete, would they?"
I've worked on a very similar project for WolneLektury.pl, but were fortunately allowed to use Python instead of Java.
XSLT and XPath proved to be tremendously useful, cutting development time at least in half. Thanks to the wonderful lxml library I could easily extend XSLT with any functionality I wanted. Of course I've kept the single best future of this domain language intact - its declarative nature.
Mixed messages here. His biggest target of criticism is his own Frankenstein's monster of a Java project, but he wants the blame to go to the tools (technologies), and the fact that he wasn't allowed to use Haskell.
You seem to have missed the point. The problem he points out is that in the Java world, it is popular to use a domain specific language like XSLT to handle some tasks and that's an external tool that does not nicely embed into Java. In the Haskell world, domain specific languages are also popular but they tend to be embedded in Haskell, which makes it easier to do the non-domain-specific stuff (like writing the results of the XML transformation to a file). In Java land, many tools can be extended through plugins which can get the same effect but the result is not as easy to follow.
He also has some critisism towards Java the language, but it played a lesser role in the article. Some of the targets of his critique (like the lack of sum types in Java) are also reasons why Java does not have cool embedded domain specific languages like Haskell has.
Though xslt didnt come out of Java, it comes from the w3c mindset of how things should be done. His main criticism is the poor Java XML library, combined with the weakness of xslt, so neither work. Now we all know that most DOM style interfaces are badly designed, tend to think the answer is the Haskell one is an exception.
Everyone else just avoids xml for these types of reason... Obviously you cant for this problem.
"I know, I know — everyone raves about the power of separating your code and your data. That's because they're using languages that simply can't do a good job of representing data as code. But it's what you really want, or all the creepy half-languages wouldn't all evolve towards being Turing-complete, would they?"
http://sites.google.com/site/steveyegge2/the-emacs-problem