I don’t like coding in Java. As a collection of libraries it’s not bad, but as a language it’s full of syntactic vinegar. Simple tasks in Perl and Python are chores in Java, distracting me from solving real problems and obscuring the code with extraneous detail. At least Java 1.5 makes things a little sweeter by introducing some language features–instead of more libraries–that I’ve enjoyed in other languages for more than a decade.
Java syntax is basically C minus pointers plus objects and exceptions. I love C for its minimalism, efficiency, and transparency. However those traits also mean working the language in addition to working the problem, like needing to explicitly code string processing behavior atop arrays of characters.
That’s great for teaching how computers work, and I say require C for all first-year computer science students. It’ll weed out the weak and give the survivors a good foundation to build upon. That’s not so great for a developer on a deadline solving a complex business problem. Try coding C against the string-centric Documentum Client Libraries (DMCL) if you don’t believe me. Been there, done that.
Then I migrated my first Documentum project to Perl. This language let me work the business problem while it worried about the details. Writing Perl code against the DMCL was faster, less error-prone, and more enjoyable. Stellar string support helped, but lists and hashs changed my entire approach to solving problems because of how effortless they were. The language understood them in context, “doing the right thing” underneath, like magic.
Coming back to Java (1.4.2) from Python recently, I was particularly vexed by handling collections of things. Besides all the casting, I found myself having to revisit the 70s and do this:
// things[] -- identical to C
for (int i = 0; i < things.count(); i++) { ... things[i] ... }
// List things — still C-like but easier to manipulate elsewhere
for (int i = 0; i < things.size(); i++) { … things.get(i) … }
// List names as iterator — more “say what you mean”, still cumbersome
Iterator thing = things.iterator();
while (thing.hasNext()) { … thing.next() … }
These all feel clumsy and out of date like bell bottoms and leisure suits. Even using the Iterator approach feels wrong. Talking it through in terms of “for each” feels much more natural than “while”. Here’s how I prefer dealing with this kind of loop:
# In python,
for thing in things:
... thing ...
# In perl,
foreach (@things) { … $_ … };
So I’m browsing my monstrously thick new copy of Java in a Nutshell for what’s new in 5.0. I couldn’t actually use any of it since my last client hadn’t upgraded from 5.2.5 yet, but it might be nice to be prepared for my next client. To my surprise I saw this:
for (String name: names) { ... name ... }
Finally! I can say what I mean in the code and not clutter it up with irrelevant implementation details. It might not sound like much, but the less I have to fight with Java means the more work I can actually do. Also, I’ll take what I can get with Java.
It’s not magic of course: The new for syntax manipulates an iterator under the covers. As it should. I get the same functionality with less code and it’s more human-readable. The old way still works of course, and sometimes I might need that approach when position matters more than order.
I hope Java continues to grow as a language instead of just piling on the libraries. My last Java project was unavoidably littered with implementation artifacts and gratuitous casts. Another new feature in Java 1.5 helps out with the latter but isn’t quite as seemless. It’s a start.
What really demonstrated Java’s language deficiencies to me as a Documentum developer was Jython, a Java implementation of Python. Jython can use any Java class out of the box–including the Documentum Foundation Classes (DFC)–with all the syntactic sugar of Python. Tasty! The built-in shell mode even allows experimenting with DFC interactively. Fabulously tasty!
I can’t escape Java as a Documentum professional if I want to avoid being one of those architects that never gets to code. Unfortunately too many IT managers drank the DFC Kool-Aid and believe that knowing Java well is more important than knowing Documentum at all, a fallacy to examine another time. At least I’ve got some syntactic sugar to soften that next bitter swig of Java.
I originally showed printing the name in each example, but perl of course has some ridiculously easy ways to do this (like
print "@ARGV";) that would take away from the real issue here. The yadda-yadda-yadda with the reference method doesn’t make Java look quite as cumbersome and reflects the more likely case of needing a few statements to process each element of the list.