Some people have reacted to my bit comparing Perl and Java from earlier today. I think that my piece came across as trashing Perl, which I didn’t want to do. I like Perl. I write a lot of Perl, and in the past have written a whole lot of Perl. Let me post my simple explanation of my problem with Perl for systems development. Perl gives you many ways to do most things, and many of them are incredibly concise. For the expert programmer, this is wonderful. A guy like Rael Dornfest can cram what would take a whole block of code in most languages into one tiny line of code. My problem is that on most of the projects I’ve worked on, some of the programmers were not what I would refer to as experts. The same goes for maintenance — in many cases, code written by an expert will be maintained by someone who’s not an expert. The more expressive a language is, the more likely it is that non-experts will screw it up.

In some ways, writing code is a lot like speaking a language. Have you ever met that person who is always trying out new words that they saw used somewhere, and getting them wrong every time? The same thing happens with programmers, and a complex language like Perl provides people with a lot more vocabulary and grammar to butcher than Java does. You can butcher Java just as well as you can Perl, believe me, but the potential for doing real damage is greater with Perl.

Dan Lyke says that when you use idioms like the one in my example, people have a hard time with the first one, but then catch on and the conciseness turns out to be a readability advantage. It’s a valid point, and I think it illustrates a general principle that good software engineers follow: consistency matters. Regardless of the construct you prefer to use (there are three examples in my item), make sure that you always use that same construct in similar cases in your code. If you use a for loop for a task in your program, and then a few lines down, you use a while loop for basically the same task, you’re not helping anybody. Over and above indenting your code properly and naming variables properly, establishing a coding style of your own that is consistent and sensible makes you a much better developer.

Speaking of consistency, Mark Hershberger busts me for inconsistency when I say that you could write Perl code just like the Java code that I wrote, but that if you did so, I’d consider you to be a bad Perl programmer. I guess my response to that is that you should use the tools that are available to you. If you’re a Perl programmer, I feel like you should write things in proper idiomatic Perl, and then expect the other people who look at your code to have the Perl expertise to know what you’re doing. Just as I’d say that if you’re porting a Windows application to the Mac OS, it should work like a Mac application. I admire the code in Bloxsom, it’s really well written, but at the same time I had to puzzle over it a bit to figure it out because I’m rusty. That’s not Rael’s fault.

In any case, I like Java for what it is, and I like Perl for what it is. For the type of work I’m doing these days, I find myself preferring Java, but I would never say that Java is better outright. It’s just different.

Update: I just found another well-written response to my Perl and Java comparison. The author is right in saying that I’d be better off stuffing the code into its own function. My intention was to talk a bit about how Perl and Java differ, not explain how one should construct a program. He also says that you should avoid Perl’s idioms, but then the question I ask is whether you should use Perl at all? I know sometimes you have no choice …