One thing people rarely talk about is key to why after well over 10 years, millions upon millions upon millions of pages served and more lines of code then a room full of monkeys could count I stopped building new apps in perl. Well, mainly they don’t talk about it because I am no one. But if I WAS SOMEONE they would ask ‘Why?’. I’ll tell you why.
‘Deployability‘.
WHAT? What is this “deployability” you speak of? Well, it is the key to a stable and reproducible system.
CPAN is great, mod_perl (and fastcgi) are , well, fast, but deploying the Perl stack is a nightmare of dependencies, OS incompatibilities and environmental hooks that require being set ‘just so’ for the entire shebang to function.
When I need to deploy across a mixed network of dozens app servers as well as get my app onto 20 developers dev tree’s, multiple staging, production and dev systems and keep everything moving smoothly perl does.. not.. help.
This is where a language like Java shines. The same app will run on windows, linux, mac os x and is almost entirely independent of its ‘environment’ outside the prerequisite (universal) java env vars. All libs are stored local to the app, it mostly ignores the OS level environment and the same libs run everywhere exactly the same (take that DBD::Oracle and your dumb client dependencies..) Yes, there is a big overhead of learning to be done, particularly coming from perl, but once your past that its pretty darn slick.
I’ve gotten around this ‘deployability’ issue with perl by creating one click/script build/deploy systems that pull CPAN modules from the project source control, build perl, apache and mod_perl from source controlled tarballs and strictly enforcing ‘The Environment Is Evil, Do Not Depend On It’ coding standards. This works really well but requires a lot of discipline and a TON of up-front work.
But what About CPAN/Debian/MyFavoriteDistro?!?!
And before you go touting CPAN as ‘all that and a stack of bricks’ let me highlight just a few incidents of lameness I have seen in a decade of perling..
- CGI.pm treats ‘undef’ differently in different versions in different circumstances. Yea, that hurts.
- The DBI Postgres drivers dramatically changed the internal SQL statement behavior and then DEFAULTED TO THE NEW BEHAVIOUR. (Can you say ‘Hello broken apps’? We sure did..)
- Storable changed its storage format which means different machines running different versions would corrupt data. Woops, thank goodness for a real multi-server test environment..
- on and on and on. This is just in the last 2 years or so.
CPAN was/is awesome but depending on it, or any uncontrolled release process, is stupid. Grab your modules, test them and then source control them. Don’t treat your linux distro like a source control system, its not, the Debian or Ubuntu guys don’t care about you. Case in point, deprecating Apache 1.3.x entirely and forcing mod-perl users to move to Apache 2.2. Sounds fine but when you have a 100,00+ lines of 10 year old perl code that have been grafted into mod_perl being forced to switch to mod_perl 2 is not happy or trivial. Sure, we can compile 1.3.x ourselves but that really defeats the point of a package management system..
Oh, and about those bajillion CPAN modules. It might be important to note
A) How many of these are just Base Features in most other languages.
B) The fact that most perl modules are factored down to very granular levels (Good Engineering Practice), increasing the module count.
I’ve found that a good 85-90% of my lib needs are covered in the core Java language + the apache-commons packages. Everything else is an edge case where either perl or java or ruby or whatever generally is going to have some sort of library that is half-tested but available and better then nothing..
Quantity is not Quality and Quantity is not a measurement of the level of support a language is getting.
Hold your nose, set your browser to ‘private browsing’ so no one knows you looked and check out the apache-commons and base java api’s, I bet you’ll find that it would provide you with a big slice of your CPAN requirements…
http://commons.apache.org/
I do love CPAN but a bajillion modules doesn’t mean anything really outside of bragging rights. And yes, there is some awesome cool Obscure Stuff in CPAN but it is dwindling as perl phases out and the next generation of languages start to arrive. Tried using some of that stuff from CPAN lately? Egads, most of it hasn’t been updated in 3+ years.
If you are building large apps in perl and are honest with yourself you should be nodding in agreement before telling me I am an idiot for using Java and not your favorite unstructured/untyped scripting language.
Summary
‘Deployability’, if you ever build a big system this will become one of the most important problems you face. If you don’t think this is true then you A) are not building large systems or B) don’t work in a multi-developer environment or C) have a manager/sysadmin/fellow coder that really loves you and shelters you from the harsh world of deploying apps outside of your dev tree.
If you don’t have a dev tree you aren’t building a real app. Sorry, its true. None of this applies to you, you can now switch back to vi and continue coding. Thanks for reading this far, be sure to USR1 your development environment when making changes so that your live users (mostly) don’t notice.
So, when you pick your next language think about its deployment mode and if its paradigm will really support what you need to get done. In the end I ended up moving to Java for most everything. Robust library support, 100% reproducibility in almost any environment, suitable performance characteristics and the best userland tools going. Yes vi is cool, I get it, you rock with vi. Congrats, I find it difficult to navigate a huge codebase in vi and the lack of tools support is insane, but that’s me, I am the Tools Using sort of monkey. Just about every single one of my developers is a vi bigot so I am used to being stared at.
That said, I am currently running a really rather very large perl codebase with tons of traffic and it is an absolute blast sometimes.


Number of uploads (mostly just new versions) to CPAN is raising exponentially lately, so CPAN is updating rapidly. Some of the modules that do not update just do not need updates, some are deprecated.
As for deployments, good modules are local::lib and PAR.
I have not found real evidence for the claims of exponential growth but there is no arguing that CPAN continues to be a vibrant community. My overall point RE: CPAN was more about ‘growing in a useful way’ and ‘duplication of core features that live in other languages’. For example. the apache commons project is ~30 modules that contain a vast amount of functionality that would probably take many more CPAN packages to duplicate. In this light I think its very true that quantity is not a good indication of usefulness.
CPAN is very useful though. I use it often, but CPAN is not great for deployability (in general). Projects like PAR (awesome btw, thanks for the pointer) directly points to CPANs deployability issue.
Some interesting links on perl, CPAN and growth
Interesting graph that shows where perl work is clustering from a subject perspective
http://lumberjaph.net/blog/index.php/2009/06/12/shape-of-cpan/
Another interesting Graph that shows the movement of CPAN
http://lumberjaph.net/blog/index.php/2009/06/12/shape-of-cpan/
A note by Bunce discussing the overall growth of Open Source and how Perl follows the trend
http://perlbuzz.com/2008/03/tim-bunce-debunks-perl-myths.html
Perl is a fine language, I use it daily. I just don’t think its super deployable. That said, there is a huge tradeoff for deployability that I did not mention which is configurability.
For example, in my Java projects I use maven. I type ‘mvn package’, I get war file, I drop it in a directory on my app server and its live almost immediately with all dependencies localized. Thats great for deployability but man it HURT to get the configuration right in that context.
So to be fair, in many cases, the burden may be somewhat the same. I wrote this awhile back when I was particularly pissed about how a CPAN dependency screwed up a production system.