Beefy Boxes and Bandwidth Generously Provided by pair Networks
Don't ask to ask, just ask

Why they choose to lie about PHP over Perl

by Anonymous Monk
on Aug 01, 2006 at 02:31 UTC ( #564901=perlmeditation: print w/replies, xml ) Need Help??

Thanks to explorer for posting this concise list of common delusions about Perl so frequently repeated by certain members of the PHP "community". The hidden agenda of vendetta against a competitor is transparent and we shouldn't let them get away with it. Lies of this magnitude do real damage to Perl, and they're being actively promoted by people affiliated with a greedy for-profit corporation, think about it.

PHP code gets embedded into HTML pages, unlike Perl.

This is ABSURD. Embedding Perl in HTML is TRIVIAL with mod_perl, if that's what you really want to do, and MANY other more powerful techniques exist. From Perl Server Side Includes:

"Another feature of mod_perl is that it integrates with the Apache mod_include server-side include system. Provided that mod_perl was built with the PERL_SSI option (or with the *recommended* setting of EVERYTHING=1), the Perl API adds a new #perl element to the standard mod_include server-side include system, allowing server-side includes to call Perl subroutines directly.

The syntax for calling Perl from SSI documents looks like this:

<!--#perl sub="subroutine" args="arguments"-->
This example calls a Perl subroutine that it creates on the fly. It looks like this:
<!--#perl arg="Hello" arg="World" sub="sub { my($r, @args) = @_; print qq(@args); }" -->
  • Note: "This feature works only when mod_perl is not built as a DSO (i.e., when it's built statically)."

    PHP is built from the ground-up with database functionality built in, particularly MySQL functionality. Perl is not.

    Perl allows YOU to decide what database to use, if any, and PHP seems to be following Perl, as usual, towards a more modular approach:

    PHP 101 (part 9): MySQL support in PHP 5.0 is not as simple as it used to be. Instead of supporting MySQL out of the box, PHP now requires you to make all kinds of decisions about versions and libraries before allowing you to hook your scripts up to a MySQL database.

    PHP is secure. Perl scripts tend to have more security holes.

    WRONG AGAIN. Not only is PHP itself well-known to be less secure than Perl, as john_oshea demonstrates with his link comparison, evidence suggests PHP applications are the LEAST secure LAMP choice, while those written in Perl have the BEST code quality.

    Coverity Study Ranks LAMP Code Quality:

    "The pillar of most open source applications is the ubiquitous LAMP -- Linux, Apache, MySQL, and Perl/PHP/Python stack. According to results of a Coverity study, the LAMP stack has fewer code defects than a baseline of 32 open source software projects."

    "Of the LAMP stack, Perl had the best defect density well passed standard deviation and better than the average, Chelf said.

    Perl had a defect density of only 0.186. In comparison Python had a defect density of 0.372 and PHP was actually above both the baseline and LAMP averages at 0.474."

    PHP is easy to learn in comparison to Perl.

    Perl is actually EASIER to learn than PHP because things like function names and their return values are MUCH more consistent, to name just one of many reasons.

    PHP takes less "overhead" than Perl, meaning that PHP scripts will run faster than CGI scripts written in Perl

    mod_perl is actually FASTER than mod_php.

    PHP code tends to be more consistent and modular than Perl.

    Let's be honest, to the untrained eye Perl and PHP and look identical, and this author is obviously completely ignorant that the best collection of modules for any language in the world exists for Perl at

  • Replies are listed 'Best First'.
    Re: Why they choose to lie about PHP over Perl
    by johnnywang (Priest) on Aug 01, 2006 at 05:31 UTC
      This kind of arguments, for both sides of any language, are really getting boring. Can we stop these and just get some things done? or as Rodney King used to ask: "Can we all get along"?
        "hear hear", and ++ to you

        I deliberately stay out of these arguments, because generally I find them completely pointless.

        People will use what they use, to get their job done - and life goes on.

        Update: s/here/hear/g; Thank you very much radiantmatrix. That's one of the things I love most about PM - even an insignificant post like this can lead you to learn something new :)

    Re: Why they choose to lie about PHP over Perl
    by MonkOfAnotherSect (Sexton) on Aug 02, 2006 at 03:06 UTC
    Re: Why they choose to lie about PHP over Perl
    by Lies of Society (Initiate) on Aug 01, 2006 at 08:59 UTC

      "This is ABSURD. Embedding Perl in HTML is TRIVIAL with mod_perl, if that's what you really want to do, and MANY other more powerful techniques exist. From Perl Server Side Includes:"

      That's the problem: you need mod_perl for any of that fancy stuff and mod_perl needs its own server. Otherwise you're stuck with old, inefficient CGI. So long as that's the case, PHP will remain the best choice for small-medium sites. (I agree with your other points, though.)

        Not true. You don't need mod_perl to embed Perl in HTML. You can run Mason or several other tools for this under CGI. You can also run under FastCGI, which is what people sometimes do with PHP these days.

          No, you can't use Mason or several other tools under CGI, not unless you're willing to accept a massive performance hit on top of the performance hit of CGI's constant process spawning. As for FastCGI, last time I looked into it, it didn't scale nearly as well as mod_perl or mod_php and few web hosts offer it.

        In order to use PHP you have to have PHP installed too...that just seems like a weird argument. If mod_perl was installed as often as mod_php on web hosts then there wouldn't be as big a difference. Hopefully someone, somewhere is working on an easier to use/install mod_perl ;)

        Eric Hodges

          The argument is that to use mod_perl you need your own web server. mod_perl is too dangerous for web hosts to offer because it allows you to shutdown, restart and reconfigure Apache from a Perl script. That's why so few web hosts offer it. If it were safe and easy to install like mod_php, then it would probably be nearly as ubiquitous. Until Perl offers something like that, PHP will remain the best choice for small-medium sites.

        Here's an example of an ISP restricting PHP to CGI on shared hosts, quoted from PHP Safe Mode, problems and work-arounds:
        For complex security reasons, (mt) Media Temple's various hosting solutions operate PHP in what is known as "safe mode". This is necessary for the safe running of PHP enabled web sites in a shared server environment...

        Safe mode imposes several limitations that might be causing your scripts to not function as anticipated...

        Please note that many "ready-made" PHP scripts, such as Gallery or ***NUKE, use the system () function to copy files...

        One known workaround on the (ss) Shared Server systems is to use an .htaccess file to force your php scripts to run in "CGI Mode"...

        Customers requiring a hosting solution without the restrictions of PHP safe mode should consider (mt) Media Temple's other family of hosting products such as the (as) Appliance-Server, or (ds) Dedicated-Server.

        "Most ISPs are offering PHP through either CGI or FastCGI (mod_php has all the same security issues mod_perl does)."-perrin

          Can you even read? It says they use safe mode. Safe mode isn't CGI. Safe mode is designed for shared hosting environments that use the PHP Apache module. It places restrictions on file/directory creation and execution of external programs. They merely suggest running your scripts under CGI as a work around if safe mode causes problems for you.

    Re: Why they choose to lie about PHP over Perl
    by tphyahoo (Vicar) on Aug 03, 2006 at 10:36 UTC
      I'll weigh in.

      Problem is, php is acutally a *framework* for building web apps. primitive, but a framework, and that's what people want.

      Frameworks exist for perl as well, but they are hell to install, *especially* on shared servers.

      Case in point

      installing catalyst on Dreamhost -- a quest in progress

      I still haven't got the catalyst install on my dreamhost server to the ease of use that would encourage casual newbies to try it out. Same goes for every perl framework -- and frameworks are where the power is.

      I'd concentrate on getting *frameworks* easier to install on shared servers, to encourage newbies to pick things up with perl, and I would consider the *real* competition to be ruby/ror and not php.

      Anybody wants to help me on the catalyst thing, give me a private msg, I asked about on the list but didn't get much of a response.

    Log In?

    What's my password?
    Create A New User
    Node Status?
    node history
    Node Type: perlmeditation [id://564901]
    Approved by blokhead
    and all is quiet...

    How do I use this? | Other CB clients
    Other Users?
    Others meditating upon the Monastery: (5)
    As of 2018-06-20 23:33 GMT
    Find Nodes?
      Voting Booth?
      Should cpanminus be part of the standard Perl release?

      Results (117 votes). Check out past polls.