Why Learn Perl?

A couple of months ago I mentioned some public training courses that I’ll be running in London next month. The courses are being organised by FlossUK and since the courses have been announced the FlossUK crew have been running a marketing campaign to ensure that as many people as possible know about the courses. As part of that campaign they’ve run some sponsored tweets, so information about the courses will have been displayed to people who previously didn’t know about them (that is, after all, the point of marketing).

And, in a couple of cases, the tweet was shown to people who apparently weren’t that interested in the courses.

As you’ll see, both tweets are based on the idea that Perl training is pointless in 2016. Presumably because Perl has no place in the world of modern software development. This idea is, of course, wrong and I thought I’d take some time to explain why it is so wrong.

In order for training to be relevant, I think that two things need to be true. Firstly the training has to be in a technology that people use and secondly there needs to be an expectation that some people who use that technology aren’t as expert in as they would like to be (or as their managers would like them to be). Let’s look at those two propositions individually.

Do people still use Perl? Seems strange that I even have to dignify that question with a response. Of course people still use Perl. I’m a freelance programmer who specialises in Perl and I’m never short of people wanting me to work for them. I won’t deny that the pool of Perl-using companies has got smaller in the last ten years, but they are still out there. And they are still running successful businesses based on Perl.

So there’s no question that Perl satisfies the first of our two points. You just have to look at the size of the Perl groups on Facebook or LinkedIn to see that plenty of people are still using Perl. Or come along to a YAPC and see how many companies are desperate to employ Perl programmers.

I think it’s the second part of the question that is more interesting. Because I think that reveals what is really behind the negative attitude that some people have towards Perl. Are there people using Perl who don’t know all they need to know about it?

Think back to Perl’s heyday in the second half of the 1990s. A huge majority of dotcoms were using Perl to power their web sites. And because web technologies were so new, most of the Perl behind those sites was of a terrible standard. They were horrible monolithic CGI programs with hard-coded HTML within the Perl code (thereby making it almost impossible for designers to improve the look of the web site). When they talked to databases, they used raw SQL that was also hard-coded into the source. The CGI technology itself meant that as soon as your site became popular, your web server was spawning hundreds of Perl processes every minute and response times ballooned. So we switched to mod_perl which meant rewriting all of the code and in many cases the second version was even more unmaintainable than the first.

It’s not surprising that many people got a bad impression of Perl. But any technology that was being used back then had exactly the same problems. We were all learning on the job.

Many people turned their backs on Perl at that point. And, crucially, stopped caring what was going on in Perl development. And like British ex-pats who think the UK still works the way it did when they left in the 1960s, these people think the state of the art in Perl web development is those balls of mud they worked on fifteen or twenty years ago.

And it’s not like that at all. Perl has moved on. Perl has all of the tools that you’d expect to see in any modern programming language. Moose is as good as, if not better than, the OO support in any other language. DBIx::Class is as flexible an ORM as you’ll find anywhere. Plack and PSGI make writing web apps in Perl as easy as it is in any other language. Perl has always been the magpie language – it would be crazy to assume that it hasn’t stolen all the good ideas that have emerged in other languages over the last fifteen years. It has stolen those ideas and in many cases it has improved on them.

All of which brings us back to my second question. Are there people out there who need to learn more about Perl? Absolutely there are. The two people whose tweets I quoted above are good examples. They appear to have bought into the common misconception that Perl hasn’t changed since Perl 5 was released over twenty years ago.

That’s often what I find when I run these courses. There are people out there with ten or fifteen years of Perl experience who haven’t been exposed to all of the great Modern Perl tools that have been developed in the last ten years. They think they know Perl, but their eyes are opened after a couple of hours on the course. They go away with long lists of tools that they want to investigate further.

I’m not saying that everyone should use Perl. If you’re comfortable using other technologies to get your job done, then that’s fine, of course. But if you haven’t followed Perl development for over ten years, then please don’t assume that you know the current state of the language. And please try to resist making snarky comments about things that you know nothing about.

If, on the other hand, you are interesting in seeing how Perl has changed in recent years and getting an overview of the Modern Perl toolset, then we’d love to see you on the courses.

Culling My Modules

About a year ago, I dabbled briefly with Travis CI. I even gave a talk about my experiences. The plan was that I would start to use it for all of my code. But real life intervened and I never got round to getting any further with that project.

This weekend, I finally made some progress. I added a .travis.yml file to all of my Github repositories that hold CPAN modules. I even fed the details through to Coveralls so I get test coverage reports. From there it was a simple step to building a dashboard that monitors the health of all of my CPAN modules.

And it’s not a pretty picture. You’ll see a lot of grey boxes on that page, indicating that Travis couldn’t run the tests or, worse, red boxes showing that the tests failed for some reason.

Yesterday I made a few quick fixes to some of the modules (particularly in the WWW::Shorten namespace) and a couple more of them now work. But I want to work out how much effort it’s worth investing in the ones that are still failing. And, widening my scope a little, I’ve decided to take a close look at my CPAN modules and work out which ones are worth keeping and which ones I should just delete.

For example, twelve years ago I was really excited about the idea of AudioFile::Info. Most people were ripping music to MP3s, but I wasn’t following the crowd and was using Ogg Vorbis instead. AudioFile::Info and its friends was an attempt to make it easy to extract information from audio files no matter which format they were it. I suppose it was a kind of DBI for ID3 tags. But twelve years on, does anyone really care about that any more? I switched all of my music collection to MP3 years ago. If I recall correctly, the AudioFile::Info modules use a convoluted hand-crafted plugin system which never worked as well as it should. I could probably switch them to use some kind of plugin architecture from CPAN. But is it worth the effort?

Then there is Guardian::OpenPlatform::API – a Perl wrapper around the Guardian’s API. I believe they changed the API end-point several years ago so the module doesn’t even work. But the fact that I’ve had no complaints about that, probably indicates that no-one has ever used it.

It’s a similar story for Net::Backpack. To be honest, I have no idea whether or not it still works. Is Backpack still running? Ok, I’ve just checked and they’re no longer offering it to new customers. But if I’m not a paying customer is there any way I can test that it still works?

Finally, there is the WWW::Shorten family of modules. I released a module called WWW::MakeAShorterLink back in 2002, but it was Iain Truskett who realised that there should be a family of modules around the (at the time new) URL-shortening industry. I took over the module when Iain passed away and I’ve been maintaining it ever since. But it’s a real pain to maintain. The URL-shortening industry changes really quickly. For a long time, new services were popping up all of the time (and many of them closed down just as quickly). I haven’t been anywhere near quick enough at releasing versions that keep up with all the changes. I suspect that at least a couple of the current test failures are down to services that have closed down. I should probably investigate those over the next few days.

I don’t think WWW::Shorten is in any danger of going away (but I need to find a better way to keep abreast of changes in the industry) but the other modules I’ve mentioned here (AudioFile::Info::*, Guardian::OpenPlatform::API and Net::Backpack) are on borrowed time. If you’re using them and you’d like to see new versions of them in the future then let me know. If you’d like to take over maintenance, then that would be even better.

If I don’t hear from anyone (and I strongly suspect that I won’t) then I’ll be removing them from CPAN in a couple of months time.

Perl School Slides

In 2012 and 2013 I ran an experiment called Perl School. I ran cheap Perl training on a Saturday at Google Campus. I got some great reactions but I stopped it after almost a year because it wasn’t getting the traction that I hoped for and attendances were starting to drop.

That’s not the end of Perl School though. I have a couple of ideas that I’m considering and it will return at some point (in some form).

But I thought that the courses were good. And I realised earlier today that I hadn’t made some of the slides public. So I uploaded them to Slideshare and they are embedded below.

Let me know if you find them interesting or useful.

Perl in Banks

An email has flooded in:

I came across your presentation ‘Perl in the Enterprise’ and happen to have a burning concern closely related to one of the bullets ‘Banks see as a competitive advantage’.

I am consulting at a major bank in South Africa, and our team have been using Perl very productively to develop and maintain a customer loyalty rewards  application. This application has now suddenly caught the attention of the ‘Architecture Board’ who are questioning whether Perl (or any other scripting language) is appropriate for production use. A presentation will have to be made to this board to present a business case.

Whatever the basis for this concern, some quotable and referencable stories from other banks, such as the list included in your clients on the website, would be gold for us. I have searched extensively on the web and cannot find anything in this light which is also recent, as in the last 5 years. Other than Nvidia and Booking.com I can only find anecdotal, 2nd hand evidence of Perl use for medium-to-large applications in well-known corporates.

Do you by any chance have anything or any contacts in those banks that would be willing to respond to an email to confirm their use of Perl and perhaps repeat the competitive advantage claim?

The presentation he’s talking about is Perl in the Enterprise, which I gave at Linux World Expo in 2005. The particular line he’s interested in is on slide 6 where I say that banks see using Perl as a competitive advantage. I’m pretty sure that I was paraphrasing Phillip Moore of Morgan Stanley who had said something similar in a keynote at OSCON in about 2001.

Obviously I know that banks in the City of London still use Perl. But it’s been several years since I worked at one, so my personal experience is slightly out of date. What my correspondent needs is people who are currently working in banks who are happy to go public and say “we use Perl in our production systems”. It would be even more helpful if they could add “and here’s why…”.

Can anyone out there help?