more Perl aggravation…

For some time I’ve been trying to get amavisd-new to play nicely with ClamAV using Mail::ClamAV under FreeBSD. It just would not behave – I would get an error like /usr/local/lib/libclamav.so.1: undefined reference to pthread_mutex_create() and fall over. (This error message would only appear if amavisd-new was being run in debug mode; otherwise, mail would just silently fail to be delivered and queue forever.)

Well, I finally discovered the problem: Perl is not built multithreaded by default on FreeBSD! 🙁 You have to build Perl, defining WITH_THREADS and this will work.

Obviously this isn’t apparent from the above error message. It looks like ClamAV is the culprit, rather than the ClamAV.so that’s built by Mail::ClamAV. I guess it’s just because in the course of using the ClamAV API, libclamav.so.1 is the caller, so the runtime link problem is wrongly attributed to it.

Perl blows camels!

Oh Perl, how I do loathe thee!

Perl sucks. (Or, to paraphrase Larry Wall, there are a hundred different ways to say Perl sucks.) Just off the top of my head I can name a number of things I hate about Perl.

  1. Perl syntax is unintuitive and difficult to learn or remember. Aside from the various different kinds of punctuation and their meanings ($foo != %foo != @foo) you have commands like “chomp” or “carp”. Every time I think I’ve mastered all the Perl hack-isms, I come across another one. Today’s favourite is qx(). I thought I’d already seen these all with q(), qq(), and qw(). But apparently there’s qx(), which encloses the argument in backticks so that the argument gets executed in a shell, e.g. my($foo) = qx(ls -l). Now tell me, without looking at the Perl manual, does qw() enclose the argument in single or double quotes or parentheses? Thought so.
  2. To expand on a point in #1, the punctuation is out of control. According to my Perl reference we have (at least) $!, $", $#, $$, $%, $&, $', $(, $), $*, $+, $, $-, $., $/, $:, $;, $< , $=, $>, $?, $@, $[, $, $], $^ and a whole bunch of $^A through $^Z. It’s totally out of control and so bad that Perl has an English module just to deal with this crap.
  3. In the spirit of being “hackerly” Perl often does away with variables entirely. $_ is the implicit variable so you get code like:


    while (<>) {
      if (m/^#/) {
        print;
      }
    }

    Look ma, no variables! (Also: Look ma, no hope of ever maintaining my Perl code six months from now.)

  4. Taint mode, my old nemesis. It’s just such a joke, even without the stupid taint mode bugs. The whole premise that user data will be clean after some regexp checking is bogus — because more often than not, said regexps will be insufficient — and it’s a complete waste of my CPU cycles to track “tainted” variables.
  5. Object-orientation is another joke, and bolted onto the side of Perl. How else can you explain code like:


    sub new {
       my $proto = shift;
       my $class = ref ($proto) || $proto;
       my $self = {
         CCPARAMS => undef,
         TRANSPARAMS => undef,
         DEBUGGING => 0,
       };

       bless $self, $class;
       return $self;
    }

    (Mea culpa, this is my code… but seriously, when my successor comes along to look at this, are they really going to have a clue what the hell is going on?)

I could go on, but I think I’ve proven my point, which is that Perl was obviously written by “real” hackers who must have sat down and thought, “wow, won’t it be impressive to our fellow brethren to have ‘funny’ commands like croak or carp in there? We’ll be sooooo hip!” Of course, I suppose it’s also a job security thing; most Perl code out there is so obfuscated that companies have no choice but to keep the Perl hacker employed, or else the infrastructure will fall down. (Never mind that the programmer spends 3/4 of the time figuring out what the hell his code was supposed to do, and the other 1/4 of the time fixing the problem.)

Don’t believe the hype. Use Python. You don’t have to listen to me: listen to Eric Raymond.