Perl Vogue
View more presentations from Dave Cross.
More detail when I get back from Italy in ten days.
In the first, I'm working for a global organisation. Most of their bespoke software is written in Java, but (like pretty much every company) there are a few Perl programs running vital parts of the infrastructure. This company have also outsourced a lot of their maintenance work to another company in India. This Indian company has dozens of people who are dedicated to working on my client's systems. But they are Java programmers and every once in while they need to do some work on a Perl program.
This company has an internal IRC network and there's a Perl channel which I keep half an eye on whilst getting on with my work (which is maintaining a huge Perl program). A few times a day one of these Java programmers turns up on the Perl channel explaining a problem they have to solve in a Perl program and asking for help. In pretty much every case, the problem boils down to the Java programmer having major misconceptions about how Perl works. Perl programmers on the channel try their hardest to to help, but it's often a frustrating experience. Usually the correct answer is "go away and read Learning Perl and Intermediate Perl, then you will understand how the code works". But these programmers don't have the time to do that. They need this task finished in an hour. Often it's a task that could be easily achieved in an hour - but only after you've done the groundwork of understanding how Perl works.
The problem this company had was that Perl wasn't seen as being as important as it actually was. People in the Indian company saw it as a "scripting language" that any of their (no doubt highly qualified) Java programmers would be able to use without any preparation or training. That's clearly not the case.
But, I hear you say, that's not fair. Perl and Java are really different languages. I'm glad you pointed that out as it's a nice link to my second example.
In this example, I'm working for a dotcom company London. Like so many dotcom companies they have a Perl codebase that was thrown together five years ago in a couple of months by people who didn't really know what they were doing. This company has the added problem that they are finding it hard to recruit people with Perl experience. So they start recruiting people with experience of languages like Python and Ruby in the belief that these languages are so similar that the programming skills are completely interchangeable.
And, of course, Perl, Ruby and Python are all a lot closer to each other than they are to languages like Java. But there are differences. Important differences that aren't just syntactic. I can read Python and Ruby just fine. But if I got a job where I had to write a lot of either of those languages, I wouldn't assume that I could just pick it up by osmosis, I'd get a book and read about the language. If I was going permanent at the company, I might even suggest that they send me on a training course.
Conversations with these non-Perl programmers often took a predictable course. They'd start complaining that the code was hard to read. This was hard to counter as a lot of the code was horrible. But if you pointed out some of the newer and better code, they wouldn't see the improvement. They would insist that somehow Ruby or Python code was inherently easier to read than Perl code. I'd try to point out that Perl programmers find Perl code as easy to read as Python (or Ruby) programmers find Python (or Ruby).
So there seems to be this perception that Perl should be as easy to read as Random Programmer's favourite language. And I don't understand why that is. Just because I've been programming for almost thirty years, I don't expect to be able to program in any language I happen to look at - well, certainly not well enough to be paid for doing it.
I'm not sure what we can do to counter this misconception. I think it probably stems from the late 90s when everyone was writing Perl. And if everyone is doing something, then it must be really easy.Of course, most people were writing really horrible Perl because Perl isn't as easy as they thought it was.
Not sure it's possible to sum this up in a simple marketing slogan. "Perl is Easy (but not as easy as you think)".
]]>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 snipe 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.
OpenTech is an annual one-day conference in London where geeks get together and share information about cool things they are doing with technology. The emphasis is on projects that improve society in some way so you'll see a lot of talks about really interesting projects. Usually the talks concentrate more on the user aspects of the projects and it's rare to hear very much detail about the underlying technologies.
I was therefore slightly surprised to be invited to invited to give a talk about Modern Perl at this year's conference. But I grasped the opportunity to speak to a room of geeks who might not be keeping up to date with Perl technology.
The slides are now on SlideShare. Bear in mind that I was aiming at a non-Perly crowd and that I only had twenty minutes - so it's possible that I didn't have time to cover your favourite Modenr Perl project.
]]>I've been using Songkick for a while. Songkick is a web site that tracks users' attendance at gigs. I've been tracking the gigs I've been going to as well as trying to fill in over thirty years of old gigs.
I've known for some time that Songkick has an API, but until yesterday the API has been for invited partners only. But yesterday on Get Satisfaction they announced that it was now public.
The public API doesn't do that much yet. There are only four documented calls. But it's already useful and I'm sure it will gain more functionality quickly.
And this evening I've spent some time writing a very simple Net::Songkick module. This is really just a proof of concept, but I've got big plans for improving it. And I can already write a useful program like this:
#!/usr/bin/perl
use strict;
use warnings;
use XML::LibXML;
use Net::Songkick;
my $user = shift || 'davorg';
my $sk = Net::Songkick->new({
api_key => $ENV{SONGKICK_API_KEY}
});
my $xml = $sk->get_upcoming_events({
user => $user,
});
my $xp = XML::LibXML->new->parse_string($xml);
foreach ($xp->findnodes('//event/@displayName')) {
print $_->to_literal, "\n";
}
If you have any interest in gigs then I highly recommend Songkick to you. And if you like attending gigs and hacking Perl (although not necessarily at the same time) then why not give Net::Songkick a try. All you'll need is an API key from Songkick.
There's a Github repository too; if you feel like hacking on it...
]]>More detail when I get back from Italy in ten days.
I've had two twenty-minute talks accepted:
The Perl Community
The Perl community is a complex and interesting city. I've been exploring it for almost fifteen years and I'm not sure that I've been to every corner of it.In this talk I'll attempt to guide you round some of the more interesting and useful parts of the Perl community. I'll point out some ancient monuments, some nice new areas and warn you about some places where you really shouldn't walk alone after dark.
Things I Learned From Having Users?
When I first started releasing modules to CPAN it was great. I released modules that no-one used. I could release new versions as and when I wanted to.Then people started using a couple of my modules. I started to get email about them. Suddenly my modules were no longer just for me. I had to deal with users.
In this talk I'll discuss how having users effects the way that you develop and release software. I'll also look at a few ways to keep on top of things.
I'm also doing my first lightning talk for several years:
You might not believe it to look at us, but the Perl community is a deeply fashionable place. If you're not using the currently fashionable modules in your code then people will be sneering at you behind your back.
Join Dave Cross for a quick review of the history of Perl fashion.
See you in Pisa.
]]>I proposed four talks last night. I'm hoping that the organisers won't choose more than two of them, but I like to give them a bit of choice. The titles are as follows:
I've also submitted a proposal for a lightning talk called "Perl Fashion". It's been several years since I've given a lightning talk, so that'll be an interesting experience.
Don't forget that there are also training courses (including my course on Modern Perl).
Looking forward to the conference very much. Hope to see some of you there.
]]>But if you're going to ask random strangers for help, you should probably make a bit more effort than this person did. I've reformatted it and corrected the English.
Hello sir,
I am new developer in perl scripting language using MVC Frame works, my doubt is how to write below query in MVC.
$query = "select belarc_update_dt from Device where belarc_update_dt > $expiry_date AND belarc_update_dt <= $current_date AND (scrapped_on > $current_date OR scrapped_on = '0000-00-00')";the above query how to write in mvc frameork can we please help me sir,
Thanks and Regards
How would you reply to mail like that?
Update: I asked which MVC framework he was using. He replied:
I am using CGI::Carp 'fatalsToBrowser' with linux shell.
At that point I gave up.
]]>Here's the description of the course from the YAPC site:
This course introduces the major building blocks of modern Perl. We'll be looking at a number of CPAN modules that can make your Perl programming life far more productive.
The major tools that we will cover will be:
- Template Toolkit
- DBIx::Class
- Moose
- Catalyst
- Plack
We'll also look at some other modules including autodie, DateTime and TryCatch.
There are several other good courses running both before and after the conference. I'm sure there'll be something that you'll find interesting.
N.B: This is not an April Fool's joke!
]]>