I commented on a blog entry here where people were Java-bashing and saying that it was inefficient and restrictive. I’ve expanded that comment into an entry here and put a bit more thought into it. It boils down to a trade-off between speed of implementation and cost of maintenance, which is a topic that is well understood in some contexts and I feel that it applies here too but is lost in the noise of language wars.
Some people rant about Java being bloated architecturally. If you architect correctly then it is not bloated. To some people, “Java” isn’t Java. To some people, “Java” is layers of pointless, bloated EJB and middleware and endless acronyms and buzzwords. To me, Java is a language and you can use it to program at whatever level you choose, given the right frameworks and support.
However, there are still restrictions that some people do not like. Some people like manipulating hash tables and lists with operators rather than with method calls and don’t like that Java won’t let you do this. My view is that the more obvious that syntax is (i.e. in correctly named method names) the more self-documenting the code is. Of course, certain symbols such as “[]” for indexing are (almost) universally understood. But if these can be overloaded in strange ways as they can in some languages, then this universal understanding is watered down. And how much time is spent actually typing in code when considering the whole process of delivering a project? Not much. The few characters that would be saved by typing “var[i]” rather than “var.charAt(i)” are negligible when compared to the thought processes that went into deciding how your method / class / package / application is actually going to function and hold together.
I like Java. It makes me feel comfortable. It makes me feel safe in a particular way: That if I write my Java code clearly and with a minimum of complexity then there is (hopefully) only one way in which a random, possibly underqualified support programmer can interpret it when (s)he attempts to change it in three years time. This is, unfortunately, a large proportion of many applications’ life cycles. Jumping on the bandwagon of shiny new technologies when they appear on the horizon can end up costing your organisation or customers a lot of money when they need to find people to maintain them. To ignore this reality is tantamount to intentionally producing an unmaintainable product. Maybe in a few years there will be a critical mass of capable, trained and relatively inexpensive Ruby programmers available and it is at that point that producing a significant government application in Ruby becomes a workable proposition.
While I am sure that I and a number of my colleagues would be more productive writing in a higher-level language than Java, that is not the only consideration in software. Also, we get good at bending Java to our will. All those frameworks and tools that are out there - if you find a small set of good ones that you know how to use then they can help a great deal.
We can go on about how brilliant we are and how we can produce brilliant code and how we can maintain it without too much trouble. But it is not the brilliant “we” who are going to be maintaining that code and that is what we need to be wary of.
Entries (RSS)