This is a reprint of an old blog post.
A few years ago I was writing blog posts (semi-)regularly for O’Reilly. This is the one that probably got the most feedback. I’m reprinting it now because a) it’s pretty hard to find on the O’Reilly site and b) it’s relevant to a couple of conversations that I’ve had over the last few days.
Last week I was in Copenhagen for YAPC::Europe. One of the announcements at the conference was the location of next yearโs conference which will be in Lisbon. The theme of next yearโs conference will be โCorporate Perlโ. And that (along with a couple of conversations last night) got me thinking about a talk that Iโll submit to next yearโs conference which might well be entitled โWhy Corporates Hate Perlโ.
Itโs not true, of course. There are a still large number of large companies who love Perl. I could probably work through to my retirement enhancing and extending systems that are written in Perl at many of the big banks in the City of London. There are, however, also many companies who are moving away from Perl for a number of reasons. Hereโs one of the reasons that will be included in my talk.
I was talking to people from one such company last night. The Powers That Be at this company have announced that Perl is no longer their language of choice for web systems and that over time (probably a lot of time) systems will be rewritten in a combination of Java and PHP. Management have started to refer to Perl-based systems as โlegacyโ and to generally disparage it. This attitude has seeped through to non-technical business users who have started to worry if developers mention a system that is written in Perl. Business users, of course, donโt want nasty old, broken Perl code. They want the shiny new technologies.
And so, in a matter of months, the technical managers at this company have created a business environment where Perl is seen as the cause of most of the problems with the current systems. Itโs an impressive piece of social engineering.
Itโs also, of course, completely unfair. I donโt deny at all that this company (like many others) has a large amount of badly written and hard to maintain Perl code. But I maintain that thisย isn’tย directly due to the code being written in Perl. Itโs because the Perl code has developed piecemeal over the last ten or so years in an environment where there was no design authority which encouraged developers to think beyond getting their immediate task done. Many of these systems date back to this companyโs first steps onto the internet and were made by separate departments who had no interaction with each other. Itโs not really a surprise that the systems donโt interact well and a lot of the code is hard to maintain.
There are, on the other hand, a number of newer systems which are also written in Perl which follow current best practices in Perl development and are far easier to to maintain and enhance – as easy, I would contend, as anything written in the new approved languages.
Itโs certainly true that this company has a large number of systems that need to be rewritten over the next few years. But throwing away all of the companyโs accumulated Perl expertise and moving to new languages seems to be a step too far. Management are blaming Perl for the problems when really they should be blaming the management and design procedures that were in place (or, more likely,ย weren’tย in place) when the code was originally written.
Many organisations are in the same situation, with large amounts of unwieldy Perl code. Ten or twelve years ago everyone was writing web systems in Perl and we were all making mistakes. We all have to deal with those mistakes butย we’veย hopefully, learned from them and can rewrite our systems to take account of everything thatย we’veย learned in the last ten years.
Itโs too late for the companyย I’veย been talking about in this article. The anti-Perl social engineering has probably insinuated itself too deeply into the culture. Itโs unlikely that Perlโs reputation can be rescued.
But if you have similar problems in your own company, then please try to ensure that blame is apportioned correctly and that you donโt use Perl as a scapegoat.
A couple of updates to the post. I did propose the talk to the next YAPC, but the proposal wasn’t accepted. And the company I talk about in the article is still employing a lot of Perl programmers – four years after this post was written.
Leave a Reply to satracCancel reply