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

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.