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.
I think I totally agree with your analysis. I usuall say the issues you see with Perl code in corporations are (mis)management issues.
It is also quite clear to me why management would want to blame something else, (in this case the language) instead of themselves. Who would want to admit failure?
I saw the above in many companies, but what struck me now, reading your post, if this only happened to Perl? Did the same not happen to other languages? Does it not happen to other languages now?
I mean both the badly written code, and then the blaming of the language instead of the people/process.
as far as i know, gabor, the same thing happens to .NET and JSP… so i can see why perl fits this list too.
Sadly, far too much management is incapable of admission of having made a mistake. Therefore, by mismanaging the Perl development years ago, they, management, made a mistake.
But they are incapable of admitting that mistake. And it is easy to “blame Perl” instead.
Ten years on, if they commit the same mistakes with Java and PHP, they will be blaming Java and PHP instead of themselves and moving to the next flash in the pan save us all tech.
Sadly, Perl is becoming less relevant as a “play mate” for newer technologies, too. I was at the All Your Base 2012 conference, in Oxford on Nov 23rd, and was twice struck by the absence of Perl from language binding lists — and one of those lists included Tcl!!!
It’s the second time I’ve witnessed a language pass over to the west, and it’s quite sad. The first was Rexx and ObjectRexx did nothing to revive the language. Sure, there are probably at least 3 people who will chime in with a pythonesque Rexx is not dead yet. And if we don’t start making Perl trendy again, that will also be its fate. Once we reach the tipping point, not even Perl6 will save it — if it even gets here before the next ice age.
God, I might have to start programming in PHP again… please, kill me now!
People in the Perl community are leaving for the new shiney. And (I’ll be controversial), I get the distinct impression that the “more beer for us” crowd are happy to see them go. Short-sight and stupid, and not helping. Oh, and there’s no shortage of ego and narcissism in what’s left of the community. Not pretty and quite repellent to new blood.
I was really happy to present at both of Richard Jelinek’s timely talks at LPW #9 this year. The problem with Perl is, in fact, us. Sure, we can blame managers, if we like, but we each need to shoulder the blame. Perhaps it’s time to stop asking what our language can do for us this week, and start reflecting on what we can do for our language.
How do we make Perl (and its community) more appealing to newbies? Or have we forgotten what was to be a newbie?
Let’s make Moose part of Perl core distribution along with Task::Kensho and make it standard programming practice. We won’t need Perl6 and become a competing modern scripting language.
There are also other issues with old apps – not only perl, but any kind of applications. Technical Debt, which accumulates over those 10+ years – it comes a time when it has to be paid. Managers and business people want features, they don’t care about refactorings, tdd and code quality – yet. They start to feel the burden of the technical debt when features are added much more slowly and with higher risks and negative side effects – that is when they decide it’s language’s fault and want a rewrite of the application. What they get is a payoff of the debt (if they manage to implement the rewriting), with debt starting to accumulate again, on the new technology stack.
Perl has become the “Cobol” of the Corporate World, and thus the “dislike” that Corporate America seems to have with it. To me, Perl started off back in the day when it was not object oriented, and just a powerful scripting language where you can do whatever you want. As the Object Oriented model took place in Perl, it’s not like everybody converted to doing OO Perl right away. At the same time, existing programs worked – why change them? In that sense, I agree with Tudor that there was no refactoring….it serves no purpose if it meets the business needs.
Eventually I think when time for enhancements came, and the next set of guys looked at the code — they were like –WTF.
I think you have to understand where the language came from to where it is today to appreciate the development, but a lot of people forget that. So they look at the existing code, don’t get it, and blame Perl/language for the issues.
@Iain: I see where you are coming from. So what are we lacking, technology-wise, in Perl these days? My wishlist for Perl is:
* Mature, documented and well supported Qt-bindings for GUI programming
* Perl on Android
* Put the best of Moose in Perl’s standard library so that we have an OO-system that you can use on any machine without having to go to CPAN first. This is important in the bioinformatics research community where we pass around scripts and programs but where many users are not able to use CPAN, i.e. stop assuming that all Perl users are Perl developers.
Java and PHP … umm. Why go to the trouble of an “update” or “rewrite” of systems if they are going to use outdated technologies?
Perl OTOH is and is going to continue be surprisingly useful in lots of places where people don’t care to look.
Well, my original blog post was from August 2008. Perhaps, those technologies didn’t seem quite so moribund back then.