Hate Perl

The setup

For the purposes of this blog post, I will present the sections of my little file one at a time, and write a bit to explain the confusion it represents. At the end, I will include the whole thing so you can print it off and put it on your wall, to remind yourself not to waste your time with this language. Anyway, the first part of the file is a simple function declaration, or what would be a simple function declaration in any other language:

The idea is that I can call the answer() function whenever I want in the rest of the program, and it will output a line with “1” on if the argument was equivalent to true, and a line with “0” on if the argument was equivalent to false. Notice here that you can’t just declare the function as sub answer($arg), you have to treat the argument to the function as an array with one element (called, naturally, @_) and then define that array yourself, with the variable $arg in it which is going to take the value from inside that array. The $ after the function name, by the way, doesn’t actually correspond to anything else in the function, it just represents the fact that the array Perl forces you to create has only one argument. Also notice that I am using strict mode here, to prevent me from writing any dodgy code that might confuse myself. Let’s see how well that works.

Attempt 1

Simple right? I’m declaring a variable $a and giving it a value of 1, but then declaring a subroutine where $a isn’t defined, so it will output 0. Unfortunately, no, that’s wrong, because functions inherit variable assignments from the outer scope.

Attempt 2

So this time we expect the output to be 1, because $b is set before the bar() function runs. The actual output, though, is 0, because $b is given its assignment after the function has been declared, and the function only knows about values from above where it is defined.

Attempt 3

When the function is defined, $c is equal to 1, so when it is run, that is the value it will output, won’t it? Nope, because as long as the variable is defined before the function, the function will pay attention to you updating it, so the new value of $c will be used by answer().

Attempt 4

What could go wrong? The if statement is always true, so the code inside it will run, setting $d to 1, which means surely answer($d) will output 1. Except it doesn’t, because the $d defined inside the then clause is in a different scope, so outside of it $d is back to 0.

The full script

Below is the full script, with comments to help you remember why Perl acts so strangely.

As explained, the script outputs:

Reveal

I hope you all spotted the obvious trick I used there. If I hadn’t put those sections in the correct order, the script would produce a warning, wouldn’t it? For those of you who don’t realise what I mean (but haven’t given up on the idea of ever understanding Perl), try changing $b to $e the two times it occurs in that file. That’s right, you get the output:

Some of you may still be asking why $b works when $e doesn’t, and you’d be right to ask. It took me and three colleagues a long period of head scratching to work out what was going on here, and that was after I spent even longer trying to work out why one piece of code was working and another one wasn’t (“It can’t be the variable names, it must be this extra line I’ve added, or this comment…”). Have you ever tried Googling for $b? Fortunately, our resident Perl guru eventually managed to recall the particular “interesting quirk” of Perl regarding $a and $b. This, then, is the point of no return; no language could ever justify its existence after doing something as arbitrary and unpredictable as this. If you don’t hate Perl now, nothing I can say will convince you.

So what’s the best language in the world then? Surely not Java, with its verbose syntax and strict object-oriented structuring of code? No, the answer is Groovy.