Every once in a while I am forced to contend with the Java programming language, and I almost always end up disgusted and disappointed as a result. My experience with Java is usually that it takes 5 lines or so of code to express a single idea.

You get to a spot in your program where you want to frob a string. You do a quick google and you find a string frobber class, so you grab it. Now mind you, frobbing a string is a very simple thing, but precisely because Java is so verbose and obnoxious, it seems like a better idea to download code that someone's already written and tested.

Now's where the fun begins. I think you should be able to write something like:

    mystring.frob();

This is easy in a prototype-based language -- you can add a method to an existing class. If that seems too fancy, I'd be ok with this:

    frob( mystring );

Or, if you want to protect the namespaces in your app:

    utils.frob( mystring );

But in Java, you're bound to end up with this kind of invocation:

    ...
    protected static frobbableString frobString
          throws java.frob.frobProblem ( String string ){
        //TODO: Try to use frobbableString as input here
        frobbableString myFrobbable = new frobbableString( string );

        //TODO: Statically attach factory
        stringFrobberFactory frobFactory = new stringFrobberFactory();

        //TODO: Pool stringFrobbers
        stringFrobber myFrobber = frobFactory.make();

        return myFrobber.frob( myFrobbable );
    }

The funny thing about this is that Java heads will tell you that strict typing makes the program safer. They'll also tell you that putting everything inside its own class is the only way to do OOP.

As for the first claim, it seems obvious to me that the strict typing basically catches errors in code that you only have to write because of the strict typing. So great: the extra code you have to write can be checked by the compiler, but strict typing doesn't guarantee that you're not doing something stupid. In fact, the actual creative and inventive part of programming gets replaced with a typing excercise, so that by the time you actually get to writing interesting code, you're more likely to do something stupid.

Now the second claim, about the strict objecty-ness of Java, has more merit. It is true that Java allows for unparalleled integration of other people's code. The problem is that you end up integrating all this extra code that really, honestly, might be just as easy to rewrite yourself. I've written about this before, so for now I'll just say that integrating a library that does a simple thing often causes as many problems as it solves.

It strikes me that Java is almost as much intended for code editors to read as it is for humans. I'm sure that part of the reason that I dislike Java so much is that I use VIM to edit it, so I don't really get much of the benefit of the droning, reptitive nature of the language. Oliver Steele touched on this in his IDE Divide article, but he's a lot less judgemental about languages that are hard to use without tools. From my vantage, using a tool forces a developer into a certain way of thinking. Writing code by just typing it in must be a more creative process: it's faster and less constrained and more similar to regular 'ol creative writing, which is what software development can be at its best.

The reason that I bring all of this up is that someone here at Laszlo recently sent around a Flex coding example that shows how Flex 2 implements states and transitions. Now Laszlo has had this stuff for years, so it's nothing new here, but I was struck by the extent to which the coding example looked like Java. It's just hard on the eyes: what with all of the repeated keywords, the sheer volume of code required to do something relatively simple, and the long ugly script blocks. Now this may just be a bad example -- I don't know if anyone at Macrobe would endorse it -- but it is in keeping with what seems to be the trajectory over there. They're making enterprise data connectors and slowly trying to turn ActionScript into Java.

As Jim Grandy, director of OpenLaszlo, has pointed out: we tried using Java to program UI in the 90s. It doesn't work so well. UIs are full of edge cases, and the best ones are fluid and flexible. I actually couldn't be happier about the direction that Flex is taking; they can have the UI coding-as-enterprise-development market. Laszlo, on the other hand, is going pretty much the opposite way. We're looking at adding unique, dynamic features to our environment (like Traits,) and we're working on extending Laszlo's flexible, concise style to the server.

More about that next time. If Flex is gonna be the Java of RIAs, we're happy to be the Ruby on Rails.