Sometimes people ask me why Perl marketing is so important. This morning I came across an excellent example of the kind of thing that we’re trying to counter.
In the current issue of Linux Format, there’s an article about building a Twitter client in the bash shell. It’s written by Nick Veitch – who seems to dislike Perl a bit. In the article he wants to URL encode a string and can’t find an easy way to do it in bash. He writes:
However, the compromise I’ve found for this isn’t too bad (props to http://stakface.com/nuggets). It uses Perl and, like everything in that language, it looks like you ought to sacrifice a goat or something before you run it.
perl -p -e 's/([^A-Za-z0-9.-~])/sprintf("%%%02X", ord($1))/seg'
It’s not clear to me which part of the Perl make him want to start sacrificing goats. Is it the s/// syntax that Perl borrowed from sed? Perhaps it’s the regular expression syntax that Perl shares with pretty much any language with regex support. Or maybe it’s the sprintf function that Perl borrowed from C and that many other languages (including bash) support with a pretty similar syntax.
Of course I’m not saying that Perl doesn’t have some grungy corners in its syntax. But the three pieces of syntax used in this code fragment look to me like things that should be understood easily by just about anyone with experience of programming in the Unix environment.
And if this code is so hard to understand, why use it? I don’t know what Nick’s programming language of choice is, but couldn’t you do exactly the same thing in Python, Ruby or PHP? I can’t believe that Perl is the only language that is so powerful. And I’d be very surprised if the same code didn’t look very similar in many other languages.
So why the unnecessary little dig at Perl?
Of course, it’s clear that Perl isn’t a language that Nick is particularly familiar with (neither, indeed, is the person who he took the solution from). Anyone who knew Perl would realise that Perl’s standard distribution includes the CGI module which contains an escape function which does exactly what Nick wanted – without exposing the programmer to all of that scary syntax. I would write Nick’s code something like this:
perl -MCGI=escape -e'print escape "@ARGV"'
There are a lot of people out there with really strange ideas about Perl. People who don’t bother to find out the best ways to do things in Perl. And having widely-read Linux magazines printing snide comments about Perl does no-one any good at all.
This is why I think that Perl marketing is important. We need to reach the people outside of the echo chamber and tell them that Perl isn’t the outdated, hard-to-use language that they are being told that it is.
Update: I should have pointed out that I’ve sent an abbreviated version of this to Linux Format. Hopefully it’ll be published in the next issue. And I’m considering proposing a series of articles on Perl to them.
Yeah, this has been going on for a while now, and the damage has been done. It’s been cool to rag on Perl for years.
I agree. The other problem with the verbose code used in the article is errors introduced by the complexity of the code. In the example, ord($1) should be ord($1)) to close the sprintf paren.
[Update: That error is probably a typo that I introduced. I was copying the code from the magazine as I couldn’t find it on their web site. I’ve corrected the typo now. – Dave]
Hi Dave,
Wouldn’t be a good idea to send a letter to Linux Format. Leaving out the specific Perl marketing content, it’s also a good read for experienced programmers in other languages (as they will mentally translate the code in the language of choice).
Hi, the tutorial, as you know was about trying to achieve something rather complicated in bash. I make no great claim to being a Perl programmer, so I am sure there are several dozen different, better ways of doing it.
The inclusion of a Perl one-liner was to solve a problem that would have been more complex to do simply in bash. I could’ve used Python (in which case urllib.urlencode() would have done the job), but coming off the back of writing a Python column for about 18 months, my guess was the LXF team didn’t want me to start writing Bash tutorials in Python too.
As it was that line looks more complicated to the average reader than the rest of the code. As you’ve pointed out, it could have been achieved more simply, so thanks for that. Though, the one-liner I used seems to pop up in various places, so I’m clearly not the only one who needs re-education.
As for the marketing of Perl… I honestly don’t think that more than that one line of Perl code has appeared in Linux Format for months if not years. I’m sure the team would welcome a short series if you or someone else could write it.
Nick
Not to mention the incorrect character range in the regex that excludes all characters in the range from the full-stop to the tilde. What was probably intended was something like:
[^A-Za-z0-9._~-]
I don’t think any level of activity will counter this sort of stupidity. Part of it is him playing to the crowd because he knows they like to read about that sort of thing, and the other part is that he doesn’t give a shit that he doesn’t know Perl. I’m constantly surprised how people actually take pride not only in their ignorance rather than their mastery, but their lack of research skills.
It’s not that hard to ask the world how to get something done and likely get really good answers within an hour. The job of a writer is to do that research and present the final product to the audience. Instead, he admits to cargo-culting it. What he’s really telling the world is that he doesn’t care enough to do a good job or learn more.
There’s no point marketing to people who don’t care.
And, it’s not like magazine editors care either. They are more like project managers than editors. As long as they can fill the space they need to fill, they tend not to care what you write.
Hey!
I’m sorry to hear you have such a negative opinion, Brian. I’m the editor of Linux Format, and I’d like to think we try a bit harder than just filling space – although this example does seem to have annoyed a few people.
You’re right, and I’m not unashamed to say that my own Perl knowledge is terrible – I’ve lost track of the number of times I have to refer to one of Brian’s books to help me solve a pretty remedial problem, and I honestly imagine that the kind of code I write would make any serious Perl programmer cry bitter tears. That said, like Nick, I tend to use Perl for quick hacks – I don’t think I’ve ever written a script longer than 20 lines – and so in a way I’m not particularly upset if it’s a less-than-perfect solution, because all I care about is that it works.
In this example, Nick was doing pretty much the same: it was just a quick hack to satisfy a larger, non-Perl problem. If we were writing a Perl tutorial, I would use a Perl expert and thus expect back tutorials of the highest degree.
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!
In the meantime, I’ll print your email in the magazine as a correction. Would it be OK if I also included your suggestion of “perl -MCGI=escape -e’print escape “@ARGV”‘”?
Paul
—
Paul Hudson
Editor, Linux Format
Did anyone actually edit his article, or did you just print what he gave you? Who was the person who let the comment stand?
Hi Paul, thanks for joining the conversation.
I’ve taken the liberty of fixing the quotations in your first comment and deleting the second one (which no longer seemed necessary).
Thanks for offering to print my email. Please feel free to add my code snippet to it.
But I do think that both you and Nick are missing the main point of my post.
I know that most people who use Perl aren’t Perl experts and won’t keep up with the latest trends in the Perl world. I also know that many people just want to get their job done using Perl and will often do that by Googling for an answer to their problem. That will often not give them the best answer, but if it works for them then I don’t really see a problem there.
The reason for my post (and the bit that you’re ignoring) is Nick’s silly little snipe at Perl. As I pointed out above, none of the syntax in his example is unique to Perl so I don’t see why he felt it was necessary write that and I don’t see why you didn’t edit it out of the article.
I wholeheartedly approve of of your choice to write Perl tutorials though. Paul is a great teacher.
As soon as I see a regexp I know the game is over.
Why do we still tolerate such obscuritanism?
Isn’t the whole perl marketing need more easily explained by the fact that Perl is one of the oldest scripting languages, one of the most popular, and therefore there is lots of old, bad Perl code lying around that anyone can pick up?
Flaming one person writing in one article is ridiculous (I don’t really know or care whether that person needs flaming, I just think pinning cause and effect of wide ranging symptoms upon one individual is the equivalent in sloppy reasoning that Bryan pins upon the author himself with regard to failing to do adequate research).
In any case, at least the dude was using Perl in the first place for a current day problem.
On which point: I would have thought the best marketing for Perl is for more folk to use Perl and write about it, whatever the problem (with helpful Monks posting perhaps more erudite ways of expressing the same thing), rather than flaming folk for using it “incorrectly” or flaming them for being opinionated. That is not very good marketing, either.