Recent discussions on this site and at OSCON concern the apparent waning of mod_perl popularity. Some may lay the blame the for mod_perl's wilting at the door of the crappy tech market that has dominate these past four years. Others may cite the confusion caused by Apache's painful and prolonged switch from the 1.3 code base to the 2.x one. Inevitably someone will throw philosophic tomatoes at languages like java or python for stealing Perl mindshare. To this witch's brew of finger pointing, I'd like to add this observation:
mod_perl is dying because it solves the wrong problem.
If my Perl compadres aren't sent into paroxyms of rage, consider this line of reasoning. Perl became popular in the nineties as a tool to build web applications via the CGI. mod_perl and fastcgi appeared to turn down the suck knob on the poor performance of those early CGI apps (jeez, they were running on PIII machines; what sort of performance did we expected?) Whereas the fastcgi apache module was meant to make perl CGI "run faster", mod_perl embedded the perl interpreter into apache and created the Perl API to the request cycle of the web server that we all know and love. And as sort of an afterthought, mod_perl also provided a mostly CGI compatible module called Apache::Registry for those that wanted to port existing CGI stuff. But the expectation from the mod_perl camp was that everyone would get into writing apache modules using mod_perl.
This just ain't so.
Now, it's not that mod_perl suck (it doesn't) or that it's not useful in some situations (it is), is just that MOST PEOPLE ARE SIMPLY DOING CGI CRAP. That's right, stupid CGI + HTML is a kind of universal Microsoft Fundation Class that works for programmers of all lanuages. After all, most of us are hired to build a system to solve a business problem. And since writing software for a specific client platform is teh suck, HTTP/CGI is a better platform to program to. A quick look at freshmeat's projects by language reveals this:
Since freshmeat doesn't discriminate between web apps and non web apps, a little fudging is needed to get at my point. While many of the Perl, Python and Java apps listed freshmeat are web apps, almost all the PHP projects are web apps (there are some weirdos out there using CLI PHP). People like using PHP for web stuff and now I know why.
PHP is a terrible language. Perl has long suffered with the albatross of its highly syncretic origin and it's "organic design". However, PHP is a lot worse. It's a kitchen-sink language where crazy things like mysql routines and GD libraries are part of the core language. While objects were around in PHP 4, few PHP systems use OO style. To put a fine point on it, most of the PHP apps I've looked at are poorly written and a bear to debug.
And yet, PHP is frequently a better choice than Perl for web apps. Moreover, users are more likely to try out those PHP apps with their sexy screenshots than go through the hassle of installing a mod_perl app.
PHP, until recently, had no illusions about what sort of programs its users intented to write. It's syntax, "library management" and poor namespace control are all a product of it's problem domain. PHP are easy to write and painless to dispose of. PHP, along with thrice-damned VBScript/ASP, are as the best tools I've seen for rapid web prototyping.
mod_perl doesn't nothing directly to aid web app development. PHP, with its shotgun spray of built-in libraries to do everything from PDF generation to cybercash functions, 0wnz mod_perl.
If you've never installed a PHP app, do. It usually involves downloading an archive, unpacking it in a PHP-aware document root and pointing your browser to the appropriate URL. A web page will walk you through the rest of the setup. This procedure appears to be the rule, not the exception. In the past year, I've installed the following PHP apps: phpBBS, sugarCRM, Jinzora (mp3 streamer), Agatha ([poorly written] mp3 streamer) and SITR knowledge base.
Have you installed any mod_perl apps lately? RT (requires Mason, DBI)? Slash (requires Template Toolkit, DBI)? Wiki and Movable Type are two perl apps I can name that are most PHP-like in their installation. I'm not denigrating Perl, mod_perl or the Perl apps I've named. I'm pointing out that the installation of these apps is a barrier to entry for many people. Perl may be share some blame in this too. Perl's core set of bundled (or "built-in") modules is small compared to PHP, so apps that actually do something besides parsing log files require a trip to CPAN. Oh, you'll probably need to configure apache for mod_perl. And a Directory section for your mod_perl app. So, you'll need to restart apache.
ugh.
mod_perl isn't getting web developers because it isn't a web application framework. PHP is.
A postscript
In a vain attempt to forestall the stupid comments, here's a list of things I'm not saying:
What I am saying is use the right tool for the job. For web apps, PHP is frequently the better tool. mod_perl isn't tool, but a platform.
Now count to 10 and write the smart comments below.
-sam
I've got to agree with you, at least in terms of people using mod_perl for super-CGI rather than using mod_perl's strengths.
At Red Hat, we did a little of both. CGI-type scripts for short-term or one-off projects, and sometimes for prototypes. But most of redhat.com was running under Apache::ASP (that might have changed by now, though). The guys who cooked up the rhn.redhat.com site used their own ASP-like system, but it too was done as a location-handler, not a souped-up CGI library.
Unfortunately (and I willingly risk the wrath of any current co-worker who sees this), my every effort to develop applications using the full mod_perl platform at my current gig have met with resistance. They feel that the performance of Apache::Registry is comparable to a more integrated mod_perl location handler, and the latter requires server re-start when you update it, whereas Apache::Registry can better handle hot-swapping of code. After the first couple of times, I quit arguing.
Re:Agree to a certain extent...
perrin on 2004-09-07T19:06:03
There are real problems with Apache::Registry, principally with the magic required to turn your CGI into a module and what that does to your subroutines. Also, reloading things on the fly, while easy to add to handlers with Apache::Reload, will kill your shared memory, and should not be allowed on a production server.If you must use Apache::Registry, use something like CGI::Application so that you can avoid all of the subroutine traps that Registry causes.
Re:Agree to a certain extent...
rjray on 2004-09-08T01:31:38
You are familiar with the phrase, "preaching to the choir", right?
Re:Agree to a certain extent...
perrin on 2004-09-08T01:57:15
Just trying to give you some arguments to use on your co-workers.
Re:Different worlds
Aristotle on 2004-09-10T18:41:42
A lot of the issues regarding letting people share a single Apache and run their mod_perl apps on it anyway seem to be greatly reduced or even completely solved with the new Apache 2.x / mod_perl 2.0 design. Now if we ever get a mod_perl 2.0 release…
And you are right about the worlds. I never compare PHP and mod_perl; PHP is actually more like
Apache::ASP,Apache::Template,embPerl,Mason, or something like that.But we need to get more people aware of these modules, we need ISPs to offer them preinstalled along with a large selection of common modules, and we need the ISPs advertising this.
The ISPs probably need to run Apache 2.x and a stable release of mod_perl 2.0 before they can even consider doing that.
Another missing part of the puzzle, IMHO, is a way for ISPs to let their customers install modules their own homes via some sort of web interface. A large problem here would be interactive
Makefile.PLs, though. There might be a way to help this if EU::MM/M::B's prompting functions are used, but it's not an easy problem.
I think it is not the right thing to compare PHP with mod_perl.
At least from the point of view of the web application developer PHP can be compared to
This is a nice list though but I see a number of problems with it:
The first step towards this has already started I think: if I am not mistaken a number of distros are already coming with Apache2/mod_perl2. Now we might want to provide a bigger release of Perl with a lot more modules installed including those of the above frameworks so they will make it to the Linux/BSD distributions.
Re:Different levels ?
perrin on 2004-09-07T19:14:10
Exactly -- Apache::ASP makes PHP look hard, and Mason has really grabbed a large part of the "EZ web app" market as well. These are very similar to using PHP. The only real difficulty at this point is the install (on OSes that don't have good packages) and I think the approach taken in Krang handles that quite well.
all the joy of installing ImageMagick on Irix while getting a root canal without anesthetic.
Few people either care about or are skilled enough for fine web performance tuning. Who gives a fuck if PHP is slow and ugly, the apps are there, easy to install and most importantly, they work. Well, most of the time.
For years Perl people laughed when I thought that geriatric software for grandparents was an untapped market for perl since, if gran can install it, anyone can. Sadly, it was declared unmanly to have software install without an immense amount of pain with bonus points for each module sucked in off of CPAN. Reaping what you sow. It's not that mod_perl doesn't solve the right problem, it's just that people found somewhere else to get their dose of software pain. I compiled Bind the other day without any hassles whiched seemed like a near miracle since it has been a few years since I've had to wrestle with the makefile. Software that is a pain in the ass to install and to use, will lose. Look at how OSX is taking the linux desktop share rather than the windows share.
Oh...and who could forget the years of matching the perl release number to the mod_perl 1.x version which was never very obvious. And, getting mod_perl and mod_php to live together on a single apache server is nigh impossible. I had to choose and I chose mod_php.
Re:installing slash is like having
WebDragon on 2004-09-08T16:50:51
And, getting mod_perl and mod_php to live together on a single apache server is nigh impossible. I had to choose and I chose mod_php.Depending on the truth of this (may just be your particular experience here, and not everyones
.. anecdotal evidence...), this itself may be the single largest reason for the lack of adoption. If getting both functioning on the same server is rather a bear to accomplish, which one do you think they are more likely to use? Also there is a major amount of perception that mod_perl eats HUGE amounts of Apache memory compared to PHP. Depending on how true this is for large sites with many instances of httpd running to serve millions of clients, the issue needs to be addressed, written-form, publicly, so that it's obvious to even those who are mere decision makers how specious this argument is and to what degree.
Re:installing slash is like having
hfb on 2004-09-08T20:57:02
I wasn't the first to experience this even though Solaris isn't linux, but Jarkko has said the same thing so I feel reasonably certain that it's either an obvious triviality that we all missed or it really is a major PITA/impossibility. I spent 4 days with a square peg, a round hole and a hammer and all I got was a crashy crashy pile of shite that liked neither perl nor php. Installing mod_php by itself took 15 minutes and I had an app running a few minutes later without having to download half of CPAN. If people had to choose, they'd likely choose mod_php as the apps are there and you can run most perl code without mod_perl anyway. Case in point, Moveable Type 3.01 as it comes with php add-ons now and, unless you're going with the dynamic page generation option, mod_perl won't buy you that much performance.
Even with performance issues aside, mod_perl still loses since it's a bitch to debug if you get something really esoteric and and it has become a bit of a niche market for those who really need it. Everyone else who isn't masochistic use PHP or something else that might not be as endeared to us as perl, but they get the job done.
I don't think it's a job for advocacy since the boat left the dock already. With the future of P5/P6 uncertain/unclear, CPAN modules hoovering in half of the CPAN for one little innocent module they might want and the overall hassle factor of all of the above, the mainstream is not your market.
Re:installing slash is like having
jjohn on 2004-09-08T23:25:37
FWIW, I too had trouble running mod_perl/mod_php in the same apache process on RH9. Weird things didn't work (no, I don't have specifics). That made me a sad panda.Re:installing slash is like having
perrin on 2004-09-09T18:48:58
mod_perl is debugged in the same way as any other perl app: with logging or the debugger. There's no big trick to it. Also, the answer to your CPAN complaints is to bundle the dependencies with your distribution. PHP doesn't have this problem yet because it essentially has no code reuse.Re:installing slash is like having
hfb on 2004-09-09T19:13:27
I don't think you understood what I was saying. I said 'esoteric' bug which means something very unusual which can be very difficult and very frustrating to locate and solve. It's not for the average user.
My CPAN complaints come from my own as well as plenty of other people who share the pain of CPAN dependency chains. It was a big topic as last years CPAN meeting as it's a problem. Clearly, you don't understand what I'm talking about as it's not about bundling dependencies. When one module hoovers in 115 modules due to a web of dependencies, only the most hard-core cult fanatic is going to look at that and think that it's better than PHP.
Re:installing slash is like having
perrin on 2004-09-09T19:42:39
So an "esoteric" bug is easier to solve in PHP? Every language has tricky bugs of some kind.My interpretation of your dependency issues is that you're saying some modules use lots of other modules for small things, and maybe they don't need to. However, if you bundle all of the needed modules for your app with the app itself, there is no need to go to CPAN at all when installing it, so it's a moot point. See the Krang distributions for example. All needed modules are included.
Re:installing slash is like having
hfb on 2004-09-09T20:00:52
I figure when Doug McEchern had no idea how to fix a particular problem I found a while back, I thick it goes beyond tricky.
They aren't
/MY/ dependency issues, it's something I hear a lot of people bitch about and I'm not terribly fond of a module, literally, hoovering in 115 modules from CPAN, bundled or not. Especially when module versions and perl versions are moving targets wrt to those. Again, I don't think you fully understand the problem. Pain?
chromatic on 2004-09-09T23:03:06
Look at how OSX is taking the linux desktop share rather than the windows share.Linux overtakes Mac OS X on the desktop.
Re:Pain?
hfb on 2004-09-10T04:47:56
Hmm, without any data, that seems like an awfully convenient article for HP. I see way too many OS fanatics toting around iBooks and if the fanatics aren't running linux on their personal systems, who will? Either way, neither of them are putting too much of a ding in the windows market.Re:installing slash is like having
petdance on 2005-02-27T21:07:03
I've been running mod_perl and mod_php together on the same Apache for four years now, run big apps, and have only once had a problem where Perl & PHP were both trying to control the environment. Beyond that, it works great.In fact, we're able to use Apache notes to pass information between Perl and PHP processes with no problems at all.
For anyone else who cares, the process is roughly:
$ config Apache $ config, build and install mod_perl $ config, build and install mod_php $ config Apache (yes, again) $ build & install ApacheWorks beautifully for us.
mod_perl isn't getting web developers because it isn't a web application framework. PHP is.
Perl is like Lisp. We have the base language, on which we write the language in which we will write our program. I'm sure people who truly grok Lisp and all of Paul Graham's stuff will say Perl doesn't completely fulfill this, but I think it does partially. We create, at least, a hybrid language that consists of Perl + whatever modules we deem necessary.
Look at the way everyone writes their own templating system at some point: this is because the language is being used as a meta-language to write the language in which the final program will be written. It's analogous to the way Scheme and (IIUC) Lisp can have multiple object systems. The language you come up with in the end is Perl+CGI.pm or Perl+TT or Perl+DBI (who said I was talking about webapps here? Perl+DBI is itself a great language not suited for web developement, unless you want to take the improved version, Perl+DBI+CGI.pm.) or Perl+Time::Piece or whatever.
So in the end, the way to capture the PHP market, if this is desired, is not to try to sell Perl as the language to write webapps in, but some hybrid language Perl+WEBAPPLANG.pm. And the emphasis should be on the WEBAPPLANG.pm, not the Perl, and this beast (which might be more than just a module) should handle all of the things you mentioned with ease of installation, etc.
In the end I think I'm saying the same thing you're saying, just in a different way. But to me it makes no difference if Perl captures the PHP market or not. (I suspect it's no big deal to you, either.)
Re:Yep
jjohn on 2004-09-07T23:43:10
But to me it makes no difference if Perl captures the PHP market or not. (I suspect it's no big deal to you, either.)
You're right. I don't care all that much about Perl in the web space specifically, but I'd like to see Perl capture the general application development market. Perl replacing VB (via
.NET) is a beautiful dream. I doubt it will happen though. Still, Perl has been a huge influence on so many of the modern languages. It's humbling.
Re:Yep
ziggy on 2004-09-12T18:23:46
Yep. And that's why it's totally irrelevant Perl will or will not see widespread use for general application development. You can focus on the near horizon -- getting Perl used in the mainstream -- or you can focus on the far horizon -- getting the features and principles behind Perl adopted by the mainstream.Still, Perl has been a huge influence on so many of the modern languages. It's humbling.Ask yourself if the programs you write today are better than the programs you wrote five or ten years ago. Chances are they are much better, due to a whole constellation of factors -- garbage collection, platform independance, reusable components, better modules, better interfaces, bringing more skill to bear on the problem and so on. So, in that respect, Perl has already succeeded because the ideas it brings to the discussion about programming language design are being adopted in the mainstream (albeit through Java and C#.)
Ten years ago, we were still fighting the battle to use "interpreters", and not fully understanding the value of platform independence. Sun adopted those issues and brought them into the mainstream. But there are a lot of other ideas in Perl that have yet to reach mainstream acceptance, like huffman coding in interfaces, DWIMmery, generic objects, generic programming and unrestricted object models.
So, in some sense, Perl will capture the general application market space eventually. It probably will be a win-by-proxy with some language that descends from Perl, and not Perl itself. But the ideas will win nonetheless, when the values Perl brings to the table are more widely accepted by the mainstream.
mod_perl_lite?
plural on 2004-09-11T18:17:12
I was just having a talk with inkdroid about this the other night.
Basically, PHP is so popular because nearly every server has it and once it is there, you don't need access to the apache config to run it.
Sure the syntax, kitchen-sink mentality and general ugliness of PHP makes it offensive. But it is the microsoft of open source web app languages.
If we had something like mod_perl_lite, that would be easy to install AS A DSO into apache, then we would easily have a better platform. How many apps are really using the whole apache lifecycle? If you have one, then you can use mod_perl. If not, mod_perl_lite.
Now, i am a crappy C coder (awful, truly), so i don't know what would be involved. However, we already have the phases we need in mod_perl. How hard would it be to rip out all of the other crap that 1% of the population uses?Re:mod_perl_lite?
perrin on 2004-09-13T16:31:25
I would suggest just using SpeedyCGI (aka PersistentPerl).Re:Yep
memerman on 2004-09-17T20:57:09
This all reminds me of the deal with Gods who die off if nobody believes in them anymore. There's something to that. Perl can't afford to be too nonchalant about PHP else the masses will continue to flock to PHP in the vacuum of Perl ignorant-friendliness.PHP can grow organically, increasing its sphere of usefulness, just like Perl did. More and more Perl may become like Latin -- forgotten by the modern day unwashed and just a curious field of study for ivory tower eggheads. Not that there's anything *wrong* with that.
Now, I'm still gonna press ahead with learning Perl anyway, but y'all really oughta settle on what's gonna be your PHP equivalent/killer (I think I'm fast settling on Mason) and push the web hosts a little more (if you have at all) to have it at the ready. A leapfrog in web programmin innovation couldn't hurt either (it's a losin game just to "keep up").Re:Yep
jdavidb on 2004-09-17T21:24:04
But for those of us who use Perl for completely non-web related things, we could care less if Perl beats out other languages in the webapp space. The right tool should be used for the job. If PHP does the job better, great!
Re:Yep
Yoz on 2004-09-20T15:08:04
"we could care less if Perl beats out other languages in the webapp space"
IMHO, we should be caring a whole lot more. The main reason that Perl took such a big lead in the early days of webapp development was that the webapp problem domain fits so perfectly in Perl's target areas of expertise (rapid development and other dynamism, text munging, database interfaces, etc.)
Plus, there's Perl's mission statement: "Makes easy things easy and hard things possible." Webapp development is definitely on the easier side of things. The fact that a language as bad as PHP4 can stomp all over Perl in this regard should be a major cause for concern.
Were it real-time 3D rendering or mission-critical embedded systems, we'd have a better excuse. But webapp dev is an area in which Perl should be able to beat PHP with one arm missing. We shouldn't be saying, "Okay, so we're not particularly good at that domain, but it's not a problem." We should be saying, "Jeez, if we can't even get *that* right..."
PHP violates all reasonable engineering principles when designing a language, but its very crappiness is its genius -- when everything is a function, and all (most) of the functions are in the core language, then it's *really easy* to install -- and move -- web apps. I say move because I've written web apps in Perl and found them a bear to move from one web server to another, especially when moving from, say, a nice university server to a 10$/month web hosting one. With PHP, it's usually trivial -- download and upload. Set a few configs. Go.
Now, what I don't understand is the Java-wannabe character of PHP 5. Who's following *that* Moses?
