Josh On Design

There's been an uproar about Phillip Greenspun calling Java the SUV of computer languages lately. I don't agree with the general theme of the entry that a project done in Java will cost 5 times as much, take twice as long, and be harder to maintain than a scripting language.

I agree that it's not the featherweight scripting language that is PHP (or Perl or VB) it don't think it's fair to say everything written will take longer. I see this is a classic example of choosing the right tools for the job. If you want to throw together a quick webapp, Perl or PHP is probably a better choice, but if you want a production quality application that scales, then Perl will let you down after you reach a few thousand lines of code. But that's really not what this journal entry is about. I want to talk about two important points Phillip brought up.

First, it takes longer to whip up an application using Java. This is true, because Java is a systems language and has rich background in strongly typed languages. I think it's a good balance between features and ensuring correctness. But then, I wouldn't have been using it for the last 8 years if I didn't think so. However, I would like to see Java be better used when it comes to rapid prototyping and scripting. I see three ways to do this: 1) create a standard visual editing environment for desktop and web applications (ie, a gui builder that doesn't suck, and they all do, but that's for another day). 2) create a scripting version of Java. The same syntax but with looser rules. It still compiles against APIs written in standard java. 3) provide better integration with other languages. Instead of Perl calling Perl Modules, use Perl calling Java modules. Reuse the infrastructure bits (Java) and focus on the new adhoc coding (Perl).

Any of these three would have addressed the issue Phillip Greenspun dealt with: rapid development of a web application. These three all have one thing in common though: they require a great degree of standardization of the underlying components.

Which leads into the second issue: there are too many ways to do things in Java (though I might note that this is considered an asset in Perl). It's very true that there are a great many frameworks. They often overlap or duplicate work. Sometimes you have three frameworks that do the exact same thing and no way to decide which too use.

I don't see this as a problem though. The Microsoft way is to dictate what you will use: Like it or not, this is the way it is. The Cathedral. The Java way is to let different groups create different solutions. Good solutions are pitted against eachother and voted on (JSR) or the good solutions simply become defacto because they are so good. The Bazaar.

Solutions created by people using them in the real world is a good thing. Eventually the details are worked out and we have one or two basic approaches that everyone uses. Then we move on to more interesting topics. I like this model very very much. Without it we wouldn't have things like Ant, a build tool so good I can't imagine living without it.

But what's needed is a place to collect these good solutions. A new developer should be able to just jump right in. For many projects Jakarta has become this place, but I think we need more. But then, isn't that what Java.net is supposed to be?

(Though I still say it's way too hard to write a Swing app.)