PHP vs perl
By Justin Silverton
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.
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):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.
[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.)
[1] Source: PHP Quick Reference [2] Source: perldoc perlfunc
20 Comments so far
Leave a reply
hi..am new here…just tryin to navigate my way around…catchya laters
welcome to whenpenguinsattack.com. I hope you enjoy your stay.
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.)
This post has been removed by the author.
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.).
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.
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.)
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.
* 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.
“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.
When I have to, I prefer to write my PHP in Perl…
PerlHP that is.
hah, nice spreading the fud. I admit I did not read your whole post, less than half way I could not take the incorrectness of it. Since when does perl have more security holes than php? common now, your comparing languages both are susceptible to cross site scripting, its up the the application developer to make the right choices. Oh and obviously from your post you have *never* written anything in perl besides a hello world website. Perl used to print html tags? you have to be kidding me. Template toolkit and Mason are more inline with PHP. Both TT and Mason are template languages. Don’t get me started on PHP’s cluster fuck of code with markup - BAD BAD BAD. You want to seperate your code from your view, this has been pioneered by smalltalk, and guess what? it really works well! There are certain frameworks such as symfony and CakePHP which try to alleviate the whole login and view cluster fuck in PHP , but their performance is much left to be desired from. oh and Perl’s interpreter is head and shoulders faster than PHP. At the end of the day? PHP is for kids and Perl is for men.
victori,
“Oh and obviously from your post you have *never* written anything in perl besides a hello world website”
I don’t use perl to write websites as it was not built for it (PHP was designed with the web in mind and has almost all of the functionality that I would ever need for building websites). I do use perl for scripts that will be running in the background or used for scheduled tasks.
“There are certain frameworks such as symfony and CakePHP which try to alleviate the whole login and view cluster fuck in PHP , but their performance is much left to be desired from”
Care to show some proof of this?
“oh and Perl’s interpreter is head and shoulders faster than PHP. At the end of the day? PHP is for kids and Perl is for men.”
perl may be faster in some respects, but it was not built for the web..plain and simple. If you are going to go with perl..why not just go all out and pick a compiled language such as c/c++?
At the end of the day, each language will have fanboys..and it seems you are one for perl (judging from your blog). I just choose the best tool for the job..and perl is not that tool for websites.
Just googled “php vs perl” and spent the past 2 hours reading up.
Regarding the “overhead” of perl [url]http://shootout.alioth.debian.org/gp4/php.php[/url]
Seems your not entirely correct. Seems others aren’t either. Under these sets of tests perl is roughly 1.5 times faster [b]most of the time[/b]. [b]Sometimes[/b] php is up to 6.4 times faster. perl is usually about 3 times less memory consuming, php up to 10 times less, sometimes. Conclusions? If you care about the speed difference between the two, stop using perl and php, and build a custom server running compiled c programs as webpages. You will get more performance by programing smart (in either php or perl), rather then by using said language.
As for security… perl is how old? If your worried about security, obviously as stated before, program smart (regardless of language). That being said, would you rather a veteran or a rookie on your side?
Easy of programing and ease of finding a webhost, php wins, for most projects.
Power, utility and scalability, perl wins (IMHO for any project, small or large).
[b]Why I like to choose perl?[/b] The simplest example is going from perl regex to the preg function set in php. Anyone who knows perl regex knows that 50% of it is missing in php. Can you do it in php? yes. Can you do it in one or two regex(es? or s? wait… regexi? 0.o) nope, maybe 5 a few ifs’, and some extra (.*)s’.
php was originally designed for ~only~ spitting out web pages. perl was originally designed for eating chunks of strings and spiting out easier to read chunks of string. So at the end of the day, if your doing more then a wiki, blog, or a forum, you should think perl. Arguably phpbb might be a little easier to debug if it was perl… then again… maybe it would never be easy
punbb on the other hand (a “lightweight” forum that can work as a replacement for the bloat of phpbb) would probably suffer if turned into perl. If you just want a website that’s cooler then your friends myspace, and is easy to improve, then go php.
All the posts here are well argued. I appreciate your efforts in popularizing your language. Please let me convey my opinions too:
* PHP is really good language for almost every task
related to web applications. We can do load balancing
with lot of ease compared to a java application.
Superior graphics (drawing splines etc.)with mouse
events is also achievable.
* Things which PHP cannot do:
We cannot know how many bytes of a file are getting
tranferred to server when uploading a file.
We still don’t have OpenGL support for standalone
graphics and GTk doesn’t help much.
* Perl is good for all tasks but one has to be really
keen on getting free drivers for supporting databases
on mis-match OS.
Eg: Driver for SQL server on SuSE linux.
* Mod-Perl is good but less people use it. Mason has
memory leaks.
* I use mostly procedural coding until and unless there
is real requirement for OOPS (for eg: grpahics). We
must remember that a web page has small life. I
developed java applications also calling an applet in
a server page for getting good graphics. But it was
very slow while we executed it. (despite having 1 GB
RAM in our server).
* I think we may depend on PHP/PERL but for this we have
break down complexities (good work for designers). In
comparison Java/C++/Python can handle complexities.
(But bad for maintenance..we may get lost on what we
wrote)
* My Verdict (Left for u guys):
Finally before you all make a decision on PHP vs Perl,
please check Google Maps. Try achieving that with Perl
and PHP. Then you know better.
“Finally before you all make a decision on PHP vs Perl,
please check Google Maps. Try achieving that with Perl
and PHP. Then you know better.”
I don’t see any reason why google maps could not be created in PHP or perl. Its power comes from some clever client-side techniques in javascript.
I think the security arguments are moot.
If one is writing a production web application one should be familiar enough with the language they are using that they don’t introduce security holes.
The security problems inherent to php / perl applications are not (for the most part) due to flaws inherent in the languages themselves, but are (for the most part) instead due to lack of adequate security auditing of the code before relese. Don’t blame the language, blame the coder. And if you are using insecure software written in php and your server is breached, again - blame the coder, not the language.
I write php (I have dabbled in perl but am not proficient). I have two workmates who write perl. There hasn’t been a single argument against php in favour of perl by my workmates that I haven’t been able to refute, aside from 1) inconsistent function naming and 2) huge, ‘hard to remember’ library of core functions. The first is a valid argument, the second is subjective.
Perl has the CPAN, which is a very nice module. Although, indeed PHP was (so it seems, or grew) built to serve webpages.
I have to confess I’ve never done any project with PHP. I’ve always been using perl, my friends have always been using php. After 2 years most of them decided to give up php and choose perl. As soon as their projects got more complex than a ‘personal home page’ they encountered problems that were hard to solve with php. Then I came in “Hey, in perl you can do it with one line of code!”.
PHP is good if you can’t code but you want to have a php.
After reading this article someone may think perl is poorly featured - it’s not true: you always can find a module or two in CPAN -> Perl can be embedded in HTML without any difficulty, if you know which module to use.
marduk,
Can you give me an example of something web-related that you can’t do in PHP, but can do in perl (easily)?
I have been coding for 10 years, and PHP can be as complicated or a simple as you want it to be.