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.
If I understand you, you say that rewriting the old crufty Perl code now that you already understand the business can dramatically improve the maintainability of the code.
Of course using a modern framework with a (post)modern object oriented system will make it even more maintainable.
These attempts to rewrite a huge code base often fail even before they are started as management gets afraid of the size of the project but leaves your programmers longing for that modern language/framework.
So maybe the strategy should be to recommend rewriting it in Modern Perl with Moose and Catalyst. Likely that initiative will also fail (due to lack of time) but at least people will want to move to Moose and Catalyst.
To add to your point about there being a lot of bad Perl out there… this can explain the liking for Django, Ruby, etc, which I’ve also encountered.
Those new languages and frameworks don’t yet have that mass of stinky old legacy code. They will one day, and then those same people suggesting Ruby today will be suggesting the next new kid on the block!
Switching language is, in general, a false economy.
Oh, I agree completely. Rewriting from scratch is generally not a good approach for the reasons that you mention. But if you’re going to suggest a rewrite in Rails or Django then you should at least consider rewriting it in Catalyst as well.
The approach we’re trying to take on one of my current projects is to replace old and crufty pieces of code with new, shiny code that does (approximately) the same thing. We’re often running the old and new code alongside each other for some weeks until we’re sure that the new code is doing all the right things. Then we chop out the old code.
The danger with this approach is that sometimes that final stage gets forgotten. We’re trying to ensure that doesn’t happen.
I’ve heard several times that Django and Rails are really better than Catalyst. Friends of mine complained to me that they love Perl and would very much prefer to code in Perl if there were Django-style framework available alongside Catalyst.
Is Catalyst really on par? It’s too bad people rarely use both Catalyst and Django/Rails.
Total converts usually praise the tech they converted to even if they secretly regret.
Hi Alexei,
You are right, many people are blind to the limits of their favourite technology. The irony is that all these modern dynamic languages and frameworks have borrowed from each other over the years, leap-frogging along the way.
If someone said to me that Django or Rails was better than Catalyst I would reply asking why they think that’s the case. Perhaps Catalyst is missing a feature and a patch could be written.
I think Catalyst is quite different to Rails anyway, and cannot be compared directly as they focus on very different aspects of web app programming. Each has its strengths and weaknesses.