I jumped in here to respond to all of the comments that the tutorial was too long. My first reaction was, "How committed would the reader have to be to learning Perl better to be willing to invest the time to read this?"

I timed it, and it took me about 12 minutes to read this article. I did find myself distracted a few times, and I did take some time to consider the implications of the exercises that tachyon demonstrates in the article.

In the end, I agree that the article could use a little trimming and tightening, but I still do not feel that it's *too* long. If someone is not willing to invest 12 minutes to read something that might make their code more robust in the future, then they deserve to waste all of the time with the single-step debugger, and all of the time it takes to write up a message here only to be met with the ubiquitous RTFM response. (Although the lack of that phenonmenon is what keeps me coming back to PM often.)

In the Dot-Com heyday, the streets were clogged with those who desired to leverage technical expertise (somehow) without making any investment of skull-sweat whatsoever. Most of those people have gone back (deservedly) to jobs where they process one-hour film, or hand espresso out the window to people in their SUVs. What is left of us (in this community) are those who understand that a little study is what it takes to make a better Perl (or anything) programmer.

So my conclusion is that this a good and worthwhile article. Like most things, it could stand to be tightened up about 15-20% so that it stays on-point more and so that all of the primary points are crystal clear. But overall tachyon, I'd say that this is the sort of article that makes me wish that we had a continuum to vote for articles. Something like three good, three bad, and a neutral. I'd give this three +++ even before editing.

...All the world looks like -well- all the world, when your hammer is Perl.
---v