Why Perl Lost It
martin.drashkov.com
martin.drashkov.com
I recall many cases at work when we had to use what's on the box and we were restricted by some funny policies to not to install/use any third-party (incl. open source) stuff. You may think it's weird, still it's quite popular in telco companies, banks and other monstrous borgs. Such organizations often run some quite old hardware/OSes and will run it for years, as they think it's cheaper to pay maintenance fees than to introduce a massive change (well often it's true). One indication you're using such box is lack of bash in favour of ksh or some so-called 'posix shell' (which usually isn't standarized at all, btw).
So, Perl saved our asses many times. The reason why some 'certified' stripped down Perl version was installed by the OS vendor was usually some ugly installer used by the vendor.
A little quiz: which commercial Unix do I have in mind? ;-)
[edit: typos]
- detrimental advocacy, people 'pushing' perl even when it clearly isn't the right solution just because it is their solution.
- tons of really ugly and unmaintainable perl code out there, where the only viable solution is to toss it and rewrite, which creates a natural opportunity to keep perl or drop it. Because the experience at that point is a negative one the decision to drop it already has one vote in favour.
- those perl programmers that you tend to meet on the job are not the examples that you'd want to follow when programming professionally, for some reason perl seems to attract people with an 'attitude', and I don't mean that in a positive way. I've yet to come across a PHP or Python programmer that wasn't aware of the shortcomings of their respective languages, but those perl programmers that I've met will have you believe that perl is gods own language.
Your second point has a lot of truth to it, though I wonder why it's not true of spaghetti PHP. A language that's incredibly easy to deploy and incredibly easy to begin and easiest to embed in HTML doesn't lend itself to creating huge amounts of well-structured, well-factored, easily maintained code.
I know it shouldn't matter but if every guy you run in to that tries to ram a certain language down your throat is basically viewing their code as a means to achieve job security then that doesn't really help.
As we're speaking I'm still busy disentangling some perl one of these guys wrote, it's the biggest mess you've ever seen. Perl certainly gives you a lot of rope to hang yourself with.
In perl you not only have to contend many times with ugly code, on top of that it might be written in a way that is completely alien from the way you would write it.
After seeing code which used files on disk because the author either didn't understand or trust arrays, I've come to the conclusion that code not designed and written and tested specifically with maintainability in mind will quickly become a big ball of mud, independent of language.
Perhaps certain languages offer syntactic tricks for obfuscation and cleverness in the small, but the mindset that prefers cleverness over maintainability will always be able to perpetuate great evils throughout a codebase.
There's tons of Unix back-end glue written in Perl, and I imagine tons still being written right now, but as a language for web-apps it just didn't get critical mass for some reason.
I think krf's comment might be part of the answer. I've had to do some mod_perl recently and the documentation is very patchy even now. I shudder to think what it might have been like 5 years ago.