A Server of Babel

Recently I’ve caught myself thinking more and more about the proliferation of languages in enterprise Java projects. If you look at a typical J2EE project you will notice that, besides obvious Java and JSP, the project contains a huge amount of code written is many “configuration” languages: tag library descriptions, WSDL, XSL, Hibernate… All these languages are XML-based – but still, each is a language in its own, with its own syntax and semantics. It seems to me that there is a tendency here: the frameworks (platforms, technologies…) become more and more generic – and the more and more of actual logic moves from Java code to the “configuration” files. Initially, maybe, that was not a bad idea – but now it turned J2EE into a monstrosity. The source files in those languages are hard to read, they are extremely error-prone, and, since they do not require compiling, quite often the problems may go undetected until the run-time. Compare it to how Java sources are handled – and you will see the difference immediately.

Personally, I am getting tired of this “server of Babel” situation. I feel I am ready to look for some other platform, which will be simpler and more elegant than modern J2EE. And – judging by the speed at which Ruby on Rails is gaining popularity – I am not the only one who is ready to move.