[Previous entry: "Dr. Horrible Rules"] [Next entry: "2009 vs 1959 Crash Test"]

09/27/2009: "The Trouble With Perl"

Perl is a great language. It's easy to throw together scripts to do amazingly complicated things. Sure, the syntax is arcane, and there's a steep learning curve, but that just adds to the fun, right?

Well, the other day I was throwing together just such a script and spent several hours struggling through a couple of Perl's idiosyncrasies. Allow me to share them with you.

First is the annoying prototype for sprintf():


my @a = ("%s|%s\n", "apple", "banana");
printf(@a);
> apple|banana

my $s = sprintf("%s|%s\n", "apple", "banana");
print $s;
> apple|banana

my $s = sprintf(@a);
print $s;
> 3


This behavior is due to the fact that sprintf() expects its argument to be in scalar context first. I can't think of a good reason why this was done. And to rub salt in the wound, there isn't any way to force list context instead of scalar context. Bad, bad, bad.

The second idiosyncrasy:


my $hr = {a=>apple, b=>banana};

print @{$hr}{("a","b")}, "\n";
>applebanana

print $hr->{("a","b")}, "\n";
>


The syntax for slices of hash references, i.e. $r->{(some array)} just plain doesn't work. You need to use the alternate syntax: @{$r}{(some array)}. Maybe Larry Wall had a good reason to do this, but it's the sort of thing that gives Perl a bad name. I shouldn't need to spend hours figuring out why a syntactically legitimate construction returns nothing.