in reply to PHP vs Perl code compare

Having been forced to use PHP for the past year or so, I have to say that the more I use it, the more I get annoyed with it. Some of my gripes:

The OO support absolutely sucks. No privitization of variables. No multiple inheritance. It's a performance killer.

Too many damn functions to do every little thing. I'm surprised they don't have a sort_an_array_by_the_values_second_character_if_it_is_after_2_pm() function.

no built-in database extraction

ever changing syntax. from minor point release to minor point release, functions change and break code (look at the manual for entires like "<4.0.3 use xxx. >= 4.0.3 use xxx"). That's damn obnoxious

Socket support keeps changing. Granted it's marked as an experimental module, but the interface has changed between 4.06 and 4.1.x, and between 4.1.x and 4.2.x. It's annoying. We can't upgrade to the latest php because socket use in all our code will break.

Doesn't have Perl's felxibility.

Regex work is clumsy

no map and grep (actually i hear that something similar may now be in there as of a few point releases ago, i havent checked)

that's a few that come to the top of my mind. PHP does have good points too, but to me it's more of a toy language at times.

Replies are listed 'Best First'.
Re: Re: PHP vs Perl code compare
by bart (Canon) on Oct 28, 2002 at 11:53 UTC
    More bad stuff:
    • Basically only two kinds of variable scope: global and local to a function. That means that if you have several PHP files that are intended to be used together, and just "do things" that are not wrapped inside a sub 'er, "function"), that they'll stamp on each others variables. There's no way to limit a variable's scope to "just this block" or "just this file".
    • Guess what value the variable $x will have after the loop finishes?
      # PHP code $x = 'foo'; $row = array('a', 'b', 'c'); foreach ($row as $x) { echo "$x\n"; }
      I'll tell you: loop variables are not localized. Stomp stomp stomp.
    • No support for placeholders in database access *. That means that you have to produce literal SQL strings to execute, by incorporating the data in the SQL statement. It's slow if you have to do this many times in a loop. But, in order to prevent people form accidently creating invalid SQL this way, GET and POST values are pre-addslashes()-ed by default! Talk about doing a patchup in the wrong place!

    Update: broquaint pointed out that PHP does have support for placeholders, which is a good thing. I must say that none of the PHP developers I've spoken to, has ever even heard of them. So use of placeholders in PHP doesn't seem very commonplace. However, my complaint on the automatic addition of backslashes on special characters in form variables still stands, which was my main gripe in that point.

    The phrase "It has about as much support for placeholders as perl does natively" is one I just cannot grok. Perl does not have native SQL database support without DBI. DBI is the way to access SQL databases in Perl. Using placeholders is one of the first things you learn there. OTOH, AFAIK they're hardly even mentioned on PHP's manual website, and only under Oracle and ODBC. Don't you just hate it that every database has its own kind of access functions.

      No support for placeholders in database access
      It has about as much support for placeholders as perl does natively. But if you're using the PEAR DB class then you can use placeholders as you would with perl's DBI.

      While I'm all for pointing out PHP's flaws as a language (which I am acutely aware of having used it extensively for 2 years) I'm just as wary as any language advocate about spreading false information.