Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

jjohn (22)

jjohn
  (email not shown publicly)
http://taskboy.com/
AOL IM: taskboy3000 (Add Buddy, Send Message)
Perl hack/Linux buff/OSS junkie.

Journal of jjohn (22)

Monday September 06, 2004
08:20 PM

why PHP 0wnz mod_perl

[ #20761 ]

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:

  • Perl: 3146
  • PHP: 2682
  • Python: 1566
  • Java: 3301
  • Lisp: 44 (included for entertainment purposes only)

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:

  • Perl sucks
  • PHP rulz
  • mod_perl is garbage
  • PHP is delightful
  • PHP's design choices are perfect
  • Perl should be exactly like PHP
  • Don't code Perl
  • Don't write Perl web apps
  • Only write PHP web apps
  • You can't write good web apps for mod_perl

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.


List all Journal entries
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

why PHP 0wnz mod_perl 25 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Solving the mod_perl application installation problem wasn't easy, but I think I did it with Krang [sf.net]. You can download a binary package and have a working system up and running in just a few minutes. Everything but the database (MySQL) and Perl are included.

    -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

    --

    --rjray

    • 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.

  • Joel on Software explains why, I think, in the "Five Worlds" [joelonsoftware.com] essay.

    Basically, Joel says that there are five major types of software, and each of them have different requirements and are for different audiences. Read the essay to see what that means.

    I think PHP and mod_perl live in different worlds, and so do the developers who use either one. And, because of that, I think that trying to make either one take over both worlds is futile.

    Here's the two worlds I see: people who don't control their server (
  • mod_perl isn't getting web developers because it isn't a web application framework. PHP is.

    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

    • Apache::ASP
    • Apache::PSP
    • Mason
    • Embperl
    • CGI scripts

    just to name a few. But even that is not totally correct as PHP provides database access, capability to send e-mail and whatnot while the above frameworks "only" provide the web front end part.

    This is a nice list

    --
    • 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 ha

    • 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 mo

      • 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. I

        • 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.
        • 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.

          • 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 1

            • 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 [sf.net] for example. All needed modules are included.

              • 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.

    • Look at how OSX is taking the linux desktop share rather than the windows share.

      Linux overtakes Mac OS X on the desktop [computerworld.com].

      • 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.
    • 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, a

      --

      --
      xoa

  • I agree that PHP applications install more easily than mod_perl applications, in general. Using a decent packaging system makes installing popular mod_perl applications much easier.

    I can easily install RT, Maypole, Bricolage, Mason, TT, etc.

    Sure, not everyone understands the value of a good packaging system, or uses an OS that doesn't offer one, but they deserve recognition for helping solve the installation at least for popular mod_perl applications.
  • I think you pretty much captured it along with the comment above about who owns the server.

  • 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 sys

    --
    J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers

    • 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.

      • Still, Perl has been a huge influence on so many of the modern languages. It's humbling.

        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.

        Ask yourself if the programs you write today are better than the programs you wrote five or ten years ag

      • 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!

        --
        J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.