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 ]

gnat (29)

gnat
  (email not shown publicly)

Journal of gnat (29)

Thursday September 09, 2004
11:31 AM

mod_perl and PHP

[ #20798 ]
PREACH IT, BROTHER! jjohn += 10

--Nat


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.

mod_perl and PHP 3 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • The only arguments I was able to draw from that journal are that Perl apps are difficult to install compared to PHP ones (a solvable problem) and that people prefer to write CGI-style apps rather than use the mod_perl API directly. It's not clear why this is a problem, since mod_perl supports a CGI interface. More to the point, those people should probably use Mason or Apache::ASP. So, the real strengths of PHP seem to be lack of code reuse (which makes installation easier) and lack of choices (no need t
    • Worse is better!

      -adam
    • The main problem with mod_perl, IMHO, is that if you're not careful, you'll fall over values left over from a previous run. Mod_perl scripts don't act like indepedendent scripts.

      That, and that ugly "variables will not stay shared" behaviour thing.

Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.