This weekend I was checking out the code for Blosxom. I’m thinking of trying to hack it up and turn it into a package for managing your photo library. Anyway, Blosxom is written in highly idiomatic Perl. If you’ve ever looked at the source code for Greymatter, let me just say that you can think of it as the anti-Greymatter. That’s a good thing. I still hack out Perl scripts somewhat frequently, but I don’t do any development any more in Perl, so messing around with Blosxom is sort of a brain teaser for me.

For example, in Blosxom, you find code like this:

$depth and $depth += ($datadir =~ tr[/][]) - 1;

Unless you’re a pretty serious Perl programmer, you won’t have any clue what that does. In Perl, you can use bare expressions like the one above as statements in your code, creating very concise control structures. That statement could be written more understandably like this:

if ($depth)
$depth += ($datadir =~ tr[/][]) - 1;

That line inside the if statement is still fairly confusing though. The tr (translate) operator replaces all of the slashes in $datadir with nothing. That’s not what it’s being used for in this case. It also happens to return the number of characters it replaced. So this line of code adds one less than the number of slashes in the variable $datadir to $depth.

As an example of how much functionality you can stuff into one line of code, this statement is an incredible example. It exploits the fact that you can just stick bare expressions in your code, a lesser known usage of the tr operator, alternate delimiters ([] instead of /), short circuiting boolean operators, and more. The same code in Java would look something like this:

if (depth > 0)
int count = 0;
for (int i = 0; i < datadir.length(); i++)
if (datadir.charAt(i) == '/')


depth += count;

Clearly the Java code is much more readable, and that's why I like it from a maintainability perspective. That said, if you're really up to speed on your Perl, it's amazing the sorts of things you can compress down into one amazingly byzantine looking line of code. The debate between Perl and Java programmers falls exactly along those lines. The Perl partisans will go to great lengths to tout the expressiveness of the language, which is indeed amazing. But the problem is that few Perl programmers can read code like that, much less write it. I've written tons of Perl in my life, and have worked on a number of Perl books, and I had to think really hard about that line of code (and hit my camel book) to figure out exactly how it worked.

The Java code that I hacked together (without compiling it) is longer, and takes longer to type in, but what it does should be reasonably clear to someone who knows any programming language. When you work on a big team, that's a huge advantage. These days, I prefer using Java, but it's fun to puzzle through a well written Perl program every now and then.

Update: you could write Perl code that looks almost like the Java code above, and it would work, but if I saw Perl code like that, I'd think you were a bad Perl programmer. There are too many easier ways to do it to go down that route (this is both the blessing and curse of Perl, as I've mentioned).

I've posted a follow up to this piece.