I was trained as a programmer, and in my current job as a build wrangler I tend to do a lot of cross-platform programming. Part of the build that I do to construct our product is programmed in java, so I can appreciate some of what the author says.

My opinion of Java always has been that Java is a solution in search of a problem.

Anyone who had done any actual non-trivial programming at this point should know that there is no magic silver bullet for programming problems. Before Java, we had hype from the CASE (Computer Aided System Engineering) Tools fans competing with the RAD (Rapid Application Development) Tools fans. Both sets of backers were convinced that the future was not in actually programming a product, oh no -- what you did was designed your product, and the CASE or RAD would program the product for you. Bugs in the product? No need to get into the messy code -- just re-design the product without the bug. Great theory, but I'm pretty sure that C is still taught in colleges.

One of the problems with Java has always been the speed at which the code gets executed. Since byte code has to be translated to the language understood by the local machine, the argument goes, a java instruction requires more assembly instructions to execute the same functionality than does a pre-compiled C++ statement. My favorite whipping boy, Corel, provides a textbook example of this in action with their ill-fated attempt to write the next-generation of Word Perfect in Java. What they ended up was slow, buggy, slow, bloated, late, slow code that didn't run very fast.

The flip side of this argument is that JIT (just-in-time) compilers and the like have improved the execution speed of Java immensely, and I am sure that they have. However, if you look carefully, you will note that the available CPU power of a typical desktop in service today has more computing power by a factor of five or ten than did those in service when the Java experiment was first attempted. Ultra fast CPUs and systems with huge amounts of memory will be Java's savior, not programming tricks. In our own product, it is only the availability of powerful AIX and affordable Sun systems which were not around five years ago which has saved the viability of the Java project.

And for those applications which are truly time-dependent, programmers will always reach further back down the tree into the fast languages -- C++, C, and in extreme cases, assembly.

Of course, the holy grail that Java pursues and pretends to deliver is that most holy of holies, complete portability. This is when you write something and it runs completely unchanged (and in Java's case, without recompilation) on a completely different system. Like being able to develop on Windows systems and delivering to HP-UX systems.

Garfinkel's argument is that since the business world has effectively standardized on Windows systems, this portability is not a big draw for the average user. It is only a draw for the marginalized systems, Apple and Sun are his examples, in the hopes that applications can be made available for these suffering platforms. He may have something here as it affects the mass market -- but neither Sun nor Apple really play in the mass market. Apple chases the ease-of-use and graphics artist crowd, while Sun appears to be chasing the low- and mid-range workstation market (especially with the release of their Blade 100 systems -- a 500 MHz UltraIIe system which starts under US$1000, and is nicely equipped under US$2000.) These people are typically not the gamer crowd, the web-browser crowd, or the office productivity crowd. They have different uses for their computers.

And the reality of the situation is that just because a JVM or a JIT is Java Certified is no reason to assume that things will run unmodified. They all have quirks. Garfinkel notes that Java's motto has become "write once, test everywhere."

Personally I have not had a reason to pick Java as a tool to solve a particular problem. When I need portability, I usually fall back on Perl, which has a portability that C and C++ can only dream about.

Arguments about whether or not a particular language is easy to read is futile -- while the language architects have some influence on the flow of reading their code, the actual coders are the ones who should be held responsible. I write some pretty illegible code (some of my colleagues would insist that illegible code is the only type I write) no matter what language I am writing. Writing easy-to-read code, especially non-trivial code that has to follow speed, space, or portability constraints is not merely hard. It is an art form. No one but the very, very best can do it on a regular basis. Throw in real-life's time constraints to get the damn thing working, and it becomes impossible.

All languages lend themselves to clear code at some level, in that it is easy to see exactly what is happening. Assembly language is brilliantly clear, because it does exactly one thing. The clarity falls down because it is not easy for code to also communicate why things are being done.

In some ways, I think object-oriented programming has made legibility worse. When you have objects sending messages to each other and to themselves, following the message stream can get difficult due to the way that the code that evaluates the messages is spread out. Object oriented programming is great if you want to focus on the data that the program uses. While that is always a useful consideration, my experience is that object oriented tends to make it difficult to focus on the actual program.

But we are straying from the topic. Today's press about Java is all about server-side processing and Java for embedded devices, an approach which sounds to this observer remarkably like C did all those years ago.

The more things change... the more they stay the same. Today the snake oil being sold through the media has exciting names like XML and BlueTooth and WAP and P2P. I am sure that each has a possible application that it will excel at. But will any of them change the world?

I'm not betting on it.