Those of you who have been following my work for some time might remember that many years ago I took some interest in Perl books. I don’t mean the kind of books that we all read (or, even write) with animals on the cover. I mean the kinds of terrible Perl books that at one stage seemed to take up over 90% of the space given over to Perl books in most bookshops. They had brightly coloured covers and made unlikely claims about how good you would be with Perl after an unfeasibly short period of time.
They all seemed to be written by people who didn’t actually know anything about Perl and they were full of the most atrocious Perl code that I’ve ever seen. Of course they were all not just about Perl but were about CGI programming with Perl (as that’s what everyone wanted to use Perl for ten years ago). It was easy to tell the quality of these books from the index. You just looked for mentions of “use strict”, “use warnings” or CGI.pm. Most books ignored them completely. At the time Schwern had a “litmus test” for the quality of Perl books. It was list of bullet points that you could use to easily calculate how bad a Perl book was. I seems to have dropped off the internet at some point in the last ten years.
Last weekend I was in the centre of London and I went into a couple of large book shops that I haven’t been to for some time. And it looks to me as though this problem has finally gone away. Looking at the Perl section in Foyles, for example, I saw a very few dodgy Perl books. Of course, there were far fewer Perl books of any quality than there would have been five or six years ago, but the ones that were left were pretty much all decent books.
My initial thought was that this was just another sign that Perl has lost the battle for the low-end web development market. People who want to hack up a web site no longer even consider using CGI programs written in Perl. These days those people would all use PHP. But it seemed to me that there weren’t many “Learn PHP in 24 Hours” books on the shelves either. So perhaps the low-end web development market doesn’t exist any more. Or, at least, perhaps it’s not big enough to make it profitable enough for publishers.
I’ll admit that my sample wasn’t particularly big. And Foyles isn’t exactly your average book shop. It caters for the higher end of the book-buying market. I wanted to test my hypothesis by looking at the computer books section in Borders over the road. But Borders has closed down. Another indication of the diminishing size of the book market.
I’m going to take this investigation further. I’ll check out the computer section in some lower-end book shops. But just to give myself some closure I’m going to declare my campaign against bad Perl books to be over. We won in the end. But it may be a slightly Pyrrhic victory.
The YAPC::Europe organisers have put out a call for training courses. They want a number of courses to offer to attendees in the couple of days before the conference. The call closed yesterday and I expect they’ll be announcing the courses in a couple of weeks.
I’ve given training courses at the last couple of YAPC::Europes so I’ve sent in a proposal for a course. I’m hoping to run a new course called “An Introduction to Modern Perl”. In this course we’ll be looking at some of the tools that form the basis of all modern Perl programming. This will include Template Toolkit, Moose, DBIx::Class, Catalyst and Plack.
I hope that this sounds interesting to some of you and that you’ll consider attending the course (if it gets accepted). Please keep an eye on the conference web site to see when the courses are announced.
And please consider holding off booking your travel and hotel until you’ve seen the selection of courses that will be offered before the conference.
I suppose now I should start thinking about some talks to give at the conference.
It’s eighteen months since I wrote “Why Corporates Hate Perl” and it’s worth pointing out that the company I discussed in that article which was dropping Perl in favour of PHP and Java is still employing as many good Perl programmers as it can find.
I talked in that article about some rather unsubtle social engineering that had been going on at that company. Management had started to talk about Perl as a “legacy language” in an attempt to persuade the business that they really don’t want their applications written in Perl. That doesn’t seem to have been as successful as I feared it would be.
But there’s another kind of social engineering that I’ve seen going on. And this is happening at the developer level. I’ve lost count of the number of times I’ve been sitting in meetings with developers, discussing ways to improve the quality of crufty old Perl code when someone throws in the (more than half-serious) suggestion that we should just rewrite the whole thing using Rails or Django.
There seems to be this idea that switching to a new framework in a new language will act as some time of magic bullet and that suddenly all of our problems will be solved. There are so many ways that this perception is flawed, Here are my two favourites.
- The current system is old and crufty not because it’s written in Perl, but because it was written by people who didn’t understand the business requirements fully, didn’t know their tools particularly well or were under pressure to deliver on a timescale that didn’t give them time to design the system properly. Often it’s a combination of all three. Given the time to rewrite the system from scratch, of course it will be better. But it will be better because the business is better understood and tools and techniques have been improved – not because it’s no longer written in Perl.
- Frameworks in other languages are not easier to use or more powerful than frameworks in Perl. Anything that you can do with Rails or Django you can do just as easily with Catalyst. It’s using a framework that’s the big win here, not the particular framework that you use. Sure, if you’re a Ruby house then using a Ruby framework will probably match your existing developers’ skills more closely but if your current system is written in Perl then, hopefully, you have a team of people with Perl skills and that’s going to be the language you’ll want to look at.
I’m tired of Perl being seen as a second-class citizen in the dynamic languages world. I freely admit that there’s a lot of bad Perl code out there (I’ll even admit to writing some of it) but it’s not bad Perl code because it’s Perl, it’s bad Perl code because it’s bad code.
This is what the Perl marketing initiative is for. We need people to know that Perl is not the same language that they stopped using ten years ago. Modern Perl can compete with any of the features of any other dynamic language.
By al means, try to get the time to rewrite your crufty old systems. But rewrite them in Modern Perl. You’ll enjoy it and you’ll be really productive.
p.s. I should point out that I’m not talking about any specific client here. This is based on conversations that I’ve had at various companies over the last couple of years and also discussions with many developers in many pubs.
I’ve got another set of public training courses coming up next month. They will be held at the Imperial Hotel in Russell Square, London.
There are three one-day courses – Introduction to Perl, Intermediate Perl and Advance Perl. They’re running on the 13th, 14th and 15th of April.
More details on my training web site. Hope to see some of you there.
p.s. Gabor has been kind enough to advertise the courses on his newly revamped CPAN Forum site – so the least I can do is to repay the favour and recommend that you have a look at the site.