Discussion on: 13 reasons why you should not use Perl

I should point out that you've been mentioned in today's issue of the Perl Weekly newsletter, so you'll probably get a few more comments over the next few days. I hope the Perl community will keep things civil, but I can't guarantee that.

I've been teaching Perl for twenty years and you raise many of the same problems as a lot of beginners in Perl. In many of these cases, things are how they are because the increased power and expressiveness they bring to the language. Let me see if I can explain.

1. Sigils are an important part of the language. I confess that I now get slightly confused when I use a language without sigils. But one big thing they bring is the ability to directly interpolate variables into strings - print "I have $x problems, but Perl ain't one". This is such a common requirement that I think it's a net gain for Perl.

2. The number of bugs in your code is proportional to the amount of code you write. Writing less code means introducing fewer bugs :-) Of course, you can add the missing variables yourself, if you want. No-one is going to stop you.

3. Honestly, I think readbility just comes down to practice. Oh, and (self-imposed?) coding standards. There used to be a thing where Perl programmers tried to write code that was as short as possible or as hard-to-read as possible (just for fun, you understand, that code wasn't mean to be used in real projects) and I think that gave Perl a misguided reputation for being hard to read. It doesn't need to be like that.

4. Perl now has support for subroutine signatures. They're currently marked as experimental, but I expect that will change pretty soon. They're really powerful.

5. Perl's parameter passing consistently confuses people from other languages. Honestly, I think that flattening aggregate data structures into @_ was one of the biggest mis-steps in Perl's design. I'd love to see @arrays and %hashes passed into subroutines as single elements of @_. But Perl loves backward compatibility and that would be almost impossible to achieve now. The best alternative I can suggest is to only use anonymous arrays ($array = [ ... ]) and hashes ($hash = { ... }) instead. Actually, thinking about it... that also removes the need for many uses of the @ and % sigils, so it might solve a lot of your problems from point 1 as well.

6. Most of this is covered in point 5. But, yes, when you unroll a hash into a list, you get a list of key/value pairs. And they're in random order. But you populate a hash by giving it a list of key/value pairs - %french = ('one', 'un', 'two', 'deux', ...) - so I don't think that's too surprising.

7. It's mostly possible to use regexes without needing to use variables like $' and $&. You can even get away without the capture variables like $1 and $2. And the /x option on the match operator makes it possible to write regexes that contain whitespace and comments. As I said in point 3 - Perl doesn't need to be written to be as unreadable as possible.

8. This is true. But the search function on the Perldoc web site doesn't ignore punctuation.

9. Perl's built-in command line debugger is pretty grim. Most Perl programmers ignore it (fun fact - we'd improve it but I don't think anyone understands the code!) Many IDEs have hooks that understand the Perl debugger and present it to you in a much nicer manner.

10. Here's a good tip. Always add use strict; and use warnings; to every Perl program that you write. They will catch many of this silly little slip-ups that we all made. In your example, you would have seen the warning Use of uninitialized value $a in print.

11. Two things going on here. The left-hand side of a "fat comma" (=>) is always interpreted as a string. And the right-hand side is an expression. Expressions can contain function calls. So your real disagreement with Perl here is that you don't want Perl to execute subroutines if you don't explicitly put parentheses after the name (one()). Perl programmers like to omit unnecessary punctuation, but I can see your point here. I think it would be great to have an option that allows a programmer to demand parentheses on subroutine calls (something like use sub_parens). I should also add that if you want Perl to see a string as a string then the best approach (as with most other languages) is to put it in quotation marks.

12. There's a saying that "only perl can parse Perl". It means that Perl syntax is so complex that only the compiler (the program perl) can completely parse the language (Perl). There are projects going to produce easier ways to parse Perl (PPI is a well-known one). But, yes, IDE support for Perl needs to improve.

13. Honestly, hate seems like a strong emotion to use on a programming language. But that's your right, of course. Honestly, the way the industry seems to be going now I think it's very unlikely that you'll need to use it once this course is over.