There was a time when Perl, operating through CGI, ruled the web as king of dynamic sites. Things have changed quite a bit since then. Perl has grown to become a much stronger language, but it has also fallen from favor and lingers in the broader software development community's eye primarily as a whipping boy to be brought out only as a source of horror.

How did this happen?

We do have a legacy of poorly-structured, obfuscated, insecure Perl 4 code to overcome, which doesn't help matters any. This is being addressed by the "Modern Perl" and "Enlightened Perl" camps, including the Enlightened Perl Iron Man Challenge which I am participating in, and their efforts to show that it's not only possible, but easy to write well-structured, maintainable, elegant code in Perl 5. CPAN provides us a wealth of development frameworks, reusable objects, and everything else that today's developers expect to find in a language, and Modern/Enlightened Perl encourage heavy use of them.

Unfortunately, this is solving the wrong problem.

Despite the near-ritualized expressions of disgust that so often come about in conjunction with any mention of Perl programming, I do not believe that the cruftiness of older Perl code was the primary cause of the language's fall from grace. As evidence, I cite its primary replacement, which still dominates web-based applications today: PHP. Very, very few of the standard complaints about how awful Perl (supposedly) is are not also true of PHP, plus PHP has its own layers of issues, yet it remains widely used and is not reviled nearly so widely nor so vocally as Perl.

If it wasn't cleaner syntax/improved readability/better object-orientation that allowed PHP to usurp Perl, then what was it?

Ease of use for the casual user. For someone who just set up an account at Random WebHosts, Inc. and wants to make himself a blog. Note also that, in this case, "ease of use" mostly means "ease of installation". This is why Modern/Enlightened Perl is unlikely to succeed at getting Perl to be used more widely - and may even prove counterproductive.

Within the Modern/Enlightened Perl sphere, there has been a recent discussion of long dependency chains and whether they're a good thing or a bad thing. dagolden has argued that dependency chains are fine, so long all the pieces work correctly, in his post Dependencies don’t matter — but stability does. Dave Rolsky has taken an even stronger position, proclaiming that Dependencies Rule (and that anyone who disagrees with him is a "whiner").

They're both completely right, within the context of Perl developers. If you are writing the code yourself and deploying it on machines that you or your company/client control completely, then it's great to be able to pull in a ton of already-written, well-tested code that you don't have to create or debug yourself. Even if you don't have full control of the server, you can still install CPAN modules as a non-root user, at least so long as you have access to a shell (and a compiler if any of the modules use XS).

But what about that casual user? He doesn't control the server. If he has shell access, there's a good chance he may not know it. Even if he does, he doesn't know how to do a CPAN install, regardless of whether he's root or not.

If that user is presented with the options of "Unzip the WordPress archive into your web root directory, create a database, load up this page to configure it, and you're done!" or "Cross your fingers and hope your web host already has these 57 dependencies installed. If not, install them all on your local machine, then make these configuration changes and ftp them to your web host, which should work unless one or more of them uses XS, in which case you'll also need to get command-line access to a machine with a C compiler capable of building binaries for your host's OS and CPU architecture. Then you can start on actually installing this application...", then which one is he going to pick?

In the vast majority of cases, it doesn't matter how much better, cleaner, or shinier the Catalyst/Moose/DBIx::Class/CPAN-kitchen-sink-based Perl application might be, he's going to go with the PHP option instead because he can install it quickly and easily with a good level of confidence that it will just work. Even if his web host already has all of the dependencies available, he's more likely to know up front that PHP and MySQL are installed than that Perl and MySQL and Catalyst and Moose and... are. If he doesn't know, he's probably going to check the short list first and not bother digging into the long list when he sees that everything on the short one is there.

Modern/Enlightened Perl and extensive code reuse (with the resulting dependency chains) are great for producing solid code targeted to Perl developers and enthusiasts or their employers/clients. But the goal of returning Perl to a position of being widely used and respected by those outside of the Perl community requires a focus on ease of installation and use, which means self-contained code with a minimum of dependencies.