clash of programming language civilizations

Why yes, the title of this post is sensationalist and even a little insulting to the real, violent culture clashes in the world. Thanks for noticing.

A few days ago I pointed to a blog posting that I saw through the use.perl.org feed. This time, I'll be pointing to blog postings through the javablogs.com feed. (I'm subscribed to those feeds because I frequently use Java and Perl at work. Outside of work, I experiment with whatever.) A proposal to add closures to Java has brought out some interesting arguments for the status quo. Java 5 Language changes were a bad idea even argues that the status quo, Java 5, isn't all that much an improvement over previous versions. Here are two quotes from there, one short, one long: "Verbosity is a good thing(tm)!", "Encapsulation is very important and is defined using several levels of hiding: class, package, protected and public... Simple and powerful. Why is this powerful? Because I can rely on the scope and find the usage of X (X being a field or method) within his scope far more easily.".

What I find so intriguing is that the same valued characteristics this blog used to support an exceedingly lean, simple Java are what Java detractors routinely trot out as arguments for Java being weak, wordy, and over-engineered. The same characteristics! It's as if one person's language vice is another person's language virtue. Contrast the above quotes to quotes from the dynamic-typing, stop-calling-us-scripting-languages camp: "do what I mean (DWIM)", "convention over configuration", "the first postmodern computer language". With values this different, neither "side" even has an agreed-upon ruler for comparing their...er, syntax.

This clash in values is even more dramatic when you start considering examples. About Microsoft's "Delegates" transparently explains why Java chose not to have delegates. One blogger compared Hani's Bile Blog to some of the oh-so-friendly Ruby resources, and got some surprisingly shrill replies in spite of the fact that one's attitude has no correlation to one's programming language. A blog entry which is not so tongue-in-cheek is Our long Java nightmare. He says this isn't an anti-Java rant, but with a title like that, I wonder what would be. An irritated individual over on javalobby has the legitimate complaint that Ruby users keep discussing Ruby on Java sites. There's even a guy who feels compelled to argue that Java is not in the midst of a close battle with the Next Big Thing.

Another twist on this deep clash in philosophy is the group who works in Java for a living, and is recreating (mostly server-side) Java development "from the inside". Truth be told, if you want to use closures along with Java-ish syntax, you can just use Groovy right now and use Grails to develop a website around an EJB 3 object. Web service development isn't that hard at all if you use Glassfish. Even sticking with Eclipse is easier than it used to be with Callisto. If you prefer VB-like development, you may be able to do that sometime in the future. Want the source for the language implementation, so you can solve the most obscure bugs? It's on the way. Java programmers are not buffoons. Whether they cash in on it or not, they (we?) know how hard it has been to get things done in Java.

Conclusion? There is none. The rationale behind a choice of programming language is up to you, or your managers. Which punctuation marks or paradigm a language uses is only part of the equation..."it's how you use it". As Ovid explains, Perl probably wouldn't have the reputation it does if people used it better. More to the point, in another place Ovid advises his readers to ignore language holy wars and use the language whose strengths best fit your problem.

I would also advise that rather than choosing 1. the side of Turing Machines and statefulness and efficiency and static typing, or 2. the side of lambda calculus and statelessness and runtime interpretation and deferred typing, pick both. Think laterally. Use a convenient RAD language for most of the program and a speedy language for the parts that are a performance bottleneck. Use a language that can check types at run time OR compile time. Use a language that is functional but statically typed, like F#. There doesn't have to be One Language to Rule Them All, as long as there is One Interoperable Platform To In the Darkness Bind Them. But it certainly is entertaining to watch the two programming language civilizations clash.