whenpenguinsattack.com

Friday, April 14, 2006

PHP vs perl

By Justin Silverton

if you have a php, programming, or open source related blog, email me your url here: justin@whenpenguinsattack.com

PHP and perl are both powerful languages used successfully in a server environment. Here are some brief differences between the two languages:


  • PHP is built from the ground-up with database functionality built in, particularly MySQL functionality. Perl is not.
  • PHP code gets embedded into HTML pages, unlike Perl. This makes it very fast to code web pages and fast to deploy a new site, thus speeding up Web development and lowering overall cost of ownership. An important code management technique for programmers is separating code from data. This allows us to make changes to the code or data without affecting the other. PHP uses the tags to indicate "code inside". In Perl, however, programmers are encouraged to use print statements to generate the HTML. True it is possible to implement templates in Perl (with more difficulty than in PHP) to separate code and HTML, but 90% of sample Perl code on the web doesn't do that.
  • PHP is secure. Perl scripts tend to have more security holes. This is because PHP has built-in a lot of the internal operations of dealing with web page requests and serving information.
  • PHP is easy to learn in comparison to Perl. It's easier to learn than C, Python, Java, and most other programming languages used in web development, for that matter. The Perl style of programming is unique, and thus not universally applicable to or from other programming languages. Accessing web form variables in PHP is straightforward, but in Perl requires either detailed knowledge of either HTTP header formats or one of many Perl CGI libraries.
  • PHP takes less "overhead" than Perl, meaning that PHP scripts will run faster than CGI scripts written in Perl, and you'll be able to handle more simultaneous users on your site.
  • PHP code tends to be more consistent and modular than Perl.
some other differences can also be found here: http://tnx.nl/php

A few of them are listed below (the rest can be found at the website listed above):

PHP has separate functions for case insensitive operations

(This can be argued both ways. Some think it's good to have functions that combine functions, even if that means having dozens of extra names to remember)

In Perl, you use a double lc() (lowercase) or the /i flag where PHP usually provides a case insensitive variant. The case-insensitive versions have very inconsistent naming.

Perl: $foo cmp $bar                            lc $foo cmp lc $bar
PHP: strcmp($foo, $bar) strcasecmp($foo, $bar)

Perl: index($foo, $bar) index(lc $foo, lc $bar)
PHP: strpos($foo, $bar) stripos($foo, $bar)

Perl: $foo =~ s/foo/bar/ $foo =~ s/foo/bar/i
PHP: $foo = str_replace('foo', 'bar', $foo) $foo = str_ireplace(...)
PHP: $foo = ereg_replace('foo', 'bar' ,$foo) $foo = eregi_replace(...)

PHP has inconsistent function naming

  • Case insensitive functions have the 'i' or 'case' at different positions in their names.
  • There is no apparent system in underscore(s) versus no underscore(s):
    underscore               no underscore:

    stream_get_line readline
    disk_free_space diskfreespace
    is_object isset
    mcal_day_of_week jddayofweek
    set_error_handler setlocale
    snmp_get_quick_print snmpget
    get_browser getallheaders
    base64_encode urlencode
    image_type_to_mime_type imagetypes
    msql_num_fields mysql_numfields
    php_uname phpversion
    strip_tags stripslashes
    bind_textdomain_codeset bindtextdomain
    cal_to_jd gregoriantojd
    str_rot13 strpos
    Perl has no core function names with underscores in them.
  • PHP has unlink, link and rename (system calls), but touch (the system call is utime, not touch).
  • And they can't decide on word order:
    • object verb: base64_decode, iptcparse, str_shuffle, var_dump
    • verb object: create_function, recode_string

    Perl core functions are all "verb object" except the superseded dbm* functions. (Note that sys is a prefix, not an object. And that flock and lstat were named after the system calls. shm* and msg* are library calls)

  • "to" or "2"?

    ascii2ebcdic, bin2hex, deg2rad, ip2long, cal_to_jd (jdto*, *tojd), strtolower, strtotime,

PHP has no lexical scope

Perl has lexical scope and dynamic scope. PHP doesn't have these.

For an explanation of why lexical scope is important, see Coping with Scoping.

                       PHP  Perl
Superglobal Yes Yes [1]
Global Yes Yes
Function local Yes Yes [2]
Lexical (block local) No Yes
Dynamic No Yes

[1] Perl has variables that are always in the main:: namespace. These are like PHP's superglobals.
[2] Using a lexical variable in a sub routine's block, you get a function local variable.

PHP has too many functions in the main namespace

(Using the core binaries compiled with all possible extensions in the core distribution, using recent versions in November 2003.)

Number of PHP  main functions: 3079 [1]
Number of Perl main functions: 206 [2]
Median PHP  function name length: 13
Mean PHP function name length: 13.67
Median Perl function name length: 6
Mean Perl function name length: 6.22

Note that Perl has short syntax equivalents for some functions:

readpipe('ls -l') ==> `ls -l`
glob('*.txt') ==> <*.txt>
readline($fh) ==> <$fh>
quotemeta($foo) ==> "\Q$foo"
lcfirst($foo) ==> "\l$foo" (lc is \L)
ucfirst($foo) ==> "\u$foo" (uc is \U)

[1] Source: PHP Quick Reference
[2] Source: perldoc perlfunc

11 Comments:

  • hi..am new here...just tryin to navigate my way around...catchya laters

    By Anonymous Anonymous, at 9:32 AM  

  • welcome to whenpenguinsattack.com. I hope you enjoy your stay.

    By Blogger justin silverton, at 1:38 PM  

  • Your arguments are... interesting.

    PHP's security is really difficult to defend, given the language's history of being insecure by default (allowing clients to manipulate variables within the code simply by adding them as URI parameters, a lackluster and inconsistent approach to avoiding database injection errors, no distinction between opening local and remote files, and no security mechanism by which to taint untrustable data, as Perl has). Certainly it is possible to write bad code in any language, but insecure defaults and the lack of good mechanisms to secure programs make PHP much more difficult to secure than Perl.

    The overhead issue is a non-sequitur. This depends on the execution model, which has very little to do with the language and everything to do with the configuration of your server.

    The issue of modularity and consistency is not in PHP's favor by any means. Perl has several thousand redistributable and installable and nearly all open source distributions available on the CPAN. PHP has PEAR, but it doesn't compare for breadth or popularity.

    For anything beyond a simple page, even PHP gurus recommend using a templating system. There's no large advantage to the embedding approach.

    PHP only includes database features if you build them in at compile time. You can enable them in Perl by installing a module. If you want to add support for a new database, you have to recompile PHP. You only have to add a new module to Perl.

    You can decide which is easier.

    Ultimately, learnability is for the learner to decide, but accessing client parameters in the recommended and secure way in PHP requires learning something just as much as accessing such parameters in Perl means learning something about a library as well.

    Besides that, claiming that Perl is not universally acceptable (and implying that PHP is) is silly. PHP arrays are fairly unique in their behavior, for example, as are PHP's variable scoping rules.

    In my mind, PHP's two big advantages are its ubuiquity in cheap hosting providers and the ease of installing pre-written PHP software. (I think it's PHP's oversimplicity that makes the latter possible, but it is definitely an advantage.)

    By Anonymous chromatic, at 6:13 PM  

  • This comment has been removed by a blog administrator.

    By Blogger justin silverton, at 11:41 PM  

  • Thanks for the comparison, Justin. I think that anyone's who has spent even ten minutes looking through the PHP manual will agree that the inconsistent function names isn't such a big deal because it's trivial to look them up if you happen to forget. Otherwise, PHP's ease of Web-specific development is second to none in terms of core language features.

    Some of the arguments by chromatic show a lack of understanding of PHP, especially modern PHP. The language's history may have some bonehead aspects like register_globals, but any competent PHP programmer knows to turn that off or program around it. It's off by default in PHP5, and it won't even be available in the upcoming PHP 6.

    PHP's modularity and consistency comes not from the idea of "modules" but from the idea that 90% of all PHP applications can run anywhere and use language features common to virtually all PHP runtimes. That means that you can download PHP software, libraries, code examples, etc., and get them working immediately in your own applications. It also means you can tweak existing applications easily. PHP is a known quantity -- once you've learned the fundamentals, it's very very difficult to find a PHP application that strays into unknown territories (i. e., using rare PHP extensions, relying on system libraries that might not exist, etc.)

    PHP *is* a templating system at heart, and many PHP gurus will tell you that in a good MVC-style framework, the templates can be written in PHP directly. Systems like Smarty are over-rated and falling out of favor.

    You don't need to recompile PHP to add an extension such as database support. PHP supports dynamically-linked extensions and has for some time. Check out PECL sometime for more information.

    It never ceases to amaze me what things people will say against PHP that don't actually reflect what's really happening with the language at all. PHP may have been a toy for script kiddies five, three, maybe even a couple of years ago, but at this point it's a grown-up, sophisticated language that's being used to power huge Web sites with millions of hits every day without breaking a sweat. PHP 5.1 is a rock-solid, modern, OOP-friendly language, and PHP 6 is under active development and should remove nearly all of the remaining gaps in PHP (lack of namespaces, tricky Unicode support, no built-in optional input filer, no built-in opcode cache, etc.).

    By Blogger Jared White, at 10:57 AM  

  • You both have made some great points about the PHP language.

    I have used both PHP and perl extensively, and prefer PHP for web based projects and perl for stand-alone scripts.

    I also have used smarty templates for many of my projects, and I think it works well because it allows a designer to go in and make changes without having to know or touch any of the PHP code.

    By Blogger justin silverton, at 12:29 PM  

  • New features in PHP 5 and PHP 6 won't matter much until the ubiquitous cheap PHP hosts make those versions available -- especially security features.

    PHP 6 won't make PHP 3 or PHP 4 or even PHP 5 go away.

    I agree that a competent, experienced, and careful programmer can write a secure and maintainable PHP application. I strongly disagree that PHP -- even version 5.x -- encourages novices to do so. Removing register_globals is a good step, but that doesn't fix the backwards compatibility problems in existing code that cheap hosting providers don't want to support and really don't want to break.

    (I didn't check whether PHP 5 works with PECL and I should have; this was a mistake.)

    By Anonymous chromatic, at 4:04 PM  

  • Sorry to correct you, but you made it one of your main points:

    "PHP takes less "overhead" than Perl, meaning that PHP scripts will run faster than CGI scripts written in Perl, and you'll be able to handle more simultaneous users on your site."

    PHP can be run as CGI scripts, or through mod_php.
    Perl can be run as CGI scripts, or through mod_perl.

    mod_php will be faster than perl cgi. mod_perl will be faster than php cgi.

    I've never compared mod_php with mod_perl, but it would be interestign to see benchmarks for simple, similar scripts.

    By Anonymous Tony, at 3:24 AM  

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

    I've always hated the built in PHP functions. Perl's DBI module is mature, stable, feature complete, and is easy to install (cpan install DBI && cpan install DBD::mysql).

    * PHP code gets embedded into HTML pages, unlike Perl. This makes it very fast to code web pages and fast to deploy a new site, thus speeding up Web development and lowering overall cost of ownership. An important code management technique for programmers is separating code from data. This allows us to make changes to the code or data without affecting the other. PHP uses the tags to indicate "code inside". In Perl, however, programmers are encouraged to use print statements to generate the HTML. True it is possible to implement templates in Perl (with more difficulty than in PHP) to separate code and HTML, but 90% of sample Perl code on the web doesn't do that.

    I can't imagine a perl programmer being encouraged to use print statements. True, many perl scripts use this technique. However, they are quickly falling out of style. There are numerous templating systems for perl and many of them are quite good. Mason, Template::Toolkit, and even HTML::Template are a few good ones. And then there is XML::LibXML and XML::LibXSLT for when you want to write a truely modern and extremely powerful templating system.

    * PHP is secure. Perl scripts tend to have more security holes. This is because PHP has built-in a lot of the internal operations of dealing with web page requests and serving information.

    Ok, I'm not even sure how to respond to this one. However, to put things into perspective, I did some searches at the Open Source Vulnerability Database (http://osvdb.org). The term "perl" returns 2 pages of results. The term "cgi" returns 16 pages. The term "php" returns a whopping 115 pages.

    * PHP is easy to learn in comparison to Perl. It's easier to learn than C, Python, Java, and most other programming languages used in web development, for that matter. The Perl style of programming is unique, and thus not universally applicable to or from other programming languages. Accessing web form variables in PHP is straightforward, but in Perl requires either detailed knowledge of either HTTP header formats or one of many Perl CGI libraries.

    I won't argue with this. Anyone can pick up php in an hour and write a crappy script. Then again, you can do that with perl too. Also, it is a very good idea to understand how HTTP headers work when programming a web app. Not understanding core features such as that is what leads to security ridden applications.

    * PHP takes less "overhead" than Perl, meaning that PHP scripts will run faster than CGI scripts written in Perl, and you'll be able to handle more simultaneous users on your site.

    This is a useless statement. What are you comparing here? Other's have already mentioned mod_perl, which completely debunks any disillusion of php being faster than perl.

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

    Huh? Care to elaborate on that statement? There are thousands of MODULEs available on CPAN. It is a very modular language. PHP tends to be much more procedural than perl. Especially since php is geared more towards newbie programmers.

    By Anonymous Anonymous, at 8:23 PM  

  • "Ok, I'm not even sure how to respond to this one. However, to put things into perspective, I did some searches at the Open Source Vulnerability Database (http://osvdb.org). The term "perl" returns 2 pages of results. The term "cgi" returns 16 pages. The term "php" returns a whopping 115 pages."

    I also searched osvdb.org and looked through these results. The reason there are so many flawed scripts is because PHP is easier to pickup than perl and most newbies, who don't understand the fundamentals of a secure application (such as checking a POST variable before sending it directly to a databse) are writing these scripts.

    Therefore, in this respect, perl is more secure. Most newbies shy away from perl because of its higher complexity.

    Perl also lends itself to background scripts and services. These will be much less likely to be exploited by people from the outside and will not show up on security sites.

    "This is a useless statement. What are you comparing here? Other's have already mentioned mod_perl, which completely debunks any disillusion of php being faster than perl."

    Point well taken. I have more experience setting up PHP on *nix systems than perl. I have used mod_perl with Apache, but maybe I need to perform some better benchmarks.

    "Huh? Care to elaborate on that statement? There are thousands of MODULEs available on CPAN. It is a very modular language. PHP tends to be much more procedural than perl. Especially since php is geared more towards newbie programmers."

    PHP supports a more advanced OO model:

    http://us3.php.net/manual/en/language.oop5.php

    OO perl does exist, but it is much more difficult to read and use (examples of OO perl code can be found here: http://www.codeproject.com/perl/camel_poop.asp)

    I have always felt that web scripts in perl are a dirty/messy hack and that PHP was built with web apps in mind. It might be because I can still remember writing CGI scripts in c/c++/perl and having to decode all of the GETS and POSTS manually. PHP is very easy to pickup and use, especially if you already know other lower-level languages.

    My article was mainly created to show two different view points on perl and php. Both languages have their place and in the end, a language's security is only as good as the programmer.

    By Blogger justin silverton, at 11:01 PM  

  • When I have to, I prefer to write my PHP in Perl...

    PerlHP that is.

    By Blogger Michael, at 4:43 AM  

Post a Comment

Links to this post:

Create a Link

<< Home