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.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • 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 (e.g. web hosting accounts) and people who do (companies providing a single web service). Since mod_perl works the way it does, you aren't going to let 500 people using the same server to run all sorts of Apache::* modules and muck with each other's URL translations (for instance). On the other hand, if your team is the single user of the server, you have flexibility with the setup.

    Most of the arguments I see one way or the other assume that one technology fits everyone's needs, and it just isn't so.

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