For years, many people have argued that one of PHP’s big successes is deployment. The language has little to recommend it for anything beyond simple database-backed HTML templating, but there’s little easier than dropping a couple of .php files in a directory through FTP.
While there are still millions of wonderful (and ultimately unproductive) flamewars about how mod_php is faster than vanilla CGI Perl and Ruby uses too much memory and FastCGI is unstable and shared-everything on a monster JVM is obviously more scalable, none of that will ever matter to most of the deployed PHP code in the world today.
A Perlbuzz commenter named Yudel made the deployment/colonization point very clearly:
I still think in Perl, but as an only occasional programmer, I seldom find it the best tool for the job. The Perl community failed to successfully colonize the new ecosystems of programmers who don’t have root access. Simply asserting that PHP is linguistically inferior won’t convince anyone who has had to argue with a web hosting company about the load MovableType was placing on their servers.
mod_perl is great for what it does, but it’s clear that mod_perl isn’t what hosting providers most wanted. A slim Perl distribution — including perhaps a new Apache httpd module which only embeds Perl — with a good templating module, the DBI, and perhaps an XML parsing module or two could have put Perl on more $4.95/month hosting plans. The corollary to that of course is an easily installable bundle of Pure Perl for an application.
Sure, that doesn’t cover everything. You probably can’t get RT orPlagger or Angerwhale in such a system, but it’s a start.
Ceding the very low end of a technology to an upstart is just one of the ways to let distruptive innovation eat your lunch.
One flaw in this argument is that approximately zero webhosts supported Ruby before the Rails lovefest. As well, the Rails deployment strategy went through several iterations. Here’s the interesting point which subverts my argument somewhat: Rails hosting suddenly became lucrative enough that several Ruby-friendly hosts appeared.
I haven’t yet figured that out.
Lots of webhosts "supported" ruby before the rails lovefest, but like perl today, it was unclear what "supporting" ruby would mean. One option was just to have the binary on the box and allow it as a CGI language.
What the lovefest did for Ruby was provide a specific application stack that hosts could work toward providing as a usable configuration. This isn't terribly surprising, as I remember many hosts going through the same thing with PHP back in the mid-90s.
I think your point about deployment is right on, but I also think the failure of this to coalesce is a consequence of Perl's TMTOWTDI culture. While the Rails deployment stack has gone through several iterations, there's generally been a community consensus about the best way to deploy it. Has there EVER been a community consensus about the best way to deploy a perl-based web application? I suspect not, because Perl web applications are a highly heterogeneous group.
@Davidcl, heterogeneity is a good point. Rails was the killer application for Ruby and Ruby hosting, so there was little danger in following the Rails core's advice on the single preferred deployment strategy.
I wonder why Python deployment isn't having more success... or maybe WSGI doesn't address that as well?
What effect will client-side processing have?
Maybe there will be a gradual migration to mostly static html and well defined data which on the server can be processed by dedicated plug-ins. NOSCRIPT clients might be supported by a virtual browser running on the server.
Whatever happens, if JS maintains it's dominance on the browser then I'm sure there will be a place for it on the server.
I think a slim perl distro (mod_plp?) with perl, xml::simple, template toolkit, and a bunch of database connectors is a --great-- idea.
<?plp
@planets = ( "earth", "mars");
[% FOREACH world IN planets %]
Hello, [% world %] < br />
[% END %]
?>
If we were going to go that far, then surely Catalyst and DBIx::Class should be included? That would be more in line with RoR.
Having said that, I think this is only one piece of the puzzle in the success of PHP, and to a lesser extent RoR. Another is the small amount of learning (and potentially coding) required to get a decent amount of the functionality that the average budget company or hobbyist wants. Another is just perception of how cool / new / sexy / easy a language is.
In the CGI days, Perl had deployement sorted (perl installed on just about every *nix box), for the time had a lot of functionality out of the box (how are you going to parse those query strings in C?), and IMO had a lot less of an image problem than it has now. Hence much success.
We can possibly solve the deployment issue. I don't think Catalyst or the other frameworks really solve the "easy" issue. They're powerful, but not really designed for the novice (which is a good thing for those of us who aren't novices). Image is a harder nut to crack. And that's not to mention all the stuff I probably haven't thought of. So not sure fixing deployment would necessary solve much.
I think the PHP feature to match is virtual host independence. If more than one customer uses a given apache child with mod_perl, then whether intentionally or by accident, they can influence each other's runtime code. Running a separate mod_perl per user isn't feasible because of the memory use.
Perhaps a mod_perl_lite (or mod_plp which has a certain ring to it), which just hooks into the content generation phase like PHP, has already loaded DBI/TT/XML::Simple and a few other things at the server admin's discretion, and then forks a child process to handle the request. Without having to exec after the fork it should be faster than CGI, and only the customer specific application code needs to be parsed and compiled. What's more different customers could not influence each others runtime code because each request is freshly forked.
That said its getting late in the day for Perl5. Perl6 though far from ready is in view, and mod_parrot will change the ballgame again. I don't know a lot about the latter, and how it compares with mod_php.
i agree that is simpler to write hello world in php than using mod_perl
<?php
echo "goodbye world";
?>
Than installing modperl and configure-ing the app (I'm working as sys admin)
maybe simple_mod_perl should interpret all *.pl and after that an use an templating system
<?perl
say "goodbye world";
?>
modrails is changing that in the Rails world... it sweeps away all the mongrel/monit/fcgi cruft. Just modrails and a virtual host, that's all you need; great stuff!
I hacked up a proof of concept for just such a thing for exactly the reason of simplicity and non-root-liness (see my link to modperlite.org), but Perl itself needs to have hooks added for: resource control, script run time, lightweight "die" and "exit" handling, and interpreter state flushing. I've just got the very basic basics done, which are to embed the Perl interpreter into an Apache module that runs anything with a ".pl" extension in-process.