So, I've been using Perl yet again, as the utility I've been working on, buck-security, is written in Perl. And it does leave something to be desired. Here's a few of the things that have bothered me since I've been using it a bit more.

1) There is no interpreter. This is a pain, because it is an obstacle in the way of experimentation. There is a trick, which is run it in the debugger, but this is a cumbersome trick and should be unnecessary. I have no real idea why there is no interpreter; it could be history, it could be philosophy.

2) There is strange semantics, often. The comma is an operator which concatenates things in a strange and unpredictable way. If you are more used to Python, the comma is a false friend.

3) Perl positively encourage global variables. 99% of the time, a global variable eventually has to be changed to a more local variable and then you always wish you, or the person who originally wrote the code, had started out in the right way, with a local variable.

4) The "grep" function is not about regular expressions. This is deceptive. It should have been called filter, because that is what it does. This problem is probably due to history.

5) The fact that arguments and return values are always arrays but are dressed up to look like something else is unfortunate. This can cause problems, because a small mistake will result in one argument overwriting another. This has probably been the source of about 1/2 million Perl bugs since Perl began. I had a few myself.
My first experiences with Perl were pretty rough. There was a time when Perl was the hot new thing and I decided then that I ought to learn it. I tried, and there were quite a few things that made it a bad experience. First, I had no real experience with similar languages, having been formally instructed in C++ and being in the process of learning Java. Second, I had little experience with Perl's chosen domain, which coincided with the domain of shell scripts. Third, I picked a book which, while highly regarded then and having gone through many editions since, only confused and irritated me.

Later I became more sophisticated, more skilled and more knowledgeable. I learned some programming language theory and discovered that many PL theoreticians viewed Perl as an object lesson in poor programming language design. I experienced Perl pitfalls in my new, sophisticated persona, and with my new PL knowledge realized that the language really was to blame and that it wasn't all my fault. Several times, I found myself debugging severely broken ten line Perl programs written by some of the best programmers I knew. This did not inspire confidence.

Lately, though, I'm feeling better about Perl. I've seen Perl scripts written with considerable discipline and I've encountered a text, "Learning Perl the Hard Way" by Allen B. Downey which told me something useful on the second page. After I'd read one and a half chapters of this book and a bit of "Higher-Order Perl" by Mark Jason Dominus I was able to write a simple script that automatically calculated the recursive CPAN dependencies of a particular script. Of course, I used existing modules from CPAN itself to do the heavy lifting, so the script was only 50 or so lines but it was not a pain at all. Features the script uses are:

  • anonymous and higher-order functions

  • foreach

  • named function arguments

  • constructing and dereferencing references

  • object orientation

and of course I make my variables local, use warnings, and use strict. Not bad for a first.

Do I have a sophisticated, mature understanding of Perl? Not in the least. Do I finally have a bit of traction with the language? I think so.



September 2013

151617 18192021


RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Oct. 21st, 2017 07:37 pm
Powered by Dreamwidth Studios