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.

I’m sorry you had such a poor initial experience. Maybe I can help you through some of the rough spots, considering this seems to be a requirement for your course? I’ve been developing in Perl professionally for the past twenty-five years and can assure you that there is logic and reason to it.

Email me at mjg@phoenixtrap.com and we can work things out.

Regarding point 4, why are you using that syntax? With recent (at least 10 years old I think) versions of Perl you can just do:

sub func1($x, $y, $z) {
    // do something with the variables
}
func1(1, 2, 3);

If for some reason you need to use a very old Perl interpreter, there's still a better solution:

sub func1 {
    my ($x, $y, $z) = @_;
    // do something with the variables
}
func1(1, 2, 3);

Michele.

I think the reason that modern IDEs does not have good support for Perl, is that there are too few people working on implementing that support. If you want to improve IDE support in Perl I would recommend contributing (submitting PRs), see for example: github.com/richterger/Perl-Languag.... If you are a beginner in Perl, asking questions at stackoverflow.com and perlmonks.org are also great ways to get involved in the community and learn more.

I've read criticisms of perl in the past and some of them are valid, but, the above seem to come from a poor grasp not only of perl, but of languages in general. Sorry, but the average programmer who reads e.g. Learn perl in 2 hours 30 minutes, should be clear on almost all the points most of which stem from a misunderstanding of what perl arrays & hashes are and a misunderstanding of what values vs references are in general.
There's also a misunderstanding of how language parsers work too, I'll take example 11 for that. Perl does give you the convenience that for keys of perl hashes you don't have to quote the string (as long as it starts with a letter). But, why do you think an unquoted value would be interpreted as a string, how would the parser know it is a string? Would the string one as a value work in ANY other language unquoted? A bare word like that in most languages would either be a function call or macro or a syntax error, how could it ever be a string? Why would anyone be confused by that? If you don't like "inconsistency" you can avoid perl's handy skipping quotes for key strings and do it like on any other language:

%m1 = ('one' => 1);
%m2 = (1 => 'one');
print %m1;
print %m2;

Since you don't understand even such basics, I can't go into how the usage of $/@/% (based on older shell languages, so it was mostly familiar to shell programmers) apart from having a learning curve helps the parser in order to make a more powerful syntax for the language.

Sorry to be like that, but it is rarely that I see such ignorance from someone who claims to have programming experience in multiple languages. I've used over a dozen languages over the years and always choose the right one for the job - even though I have personal favourites (yes, for a quick shell script you cannot beat the expressiveness of perl).

At point 5, I don't see any overhead in using references. It's just the same amount of code...

sub func1($aa, $ab) { print $aa->[0]; # First element of first array }

my $aa = [1, 2, 3];
my $ab = [4, 5, 6];
func1($aa, $ab);

Same applies to point 6:

sub func1($f) { print $f->{one};  # Prints "1" }

my $f = { one => 1, two => 2 };
func($f);

Hope this helps!

Michele.

"Weird", in my book, is something that doesn't match pre-existing models in someone's head, i e tells more of the person's close-mindedness than anything else. In other words, haters gonna hate.

No programming language can read your mind (point 6, among others). If you want the keys, ask for them:

func keys %f ;

If you want the values, ask for them:

func values %f ;

Perl absolutely has its uses in low-level shell scripts, running server-level heavy-duty functions.

The problem that I see with Perl is its connotation as an older, early-born language that hasn't evolved (even though Perl totally has) -- very likely correlated (if not caused) by your 12th point.

As for point 13, this is my go-to example of Perl:dev-to-uploads.s3.amazonaws.com/up...