2004-07-18

Java GUI portability; scripting languages

It's often quite difficult to write UI that works well on the Mac in addition to Linux, especially if no-one had the Mac in mind at the beginning. But there's something really exciting and fresh about writing some piece of UI on Linux, and finding when you run the same bytecode on a Mac that it looks great. Sometimes better than the original (because, for example, the Mac's JProgressBar is beautiful, and Linux's one is functional but plain), but both being good approximations to the UI that was in your head.

All this talk of scripting languages overtaking languages like Java is nonsense until at least such time as a scripting language has anything like as good as Swing. It needs to be at least equivalently full-featured, and it needs to have an equivalent ability to fit in on various platforms. Both of which rule out tk (despite its rather powerful text widget), the latter of which rules out such things as RubyCocoa. Anything that isn't part of the default installation is also a non-runner; I can use Swing out of the box if I have a Java VM, and the same must be true of any Python/Ruby solution. (I'd also suggest as a requirement that it must not require any more Perl to be written. There's enough of that effluent polluting our environment already.)

Java, in turn, could really do with even faster start-up times. Java 1.5.0 is visibly better than 1.4.2, but it's still not in the same ballpark as Ruby. And regular expression literals would make an enormous difference. I never get a regular expression string literal right first time.

To be honest, I think Groovy probably has the best chance of becoming as useful as Java, because it can simply use Swing. And Groovy is hardly going to hurt Java's presence. In the meantime, Java and scripting languages are useful for very different things, with relatively little overlap.