Why Java might lose against Ruby (or Python, or PHP ...) in web development

There I said it...

There I said it, Java might lose its rank in web development. Sun GPL'd Java and integrates scripting languages. Ruby is going on with JRuby, Python has it's JPython pendant, nowadays PHP runs/compiles on Java. But that is not enough, Java may lose the struggle for the #1 internet language.

I always thought that a language like C# will accomplish the task to overthrow the "heir to the throne", but that was a little bit naive and sounds ridiculous: Java and .NET are way too similar for that. Lisp? SML? OCaml? Haskell? No, these languages need (damn) good programmers to complete the task, and there are not enough good people out there. To shift the workload needed in IT-business kind of standardized people are needed (no offense meant!): People only thinking in mathematics, functional programming and definitions, or simply only programming recursions seem to be the wrong way to work this load. The industry needs standard tasks to be done in standard ways by standard workers. If it wouldn't be that way, no-one would program Perl/PHP/Java/C# or similiar languages/scripts any more, they would program such complex algorithms like Shell-sort in only four lines (as I did in SML more than one and a half decades ago).


The three frontier war

Many people are complaining about Java, it is fighting a three-frontier-war. The arguments:

1. Java is losing against Perl or PHP because they "get things done". Perl is "quick in programming". PHP is a starters programming language, fast and simple (be honest: nearly no good known project uses PHP5 with objects and Exception-handling) and, moreover, it's good for small to medium sized projects and has (like Perl) not to deal with the (typing and casting) overhead of strong typing.
   
2. Java is losing against Ruby or Python because they "get things done faster". Ruby on Rails seems to rock for (small to medsize) projects and Python seems at first glance to be a good replacement for all.
3. Java has, because of the mature kind and popularity, to match (or: to be a target of comparisons) with functional programming languages like Lisp and Haskell, for example, which "know what the programmer wants" without explicitely explaining it by syntax.
   

I do not even mention runtime behaviour, everyone knows that C (or even C++ compared to an old JVM) is magnitutes faster than Java and everyone thinks that Java still is slow. So, Java is dead, isn't it?

Let us, just for a minute, forget the discussions and the pro's and con's of the points mentioned above, all this was discussed endlessly all over the internet before. Let us not talk about the verbosity of Java programs compared with dynamic language A or the fact that programs can be written so much more elegant using language B, because in B there are not all those conventions which clog the programmer using Java.


Who is killing Java?

Though having the best intentions, Java programmers are killing Java. I know that sounds weird, but I watched that for nearly 5 years now. The fact that Java people, (better: Java software / better: Java frameworks) cannot simply "be simple" discourages. And directs programmers and projects got the train: Ruby on Rails, as an example, is the exact opposite by just being simple. Just "getting the thingies done" is what people want to see after endless fussing around with XML and EJB, hoping that it will work out anyhow. Having hundreds of pages of documentation explaining complex frameworks, who cares? Ever started a new experimental web container in Tomcat and not simply copied the web.xml without exactly knowing what's in there? It got far too complicated.


The world is watching

Continue doing complicated stuff and you will see the people running away from Java. The problem about Java is not the language, the problem about Java is that Java does not provide a "simple start" anymore, not with all the programmers using these fancy frameworks nowadays. I'm not talking J2EE - that is too complicated, too. But that's only interfacing, at least partly. Looking at the frameworks deriving from J2EE and even if you have an IDE like NetBeans or Eclipse installed, you cannot have a web/http-service up and running in 2 minutes. Too much configuration - which needs too much knowledge of how to be configured. And, yes, surely, you cannot simply talk to a database, that would not be 1337 enough, you need a second (third, fourth ...) layer like EJB/Hibernate etc., all XML / annotations configured. At least we can do it, who bothers if we need it? And who cares for SQL, anyway? There are so much frameworks, why bothering with the simple thingies 'round there?

C'mon. I heard of a project where four (practicvally immutable) database tables had to be filled with logging informations and they used the XML-ORM-Mapping iBatis framework for that. Be honest, ever heard of the word "overkill"? Nooooo, you are right: Better configuring it using XML, or even better, let the software write the configuration! Write your makefiles in XML (including self-injected file commands). Keep it unreadable, that's a kind of job-security, too! Why typing some 10 lines of code when we simply may let the preparser generate it by configuring all in fourty lines of XML?

Never mind. Just keep on killing Java.

What, exactly, is XML?

This seems a dumb question: What, exactly, is XML? But, being honest to yourself, can anybody out there explain to me in a few words what XML really is? Or, to be more precise, what is XML all about?

For a couple of years I tried to just listen to the guys 'n ladies who should know the answer and, believe it or not, I got a couple of answers depending on whom I asked for:

Listening to consultants it is the one-and-only salvage to our new computer-century, solving all problems you ever had. Not even enough, it is capable to solve problems you are not yet aware of ever to have.

Listening to the techies you might learn that all you want to achieve technically may be done using XML.

Listening to the decision-makers it is the answer to life, the Universe and everything, and that all doing one big shot.

But, honestly, can anyone out there answer the simple question: "What, exactly, is XML"? Doubt so. This is because merely (in first sight) it only is a format but then (in second sight) everyone put their hopes in it to solve problems XML never was ment to solve. I still can remember the hype in IT where, at a meeting, someone simply said: "Well to solve this problem we provide a XML interface, that should do.". Needless to say that it didn't.

And it is easy to process. There are so much frameworks, tools and API's to cover all that unconvenient stuff of "reading", "parsing" and "testing" XML (configurations) that most people may suggest to you that using XML is pretty more simple than doing without it. Never had the sensation that you needed one hour to do something in XML which could have been done in a couple of minutes without? I had.

To be more precise, the troubles I have with XML are the following:

- It is not defined which element (or tag) to use if there are more than one in one realm. As far as I know all the tools and API's take the first value they find, but it might be a source for errors, especially if you insert a new element which overrides (or better: does not override) the previous value.

- XML is not human readable. It is an exchange format with fault-tolerancy. This is the one advantage XML has (compared to, say, a fixed size record-driven format): In case an elenment is not defined, the structure is kept (mostly). But reading XML as a human reader is painful.

- XML is a format and no programming language. XSLT is a cute way to transform XML into another XML (or text or u-name-it), but XSLT is no programming language either. The moment you stop thinking of XML as a language is the moment you will better recognize how often it is misused nowadays.

- XML produces overhead. Huge overhead. Only think of SOAP-WebServices (or BLOBs represented in XML): To send one bit of information you will need to process, assemble and send some kilobytes round the corner. Agreed, SOAP-WebServices are well-defined and can simply be extended. But do you need XML-ish things for each and every problem?

So what, exactly is XML? An all-intention-problem-solver? Definitely not. An extensible exchange-format with fault-tolerancy and many available tools to deal with and transform or show it? I bet on that one.