in reply to Re: perl vs. php
in thread perl vs. php

Caveat: I'm a PHP developer for Zend, and a lead author on several PHP open source projects. I'm also a perl developer. I use both languages regularly, though PHP more often than perl in recent years, due to the nature of my places of employment. I'm going to refute some points about PHP below, based on my experience with the language.

From what I understand, similar things are available in PHP as well

Yes, they are, including a PHP port of Cgiapp (that's a shameless plug), the Smarty templating language, the Savant templating language, and many others. In fact, regarding templating languages, PHP, in Rasmus Lerdorf's own words, was meant to be a templating language (Savant takes that approach, actually).

There are number of frameworks similar in nature to Catalyst and CGI::Application out there for PHP as well -- Solar, Symfony, Cerebral Cortex, and Seagull, to name a few.

PHP does not have the breadth of coverage that CPAN does

This is debatable. The difference between PHP and Perl is that Perl has CPAN as a common repository. PHP has PEAR, but PEAR doesn't have quite the extensive library CPAN does. However, it does have some pretty rigid guidelines for contribution, one of which is that it (in recent years) allows duplication of packages only when the approach significantly differs, leading to what is hoped as 'best-in-breed' packages. Additionally, there are a number of other sites that are aggregating packages out there, including phpclasses. I'm betting that the number of PHP libraries out there is similar to perl's -- if in fact it hasn't exceeded perl's at this point.

However, a key difference to note is that PHP is primarily targeted at web development. So the breadth and scope of packages for PHP is going to be significantly different than that for Perl.

The main reason I avoid PHP though is the myriad security problems, lack of a consistent database interface, the habit of having a million functions in the main namespace with no particular naming convention or consistency, and the rather strange nature of PHP data types which allow you to mix hashes and ordered lists in a single structure.

To this I reply:

As for the OP, what it comes down to is: does it make good business sense for you to learn PHP at this time? If the project has a narrow deadline, and it's known that there will be Perl developers in your company for the forseeable future, it may not make sense; you're more familiar with perl and its libraries, and you'll be able to maintain the site more easily as you won't need to 'switch modes' between the two languages.

However, your boss may have some particular ideas for why s/he wants PHP: cheaper, more plentiful developer base (though that may change); easier to find hosting should s/he decide to outsource the hosting (I see PHP on more shared hosts than perl); perhaps some business partnerships that would involve exchanging APIs and code.

Do more research before you make your decision; but don't believe all FUD you hear about either language.

Replies are listed 'Best First'.
Re^3: perl vs. php
by friedo (Prior) on Nov 15, 2005 at 19:00 UTC
    Thanks for the informative update, weierophinney. It seems at least some of my PHP knowledge is old and crusty. Fortunately I have the luxury right now of continuing to be a Perl snob. ;-)
Re^3: perl vs. php
by emazep (Priest) on Nov 17, 2005 at 01:32 UTC
    There are security problems in just about every language; perl is not immune to this.
    I would nevertheless say that Perl is somewhat more immune to security problems than PHP since, as I've already said in another message, PHP doesn't have a taint mode (contrary to Perl.)

    (I've heard about an attempt to provide PHP with a taint mode (PHPrevent), but I think that's at present more a theoretical study than a working extension.)

    Most security problems seen recently have less to do with the language itself as with bad programming practices
    Taint mode is something that can help to detect and prevent such bad programming practices, and it is something that unfortunately PHP can't offer.