Back in September 2010 I wrote a piece criticising the way that Perl had been described in a recent issue of Linux Format. In a response to my article, the editor wrote:
And, believe it or not, I do care about Perl. I met Paul Fenwick a few months ago, and he agreed to write a Perl tutorial series for us – I hope you agree with my choice!
So when I saw that a new series of Perl tutorials was starting in the “Coding Academy” supplement of the new issue (#149, June 2011) I was looking forward to reading a useful introduction to the language written by Paul Fenwick.
Unfortunately, I was disappointed. The tutorial was written by Marco Fioretti and, to be honest, it really wasn’t very good. It failed on three fronts.
- The English wasn’t very good
- The explanations of Perl were, in places, rather out of date or just plain wrong
- The sample Perl code included some rather outdated practices
Let’s look at those three areas in more detail.
English Language
Obviously, English isn’t Marco’s first language. And his English is far better than my Italian. But I’d like to think that if I was writing for an Italian magazine, then the editors would tidy up my writing so that I didn’t make myself look too foolish. It appears to me that the Linux Format editors did nothing to correct Marco’s English. Here are a few examples of infelicities that slipped through.
“Before looking at the code, however, let me explain which data it uses…”
“Perl arrays and hashes are much more flexible than it shows in these pages…”
“The complete code of the procedures is in the DVD”
Of course, there’s nothing terrible there. We know what Marco meant. But the magazine would have looked a lot more professional if the editors had taken the time to edit this article.
Misunderstanding Perl
Marco’s knowledge of Perl seems a little mixed up or out of date in places. For example, he says:
You call a subroutine by adding a & to its name and passing parameters
It’s been several versions of Perl since the & has been required on a call to a subroutine. You won’t see it in any modern Perl code. It just makes the code look unnecessarily messy. Later on in the article, Marco says:
Perl does have while, if, for and unless, but it lacks a C-like switch operator for multiple, mutually exclusive choices.
The Switch module was added to Perl in version 5.8.0 (in July 2002). A much improved version called given/when was introduced in version 5.10.0 (in December 2007). Anyone who thinks that Perl doesn’t have a switch statement simply hasn’t been keeping up.
Outdated Perl
The Perl idioms that Marco uses are often somewhat outdated. In particular he uses the two-argument version of open instead of the safer three-argument version. He also uses global filehandles instead of lexical ones.
Marco also has a rather distinctive style for his Perl code, much of which runs counter to the advice in the perlstyle manual page or the Perl Best Practices book. In particular, his use of capital letters for variable and subroutine names will look very strange to someone used to reading Perl code formatted in a more traditional manner.
All in all, I think that Marco’s style does nothing to counter the reputation that Perl has for encouraging unreadable code and that with a little thought the same program could have been written in a far more readable manner.
Marco’s attitude to keeping up to date with Perl is nicely demonstrated by the books he recommends. “Programming Perl” and “The Perl Cookbook” were last updated in 2000 and 19982003. He would have been far better off recommending “Learning Perl” (which does keep up to date – the fifth edition was in 2008 and the sixth is currently in progress) or Modern Perl.
It’s a shame that the promised series of articles by Paul Fenwick hasn’t materialised. But it’s even more of a shame that Linux Format has fallen back to using articles written by someone who is not interested in keeping up to date with modern Perl. In light of this disappointment, I’d like to make the following offer to Linux Format.
If you want someone to write an article about Perl (whether that’s a one-off article about a particular topic or a series of tutorials), if you get in touch with me then I will find the best person to write that article for you. I may even do it myself if I have the time and the knowledge. Further to that, I am more than happy to proof-read and edit any Perl articles that you have currently in the pipeline.
I don’t believe that the Perl community in the UK is particularly difficult to track down. but if I’m wrong then I’m quite prepared to the the conduit that people to use to contact the community.
[I’ve found the sample program from the tutorial on the CD and have put it online.]
I’d be happy to write Perl articles for any magazine that wants them, and if they really wanted a tutorial series, they’d get the king of Perl magazine columns, Randal Schwartz, to do it. I don’t think either of us has ever turned down a magazine that wanted Perl content.
Here is what I don’t understand and I will use myself as an example. If a magazine came to me and said “Bob, we want you to do a series about Perl.” and I say “Great.”. They next thing I would do is look around and see what is happening in Perl to make sure what I am going to write and a lot of people are going to read is “Good Perl”. I don’t understand the mindset of anyone doing anything less than that.
Oh wow, that code is rotting to the core. I’m really not sure where all these ‘Perl’ people come out of the woodwork when an article is required, it seems the find someone who was using Perl in 2002 and who has been doing PHP, Ruby, DotNET or maybe even BASIC since then.
Sad that Perl actually can’t get a fair view or a fair trial in the media.
I’m also willing to do any articles for magazines. Other people who know Perl, love Perl and enjoy Perl should also volunteer.
Dave,
thanks for your comments. PLease let me answer point by point.
English language: yes, English isn’t my first language. Thanks (I mean it!) for helping me to improve my written English, I always greatly appreciate help. The editors of all the magazines I work with know that English isn’t my first language and it’s not a problem. Not because I’m special in any way, but because all editors of every magazine around proofread and tidy up every article anyway, no matter what the native language of the author is. Apparently, this time it didn’t happen with this specific article. Why? I don’t know, but maybe a possible explanation is below.
Misunderstanding Perl/outdated Perl: the request to write a project-based Perl tutorial came out of the blue with a **very** tight deadline, while I and the editors were brainstorming about other topics. Please let me point out that statements like “if they really wanted a tutorial series, they’d get the king of Perl magazine columns, Randal Schwartz, to do it” are a bit naive. Of course Randal Schwartz, you and many other people could write a Perl tutorial better than me. But in real life you can plan as much in advance as you like, then something happens and you must change and react quickly, even if what is doable quickly isn’t the best of all conceivable solutions.
Secondly, goal and target of that article. The tutorial *had* “to be accessible to people without any Perl experience and finish with something tangible”. 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. So YES: the script as is is NOT the best or most modern Perl you could and should produce. But please note that I have EXPLICITLY said so myself in the conclusion: “This script is *not* the best solution for the problem it wanted to solve…”, even if for space constraints I didn’t explain there all the single reasons for that statement, and the other things I’m explaining now in this comment.
Even with those limitations, the script works without problems and is not a Web Server or any other mission-critical code, so I feel it did satisfy the requirements.
One reason why I feel so is that the goal here was introducing to Perl and, more in general, to the power and beauty of scripting languages, absolute novices. Linux end users, who don’t need to program for a living. Those are the people I normally have in mind when I write.
What I love about Perl, and what I try to communicate when I write about it, is how efficient it makes you in a very short time, even if you know very little about programming and even if it’s not “Good Perl”. In scenarios like those of this and other scripts I present there is no need for heavy optimization, 100% robustness to attacks and so on.
In scenarios like those, “Good Perl” is not the most modern and most efficient code. In those cases, which often are one-time needs, “Good Perl” is what gets the job done consuming as little as possible user time from beginning to end.
What I like and find “Good” about Perl is, first of all, that you can find online (or in your own backups from the ’90s!) loads of 10+ years old scripts that will work without a glitch today and solve a small problem in a FRACTION of the time (from finding to downloading, adapting and running them) that it would take to write from scratch the best possible Perl code that does the same thing. Answering to Andrew’s comment, “Perl is so good that even ten years old code is useful today”: this is what I tried to communicate.
Had I been asked to write a Perl tutorial for (wannabe) software professionals, I would have written a TOTALLY different piece or, depending on the target audience, said immediately “please ask somebody else”. But this was not the case here. And maybe that piece will encourage more novices to continue and come to websites like this to learn more.
Hi Macro,
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.
Dave,
you wrote:
“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.
> 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.
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.)
Wow. I’m a bit surprised that Paul Fenwick was going to write a “Perl tutorial series” for Linux Format. Not that he couldn’t, just that – as his business partner – I haven’t heard the idea mentioned. Sounds awesome. If anyone needs it written, please contact me; direct messages to Paul can sometimes result in a slower responses as he’s often on the road.
I did wonder about that. I meant to ask him about it back when I first heard.
The Perl Cookbook was updated in 2003 (http://oreilly.com/catalog/9780596003135/) though that is still ~7 years old.
You’re absolutely right. Thanks, I’ve corrected the post.
So are we going to do this, or what?
Here is my first pass: https://gist.github.com/941066
Feel free to fork and improve!
A good start. But you missed the obvious improvement of replacing the C-style for loop with a foreach.
I’ll take a stab at it later today.
I agree. The trick there is that it is actually wanting a slightly larger refactor — the loop index is being used in ways that I didn’t bother exploring. I was also thinking a better parametrized ‘main’ sub would clear up the rest of those globals. The original had some global-usage bugs — for example DRAW_BORDER_ADD_CAPTIONS sub took in $BC and $BP (caption and price) parameters, but actually used the globals.
… I also didn’t actually _test_ my changes 🙂 . Bad Brock.
Honestly, I can’t tell that the English phrases you list are bad (must not be enough context). The Perl, though, is definitely gross. I reminds me of reading scripts that my professors write; always a blast from the past! I sometimes learn new things reading old scripts, but the reason they are new to me is because the community buried them long ago.
One specific thing I notice is the line my “$PIC_NAME;my $CAPTION; my $PRICE;”.
Was there ever a time when you couldn’t pass “my” a list? “my ($pic_name, $caption, $price)” is much cleaner in my opinion.