Chad Perrin: SOB

3 January 2007

some Perl issues

Filed under: Geek — apotheon @ 03:17

I like Perl quite a bit. I find it very productiveness-enhancing. It’s easy to write readable code, as long as you have a clue what you’re doing and what makes code “readable”. Its syntax gives clear visual clues to implementation details that can be important for maintenance. It’s one of the most flexible and syntactically powerful languages out there.

It does have some problems, though, and right now I feel like I need to get a few of those problems off my chest.

  1. Dereferencing syntax sucks. You get something like a half dozen different ways of dereferencing a reference in Perl, and they’re all so similar that the variation is almost entirely pointless. Furthermore, once you start nesting references to create complex data structures, your code starts looking like chicken scratch. It’s ugly, unwieldy, and generally just bad.
  2. Lexical scope isn’t default. This is a relatively minor one: it’s easy enough to just use my() when you want something to have lexical scope. On the other hand, you should almost always want to use lexical scope, which suggests to me that lexical scoping should be the default. It’d save a lot of typing without sacrificing any readability. Of course, we’re stuck with it now, because altering that would probably break every single (worthwhile) Perl program in existence that has more than six lines of code in it.
  3. Object oriented programming is a mess. Granted, it’s better than OOP in something like PHP or VB, but it’s still a mess. This could be blamed on a number of other issues with the language, such as dereferencing syntax, because Perl’s object model was cobbled together basically by inventing a couple of implicit arrays and core functions that tie together a bunch of features already extant in the language. I’m of the opinion that OOP in Perl deserves its own complaint, however, because the decision to base it off of other, also broken, constructs in the language betrays the existence of a really broken philosophy of OOP, and because Perl’s object model more firmly entrenches those other issues so that we’re even less likely to see them ever change for the better than we would be without Perl’s object model.
  4. Parenthesis requirements are inconsistent. I’m generally in favor of allowing programmers to either use parentheses or not as they desire when using functions or subroutines. There are other instances where parentheses are not so optional, however. For instance, trying to declare several lexical variables in one statement via my() without using parentheses just doesn’t work — and how they are used is a mite unintuitive when examined in the context of the language.
  5. Prototypes are gutless. Try building a subroutine that optionally takes a block of code as an argument some time using prototypes, and you’ll see what I mean. Sure, you can do stuff like write your own prototype handling code into the subroutine that will handle that kind of usage, but at that point I have to ask why Perl has prototypes built into it at all.
  6. Sigils get reused. It’s not common, but every now and then I see sigils get reused within the language’s syntax in a way that makes it more difficult to parse the code from time to time. For instance, regular expressions use ^ to anchor a pattern to the beginning of the string being parsed, and $ to anchor it to the end of the string. On the other hand, character classes use ^ as a negation operator within regular expressions, and scalar variables beginning with $ are used in regular expressions all the time. This can at times be very confusing, especially if your variables are in fact references, and you’re dereferencing them within the regex (at which point you can get a number of $ characters strewn through the thing), or if you use implicit scalar variables within your regex matching patterns.

Of course, most of this will supposedly be fixed in Perl 6. That assumes we ever see a release-worthy Perl 6, however — and it will essentially be a completely different language anyway. I’m not sure it’s even possible to fix these problems without creating a new language, of course, because they are so thoroughly integrated with the entire Perl corpus. In any case, Perl 6 is looking an awful lot like vaporware at this point, so don’t hold your breath.

Now that I’ve got all that off my chest, I have some Perl programming to do. It is, after all, better than any of the alternatives available to me for most of the programming I do these days.

All original content Copyright Chad Perrin: Distributed under the terms of the Open Works License