One of the most popular entries in the You are not a ‘real’ Java developer until… post (that was mostly meant to be funny, by the way) was the one about the amount of lines of code required to read a file in Java.

Many people stated the obvious: All it takes is writing your own utility class, or library and reuse that. Fair enough. However, spending effort on implementing my own solution of a language feature as basic as file I/O is a major drawback in productivity. Or creativity for the matter, because it drives the focus away from more important issues that need to be addressed, like the actual business logic my application is supposed to express. Someone mentioned that there’s a basic principle that applies to all programming languages: DRY. Absolutely. So how much DRY was applied to a language that requires you to wrap its File I/O routines in a utility class after all these years?

People mentioned that a programming language’s potency should not be measured in lines of code. Could not be more correct, plus I don’t think anyone claimed this ever being a valid measure. Any ideas what it should be measured in? A popular notion was the supposed flexibility offered by Java against dynamically typed languages. Hmm… If “flexibility” is what we’re aiming at, we might as well code in C/C++. Or, in fact, Assembly. All these languages rock, by the way. I can’t imagine having to use them to write a web application for a client that needs things to be delivered on schedule, though.

Or maybe someone out there was disappointed when Collections were introduced in Java? Who needs them, when you can implement LinkedList yourself?

Back to DRY in relation to writing your own libraries. Sounds like a bit of an oxymoron has slipped in there… It’s like choosing to get a screwdriver and parts to make your own blender in order to make milkshake. I can obviously see the fun and challenge in this, but it’s not exactly what I’d like to be doing in a dynamic environment when the quality and stealth of delivery play a very important role, and this sounds much more likely to be the state of the environment most of us have to work in every day.

Trying to pinpoint what makes a language better than another is too abstract a subject for anyone to come up with any concrete suggestions anyway. However, the choice is highly dependent on the problem we’re trying to solve, and for a significant number of problems out there at the moment, there are better tools for the job than Java. And I do believe what makes a good mechanic is his judgement in terms of the choice of tools.

I guess what I’m trying to say is that it might pay off to try something new out before we dismiss it just because we feel threatened that it might take over something we already know and are comfortable with. And then decide whether it might be the way forward or not. It’s called evolution and it’s a Good Thing. That’s exactly what happened to me the first time I did import java.net.* (I still really like networking in Java, by the way).

Oh, and lighten up a little bit. It’s supposed to be fun.

This entry was posted on Friday, June 16th, 2006 at 12:27 am and is filed under Software. You can follow any responses to this entry through the RSS 2.0 feed. Responses are currently closed, but you can trackback from your own site.