It was far too easy to come up with dislikes, and not so easy to come up with likes. It was a perfect example of the adage that “Every programming language sucks, but some of them suck more.”

That said, the one language that scored more likes than dislikes, for me, was Perl. Here are some of the things I like about Perl:

1. Different sigils improve readability. The only data types that matter in Perl are easily distinguished. While we’re at it, ensigillizing your variables means you can stick them in print statements without having to step out of the quotes: print "foo equals $foo and bar equals $bar" is pretty easy. A sigil-less language like JavaScript requires print "foo equals " + foo + " and bar equals " + bar so the interpreter knows when to print the value of foo and when to just print the string “foo”.
2. Scalar vs. list context means the language effectively doubles its potential function namespace, because each function can (potentially) return one thing in scalar context and another thing in list context. (For example, the “grep” function can either return a list of matches, or just the number of matches it found.)
3. The language is compact. (Contrast this with PHP…)
4. Function names are generally chosen pretty well, so that an experienced programmer can generally get a good idea of what the function does. (Contrast this with, for example, Prototype.js’ Enumerable.include() method. This name looks — at least to me — like it should do something, but instead, it actually returns a Boolean based on whether the Array, Hash, or Object in question contains the given property. I understand this is based on Ruby’s Array.include? method, but the removal of the question mark results in a confusing name.)
5. Nearly all built-in functions have default arguments, which are sensibly chosen. For example, if no array is passed to shift(), it will shift @ARGV. By default, print() prints $_, and pattern matches match on $_.
6. The presence and uses of the $_ variable are reminiscent of pronouns in human languages. Once I’ve referred to, for example, “John”, I don’t have to keep calling John “John” every time I want to talk about John. I can just say “him”. Similarly, once I’ve set up, for example, a while (<FILEHANDLE>) construct, I don’t have to refer to each line as $line. I can go ahead and pattern match on $_ without having to construct an extra variable. And since the pattern-match operator operates on $_ by default, I don’t even need to mention it… This is huge. This is a core part of what makes Perl Perl. Effectively, it has pronouns.
7. The language doesn’t enforce any particular programming paradigm. It easily supports procedural, object-oriented, and functional programming. It has anonymous functions, first-class functions, and closures.
8. Regex extensions like \b, \d, and \s, and especially \W, \D, and \S, make my life easier. (I continually miss them when working with non-Perl regexes, such as egrep.)
9. The standard substring-finding mechanism (“do a regex match”) returns Boolean. This stands in stark contrast to the more usual substr(), which tries to do too much: it returns the position at which the substring was found, or an out-of-band value (such as -1 or Boolean false) if the substring wasn’t found. This means that if I just want to know if the substring was in there or not (but I don’t care where it was), I have to do an extra check against that out-of-band value. For example, I have to do if (false !== substr($haystack, $needle)) in PHP, or the equivalent if (haystack.match(/needle/) != -1) in JavaScript. Note that JavaScript, even though it uses a regex match, still returns a positional integer instead of a strict Boolean! This gives me too much information, making me hang an ugly-looking “!= -1” off the end for no benefit.

By the way, just to round out the list, here are a few of the things I dislike about Perl:

1. You have to manually unpack and assign function arguments? What was Larry Wall thinking?!? I’m okay with “sub” instead of “function” as the function declaration keyword (just barely), but not being able to declare the argument names as part of the function definition? That’s just bizarre and weird, and it hurts every time I have to write a separate my ($foo, $bar, $baz) = @_; line after the sub foobar { part.
2. And in every single class method, you need to manually unpack a reference to $self! This is, I’m quite sure, intimately related to the previous problem. But it’s another context in which I keep encountering the problem. Stupid boilerplate like the existence of my $self = shift; in every single method everywhere should simply not ever exist; it should be abstracted out and taken care of automatically.

At one point, I had high hopes that Perl 6 would fix these problems. At this point? The momentum has been lost; the interest in Perl has shifted to other languages (largely Ruby and Python). I recognize that Larry Wall and the Perl team are proceeding at their own pace, and that they’re more concerned with doing it right than with doing it quickly. And I appreciate that.

But they’ve taken so long that I doubt anyone really cares much any more. Perhaps Perl 6 will manage to reawaken interest in Perl… but if so, it’ll be starting from scratch, rather than building on Perl 5′s preexisting popularity. Which is kind of a shame, because there’s so much to like about Perl.

The story is simple: I was tired of seeing “failed password” messages from sshd cluttering up my logs. I was also annoyed at the constant flow of dictionary attacks, even if I knew they’d never get in. So I whipped up a quick Perl script that acted as some glue between Swatch and iptables, and which would also give me some amount of reporting and history on who and what it was blocking.

Then I posted about it in my online journal, and a friend said it sounded useful. So I started getting it ready for release as a package that anyone could use…

And promptly realized that doing a decent, professional job of it would take more time than I had available. Fast-forward to now, when I’m unemployed and can only spend so many hours per day job-hunting — the result is that the world gets more software!

I just came across a great example of one use of Big O Notation, in examining the trade-off between conciseness and efficiency in Perl functions to find the smallest member of an array. While looking around for a good Levenshtein algorithm implementation, I noticed this helper function:

# minimal element of a list
#
sub min
{
    my @list = @{$_[0]};
    my $min = $list[0];

    foreach my $i (@list)
    {
        $min = $i if ($i < $min);
    }

    return $min;
}

And I thought, "Hmmm, that's a little odd. Why go through that entire loop, when you could just do:"

sub min {
	my @list = @{$_[0]};
	return (sort @list)[0];
}

Of course, hard on its heels came the thought: "Wait a second... how do those stack up in Big O?"

Without even bothering to look at the source code, I'll assume Perl's sort() is an implementation of Quicksort, and will achieve O(n log n) performance on most sane data. But the min() function supplied at Merriam Park is O(n); for any situation where log n is greater than 1, the n log n function will take longer than the just-plain n algorithm.

This would make a wonderful "teachable moment": point out to the class that my function is shorter, and easier to read and understand, but the other one is more efficient. This is exactly the sort of thing that Big O Notation is useful for, and it's something that can't be easily expressed just by looking at the code itself.

(Not that I'd try to tell the class that one way or the other was automatically better. The real usefulness of this example is the way the psychological complexity and the computational efficiency are in opposition to each other. It makes a great springboard to talk about how we decide on what trade-offs to make in engineering.)