Rants on software, computing, and any other topic I feel like.

Sunday, June 26, 2005

Java is the worst of both worlds

Unless you were sleeping on the first day of your programming languages class, then you know that there are two kinds of programming languages, compiled and interpreted. Compiled languages are those that are routinely converted to some other language (usually assembly/machine code) for execution. Interpreted languages aren’t. Another program interprets the code on the fly and makes the program work. And no, pseudo code is not a programming language, it’s a human language. Don’t even dare confuse the two. See the entry titled “Humans are not Computers” if you disagree with me. You will realize the error of your ways.

Both types of languages have their advantages. Compiled languages tend to be able to squeeze the most out of their host platform because there is no interpreter to slow things down. However, much of the “information” about what the program is supposed to do is lost since we’re converting from one language to another. You always lose some insight when you convert from one language to another.

Interpreted languages on the other hand tend to be more flexible and easy to use. Because interpreted languages don’t have to worry about what the code actually does until it has to do it, it can allow a lot of ambiguity. The interpreter can figure out a lot more things by itself if it has the data that needs to be processed at hand when it interprets the code. A lot of flexibility comes from the ability of the interpreter to interpret any code given it, even if that code didn’t exist until runtime. The PERL eval() function takes PERL code as a string and can interpret it on the fly. Also, interpreted languages are executed on the fly, the interpreter has more information about what the programmer meant to do, so it can optimize many things that a compiled language can’t. This capability hasn’t been exploited as much as it might be. The Java folks have done some work with just-in-time compilation. I suspect this is where they get ability to hit benchmarks as well or better than C++ code.

Ah, Java; the savior of all of use who are trying to write software for everything from mainframes to calculators to cheese slicers and unmanned exercise machines. Java is the worst of both of these types of languages. It isn’t an interpreted language, it’s compiled. But it isn’t compiled to machine code to take advantage of native code, it’s compiled to Java byte code, which is then interpreted. “But byte code interpreters are really fast!” they say. I don’t care how fast they are, unless they’re so fast they don’t actually run, I don’t much care. If they take time, they take time. You just can’t get around that.

Now I have nothing against interpreted languages. PERL is one of my favorite tools. But look, Java just doesn’t give you any of the flexibility of an interpreted language. Once you’ve compiled to byte code, you’ve gotten rid of all that semantic goodness that is found in the original program. So you’re interpreting without any of the benefits of interpreting, and compiling without any of the benefits of compiling.

I hear folks saying, “what about the platform independence? Isn’t that a great thing?” Yes, yes it is. But there a lot better ways to solve that problem. On the compiled end of things, you can use platform specific code wrapped by platform independent APIs like STL, Boost, Qt and wxWindows. Or just write platform independent code with conditional compilation (#ifdef’s for the buzzword impaired).

On the interpreted end, things are even easier. Just write platform specific interpreters. This is probably the way to go when performance isn’t an issue. And even if it is, then JIT techniques might help your cause.

Java just isn’t the answer.

Labels: ,

Comments: Post a Comment

<< Home

This page is powered by Blogger. Isn't yours?