… I also didn’t actually _test_ my changes . Bad Brock.

I’ll take a stab at it later today.

Here is my first pass: https://gist.github.com/941066

Feel free to fork and improve!

You should like the perl community then. Post any piece of code or article you might want to publicize on reddit and/or perlmonks first and you *will* get a plethora of improvement inputs, as well as one or two rewrites if you ask for it. (The only reason it doesn’t happen more often is because often writers think their example code is perfect as is and react offended even to the most well-meaning advice.)

“you seem to think that writing modern Perl would have a) made this article harder to write and b) made it harder for the readers to follow.”

but I have explicitly said in my first comment:

“Given the deadline, my solution was to explain in detail, among the many scripts I’ve written for myself in the last years, one that produced interesting figures and contained examples of as many different Perl features as possible.”

I thought the statement above was clear enough, but if it isn’t I’ll now try to say the same thing in another way. What I thought and still think is this: there is no doubt that, at the end of the day, “modern Perl” code would have been at least equally easy, for the reader to understand. However, there is also no doubt that writing the article in that way WOULD have been harder (as in “requiring more time than doing as I did”, not as in “more intrinsically difficult”) for me under the existing constraints, which made me very unwilling to modify any code. I only had time to reuse as is existing working code as a basis for an explanation. And when writing for a paper magazine, space and time constraints are badly linked. You can’t do as M. Twain wrote: “I didn’t have time to write a short letter, so I wrote a long one instead.” I had almost no time, and I realized from my experience that I could only meet the deadline by leaving the code as is and trimming the explanation until it fit in the available, fixed space. That’s it, really.

Since I did NOT “sold” the result as the best Perl possible solution and explicitly warned as much as I could about its limits (1), I remain pretty happy with the result, and hope you and your readers will keep all this in mind.

The last statement refers to this other thing you wrote:

“I maintain that a solution written using modern Perl techniques would have been shorter and easier for the beginner to understand. At some point over the next couple of days I plan to rewrite your program using the techniques I’m talking about to demonstrate exactly what I’m talking about.”

That’s great. I mean it. I wish that this happened every time I write a tutorial. I AM happy if what I write stimulates both novices to look for more in depth resources to learn more, AND experts to provide better, more complete resources specifically aimed at those novices. A lot of the problems with all FOSS (not just Perl) today come from the fact that the experts community doesn’t interact enough with everybody else.

(1) This and my previous comment in this thread do little more than explain all I actually meant and had in mind when I wrote in the article “This script is *not* the best solution for the problem it wanted to solve…”

It took me less than one hour to write these two comments in this form, yet they amount to 1305 words. That’s almost 2 FULL pages of Linux Format, as you can read in the specs at http://www.linuxformat.co.uk/writers/index.php/Four-page_tutorial.

If I had had to tweak these same concepts to make all of them appear explicitly in the same space, together with the code and its explanation, it would have taken quite a few days. (to me, at least). Modernizing the code would have taken much less time, of course, but still more than I considered safe to spend, given the deadline.

Thanks for taking the time to reply.

It helps to know that the article was written under strict time constraints and I agree that this probably explains why the the article wasn’t proof-read at all. However, I’m not that I agree with the rest of the conclusions that you draw.

You seem to think that writing modern Perl would have a) made this article harder to write and b) made it harder for the readers to follow. I can’t agree with that at all.

By “modern Perl” I’m not talking about big new Perl modules like Moose or Plack. Those are certainly an important part of any modern Perl installation, but it’s just as useful to make use of the many small but important syntax improvements that have been made in the last few versions of Perl.

For example, you have used the older, two-argument version of “open” and you use it with global filehandles. So your code looks like this:

open FILE, '<some_file.txt' or die;

Modern Perl would write it like this:

open my $file, '<', 'some_file.txt' or die;

That’s no harder to write and I’d argue that it’s more readble. Treating a filehandle as a regular scalar is one less concept for the programmer to worry about. And the fact that the filehandle is automatically closed when the filehandle goes out of scope is another bonus. Also, the three-argument version of “open” is safer.

You say that space constraints prevented you from writing the best program to solve the problem in hand. I maintain that a solution written using modern Perl techniques would have been shorter and easier for the beginner to understand.

At some point over the next couple of days I plan to rewrite your program using the techniques I’m talking about to demonstrate exactly what I’m talking about.