Perl Bad

I haven't used Perl much since 1998 or maybe 1999, when I discovered Python. Or rediscovered it, I should say; I knew of Python from some prior life but had dismissed it as irrelevant because it uses indentation to indicate program structure.

What?

Well, in most languages, you'd write a loop by enclosing it in markers like this:

for i = 1 to 10:
    print i.
end.

Or this:

for (i=1;i<10;i++) {
    printf("%d\n",i);
}

In the first example (written in Progress), the end statement marks the end of the loop; in the second example (in C), the loop is enclosed in curly brackets, { and }. Because the beginning and end of the loop are clearly marked, you could write these two examples as:

for i = 1 to 10: print i. end.

and

for (i=1;i<10;i++) { printf("%d\n",i); }

respectively, and the compiler would be perfectly happy. You write in whatever style you like, as long as those curly brackets or that end statement are in the right place.

In Python, though, you'd write it like this:

for i in range(0,10):
    print i

There's no end, you see. The fact that the statement print i is indented relative to the previous code tells Python that it's part of the loop. If I follow it with the line:

    print i*i

with exactly the same indentation, it will be part of the loop too. If the line isn't indented (or more precisely, is indented to the same level as the enclosing block), then it indicates the end of the loop.

Which looks really pretty, but is a bad idea, because if anything happens to your indenting, your program won't work any more. On the other hand, it's a good idea, because it's a very common problem that a programmer will change a piece of code without fixing the indenting, so that the program looks like it does one thing but really does something else.

You can't do that with Python.

But if something does happen to your indentation, your code is toast. The Pythonistas speak of a whitespace-eating nanovirus, but HTML will do the job just fine:

for i in range(0,10): print i print i*i

That's the exact same code, only this time I left it as normal HTML text. Python won't like that at all.

So from a language-design standpoint, it's kind of a problem. From a practical standpoint, though, it turns out to be a pretty good tradeoff. I've only once been bitten by the whitespace-eating nanovirus, and while it was painful I've seen plenty of code lost due to editor accidents or files getting overwritten or good old drive failures, so one lost program isn't really that bad. The fact that the layout of the program always reflects its function really is a blessing - though it still doesn't stop people from writing incomprehensible Python code.

There are a few main points that I like about Python. First, the code is clean. With Perl, you get lines of code like:

my($tag) = @_;
return ("start_$1","end_$1") 
  if $tag=~/^(?:\*|start_|end_)(.+)/;

That's not even a particularly bad example. That's pretty normal Perl code. And I find it just as nasty as you do. Python doesn't fill your screen with $@_!?^*+/ unless your modem has dropped out.

Second, it comes with a nice, flexible and fairly rich standard library. It doesn't have a vast collection of modules like Perl's CPAN, which sometimes seems to have modules for every conceivable requirement, but it does have a decent library, and it's standard. If you have Python installed, you have the standard library. (It's possible to screw this up, but it takes effort.)

Third, Python is dead easy to install on any Unix platform. Download and unpack it, then it's the familiar configure, make, make install dance. Blippy blip blip, and you're done.

Perl's install is somewhat weird. It has a Configure script, but if you don't know about the -d option, it will ask you all sorts of questions that you will probably have no idea how to answer. So you keep hitting the enter key, and after a while you start getting all these strange messages (Python's configure gives strange messages too, but it doesn't bug you constantly). Then it asks if you want to make dependencies, and you say what the hell, why not? Then you make, and then you make test, which takes forever, and then you make install -

And then your friend Susie contacts you in a panic because her blog is toast.

Oops.

But all you've done is updated Perl. Everything MovableType should need is built into Perl by default. But now it's complaining that DB_File.pm is missing in action. DB_File.pm is the code that handles MT's databases; without it you can't update anything, and though people can still read your blog, they can't leave comments.

Not good. So you take a look, and sure enough, you've overwritten every trace of the old version of Perl. Rats. Well, DB_File should have been included, but no problem, you'll just specify it manually: ./Configure -D DB_File -de to make sure this time. Then make, make install...

Which you do, only nothing changes at all. So you Configure again, only this time you actually read all of the text scroll ing past. And you notice this little bit of unpleasantness:

Checking Berkeley DB version ...
You have Berkeley DB Version 2 or greater.
db.h is from Berkeley DB Version 3.3.11
libdb is from Berkeley DB Version 2.4.14
db.h and libdb are incompatible.
I can't use Berkeley DB with your <db.h>.
I'll disable Berkeley DB.
Removing unusable -ldb from library list
libs = -lnsl -lndbm -lgdbm -ldl -lm -lc -lcrypt -lutil

So much for DB_File. Gone bye-bye.

Now you check your libraries. You've got three different versions of Berkeley DB installed (all of them out of date, of course, but not to worry, even fairly old versions work well enough), and some weird links between them, but the default library is version 3.3. So it should work.

Check your library path. It's not looking anywhere weird.

Do a find, to see if there's a copy of libdb.so lurking somewhere strange. Nope.

Eh. Well, the Configure script actually creates a little test program to see what version of Berkeley DB you have. So you copy that little test program and compile it manually, and it works. Perfectly happy. What? How?

Time to Google. Which turns out to be no help at all. MovableType's support forum isn't much good either; mostly it suggests using MySQL. But there's a mention of recent Linux C libraries including Berkeley DB themselves, and the problems this causes if you want a version of Berkeley DB other than that in the C library.

A clue.

Well, if your program found the right version of Berkeley DB, but Perl doesn't, that must mean that Perl is picking up the wrong version from the C library. So you look at the libraries that Perl is using, and sure enough, the C library is listed before Berkeley DB. Change that and keep your fingers crossed while the whole thing rebuilds...

Success! We're back on the air! After two hours of pointless wrangling with Perl, it's decided to do what it's supposed to. MT is happy, I'm happy, Susie probably won't be happy because I have a nasty suspicion that it ate her post.

The whole thing started because I was trying to set up Image::Magick so that MovableType could generate image thumbnails. Image::Magick requires Image Magick (no great surprise), which of course is not installed. And Image Magick doesn't want to compile because it doesn't like my version of Perl. No problem, that version of Perl is out of date anyway; I'll just fetch the latest release and install that and aaarrgh!

What possessed Six Apart to write MT in Perl in the first place I'll never know. There are people in the world who program in Perl by choice, just as there are people who eat brussels sprouts or live in North Dakota or listen to System of a Down.

If they'd written it in Python this whole hideous mess could have been avoided. Of course, then I'd have had to find something else to rant about.

Posted by: Pixy Misa at 01:17 PM | Comments (4) | Add Comment | Trackbacks (Suck)
Post contains 1372 words, total size 9 kb.