It became irresitable, whenever someone hit a wall in Java or found a nice hack for a specific problem in some other language: Start bashing Java.

In short: If you are still using Java you are

• … a poorly educated retard
• … an ignorant who will never see the light
• … doomed as you programs are unmaintainably bloated
• … to lazy to write unit tests that replace the declaration of the receiving type in every place
• … should read “my” blog and stand still in awe

I think this list can be prolonged at will - and it will.

The world is more complicated - fortunately I’d say. Some truths aren’t negotiable:

• There are programs of different complexity
• There are programmers of different skill

even more, as slight variations of these

• Not all programs exhibit the same type of complexity
• Not all programmers have the same character

Complexity

Given a problem small enough, it is quite likely that there exists a language that provides just the needed abstractions to make the solution  look trivial. Prolog is an extreme example, but unfortunately very few problems fit Prolog very well. Most scripting languages come with very slick regexp support - I used regexps in Java two times in 10 years or so…

So when we look at real world problems the advantages of single languages get smaller, unless one language could offer it all (if such a language existed I am not sure if I want to learn it). If you use a malleable language like Lisp you could build your own abstraction (err - with Lisp you actually have to unless counting ((()))s will haunt you in your sleep)

Some complexity can be extracted by using libraries. This is always  possible, but your mileage may vary. For common problem sets good libraries had been developed and not using them is stupid. If the libraries don’t exist either your language is a) too new b) rarely used c) used in a different domain. If it is not a): Throw everything away and start over with something else - now you know for what you’ll have to pay attention.

After moving out complexity into libraires the remainder is another decisive point: Do you have one big block or independent problems or variations of some problems left? The latter is the classical case in most enterprise projects, here OO helped a big deal by enabling reuse using inheritance (my stance on this should be known),   if there remains a problem like the GNFS algorithm you language choice won’t affect the outcome a lot, otherwise we are in the “framework” domain. Web applications typically consists of some loosely coupled pages and to tied this all together there are 200 web-frameworks to choose from. What all these frameworks have in common (at least the better ones) is

• separation of concerns
• control abstraction

Separation of concerns (see MVC, etc) is already well know, control abstraction came into fashion more recently. Dynamic languages, or even languages with a fair support of closures make control abstraction very easy without a callback-based API or immense boilerplate definitions. In classical languages we know them from the Command and Strategy patterns and there are three types of programmers: Those who use them, those who hate them and those who hate them because they are are to explain to the second group.

I am sure that closures with a reasonable syntax will eventually lead to a wider use of these patterns as they are then built into the language, but I am far from sure that it will be for the better.

Skill

If you are working at Google you had been ckecked thoroughly for you skills. If you are working in a small consulting firm and a start-up this can be taken for granted as well. You also had been accepted for another reason: You love what you do and you take responsibilty for it.  There is the story about the man asking three stone-cutters in a quarrel: “What are you doing here?”. There had been three responses:

• I am cutting stones, isn’t this obvious?
• I am earning a living for my family
• I am building a cathedral!

Of course we love to work only with those cathedral builders, but again it isn’t so easy:

• Only a few stone cutters are cathedral builders
• You have to have the team leader of the cathedral builder as well

Without a visionary project lead who can communicate the vision to entire team, people will continue cutting stones. The worst thing is that it will be even hard to tell the good programmers from the rest: It is a sad truth that most projects have a technical hierachy which is based on seniority rather than on achievements.  New  talents will find it incredibly frustating to be turned down on any new idea, being told that “this can’t be done here”. Why? Because nobody can tell, everybody is stone-cutting and for most people it is OK that a stone-cutting day has only 8 hours or that there seem to be enough stones to be cut to bring the kids through college. Any change in habits has no incentive for them and it will face immediate resistance.

Well, if you say such an organization is doomed, I’d love to join in, but this isn’t true all the time. You find this increasingly in larger organizations that represent a market power that helps the to compensate that, they might do better with more dynamic teams, but this isn’t sure neither.

The other side of our cathedral-builders is that you’ll easily find out the good and the poor builders. Now we are down to true skill. It will create tension in a team when the differences become visible. In large organizations you can look for a better suited team for the less skilled, but there are some limits. (I had been close to slapping my PM as she announced in a mail that some people who don’t has an assignment at the moment will be pooled as a “B-Team” under my project “to stand by  for tasks of minor importance” - we healed this faux-pas by never establishing the B-Team)

What was I about to say?

In short: Java is OK, but for sure it isn’t the best language ever. It democratized object-oriented programming, but it isn’t the stuff to build cathedrals from, nor it isn’t a good language to implement frameworks in (no closures, no metaprogramming). Some coined it a blue-collar language (I think it was even James Gosling).

The challenges of programming have shifted, features we are missing in Java make the code accidentally complex and frustrated skilled and motivated engineers as they know how easy they can achieve it in other languages. Moving to some other language is no option as you would leave behind 80% of the Java workforce and you loose all the time tested libraries you built upon. Even if a language would give you the 500% jump in productivity, this probably won’t last long:

• What is the statistical data on maintenance cost/loc for language X
• Complexity rises faster as you think, in fact the old saying that a program grows in complexity until it surpasses its programmers ability is the real limit

Problem complexity is that it is for the better part the actual problem. Setting each rule into code requires thought - otherwise it is just boilerplate (easy to write, easy to maintain) - but how many rules can you keep in mind when changing a program? The only way to scale up here is to parallelize.

Thus the solution isn’t pouring the baby with the bath. A sound architecture is needed to decouple to decompose the complexity, ideally incrementally. This means refactoring. I am not aware of any other language that has such great tools for complex refactorings like Java.

At some level the infrastructure for this has to be created, luckily Java also brought us the JVM which allows us to write code in other languages while being interoperable with the Java code. A nice playground for the talents in an organization to show how this could help to build a beautyful cathedral.

But of course only if everyone knows that they are building a cathedral.