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 http://cpan.org/.
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"? | [reply] |
|
"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 :)
| [reply] |
|
The only thing worse than having to respond to such misinformation about Perl is having to read it in the first place, barely refuted, right here on Perlmonks. It's right down there with you guys chastizing me for simply answering the propaganda campaign against Perl, right here on Perlmonks again. I felt compelled to because every point in the article contradicts my everyday experience with Perl, and it continues to be the 3rd result on Google for PHP Perl Comparison.
Lies of Society joined Perlmonks 2 days ago and after initially agreeing with me proceeded to make the following refuted assertions on this very thread, draw your own conclusions:
- mod_perl needs its own server
- old, inefficient CGI
- PHP will remain the best
- massive performance hit (in unlikely situations)
- Few people run PHP under CGI
- PHP Apache module ... does not have the same security considerations (for an ISP) that mod_perl does.
- mod_perl is too dangerous for web hosts to offer
- If it were safe and easy to install like mod_php
- PHP will remain the best choice
There is a campaign of lies against Perl, right here on Perlmonks, and we should oppose the misinformation with facts, otherwise it spreads and takes hold, as it already seems to have done in the minds of many web developers.
"This almost identical phrase seems to crop all over the place, with no attribution or supporting evidence as if it is absolutely the case with no possibility of mitigation. It would sound less like some third party cargo-FUD if some example or documentation were provided to be honest."-gellyfish
| [reply] |
Re: Why they choose to lie about PHP over Perl
by MonkOfAnotherSect (Sexton) on Aug 02, 2006 at 03:06 UTC
|
| [reply] |
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.)
| [reply] |
|
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.
| [reply] |
A reply falls below the community's threshold of quality. You may see it by logging in.
|
|
| [reply] |
A reply falls below the community's threshold of quality. You may see it by logging in.
|
|
| [reply] |
A reply falls below the community's threshold of quality. You may see it by logging in.
|
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. | [reply] |
|
|