Five things I hate about Perl

Enough advocacy, let's get to the nitty gritty of 5 things I hate about Perl. (After brian d foy.)

1. The difference between list and scalar context is subtle. One bug that bites people too often is this (for some value of "people", including me, far too often):

   sub myfunc { return }
       my $scalar = myfunc(); # contains undef
   
       my %hash = (
           key => 'value',
           key => myfunc(),
       );

   In scalar context, we get undef. But in list context, myfunc returns a list of zero elements. Guess which context hash declarations are in...

   Luckily in this case we'll get a "Odd number of elements in hash declaration" warning. Perl's warnings are mostly very useful and surprisingly helpful. However:

2. Some warnings suck. Yes, some of them almost always point out an error (the void context error is useful: I usually find it means I've written: my $x => 1 instead of my $x = 1) but some are more irritating.

   When was the last time an 'uninitialized' warning had any effect on your code apart from making you have to sprinkle $x ||= '' throughout your code? Yet I usually restrain myself from adding no warnings 'uninitialized' because maybe one time in a hundred there's a genuine bug I need to know about.

   Similarly 'once' warnings sound useful, but in practise are usually because you've referred to a magic global that's used plenty of times in the library you want to use. For example, from List::Util's documentation,

   my $sum = reduce { $a + $b } @list;

   will warn about $main::a and $main::b being used only once. $a and $b are the canonical magical variables, wtf is that about? (mst suggests that these warnings are inhibited for sort only, which was their first use case).

3. Argument passing. Yes, it's really flexible to be able to unpack @_ in any way you want but I'd like a proper way of doing it. (And yes, there are all kinds of solutions including Devel::Declare, but none are standard yet). Oh, and we don't have full destructuring bind, so yes, you can do ($x,$y) = ($y,$x) and my ($self, %args)=@_, but not my ({foo=>$foo}, [undef,undef,$bar]) = @_.

4. It's a big language, with lots of syntax, several powerful minilanguages, a vast array of standard idioms, a large set of standard libs (including various incompatible ways of doing similar tasks) and a truly staggering number of 3rd party libs, CPAN, with even more ways of doing it. Actually, learning a big language is fine, but the bigness is one of the things making Perl difficult to parse. The other is the sheer amount of flexibility that Perl gives you to shoot yourself in the foot, change the way the language is parsed etc. Only Perl can parse Perl, and usually only after executing part of your code first. Yay for exploits on your language-aware text editor!

5. Functional programming isn't easy or elegant. Yes, we have first class functions, but things like argument unpacking being ugly make it less convenient. Little kludges like the functions passed to map and grep taking $_ rather than the usual argument list @_ just add to the fun ($_ seems like a special-cased points-free hack, and it's far less consistent or common than Haskell's currying)

   I also dislike that regex substitution etc. can't be done as a non-destructive function.

Hmmm, there are probably more things, but those are the main ones. In particular I don't hate references (yes, they take a little learning, and I'm aware that's a stumbling block for most learners, but they are quite sensible once you do) or OO (baroque, but quite capable, and see Moose for a cute modern take on it).