Web Automation: PHP vs. Perl vs. PHP

I'm going to briefly tangent away from my usual HOWTO-style column, and get a bit teary-eyed and philosophical. There's been a lot of hype lately about PHP and Perl: one columnist claims that PHP is killing Perl, another one claims that PHP is overrated, and the newsgroups are filled with "PHP kicks Perl's [butt]" and "Perl dusts PHP" postings. Since both of these languages are so crucial to Web automation, I thought I'd take article and help cut through the zeal and look at these languages.

It's turning out to be the eternal debate in the Apache world: which is better, PHP or Perl? Both, according to Matthew Keller, who makes some compelling arguments for both.

Just for the record, I've used Perl for many years and PHP for a little over a full year. I've created large applications in Perl, and I've created mediumishly-large applications in PHP. I know Perl like the back of my hand, but I also know PHP pretty well. Nine times out of ten I'll make a web application in Perl instead of PHP, but that's my choice, and the reasons for that will unfold below.

PHP and Perl are both interpreted languages, which means they aren't compiled like C or Java. Instead of being compiled, they are read by an interpreter, which instructs the computer to "Do the Right Thing" (patent pending). Both languages can be embedded in HTML documents, and both languages have Apache module-based interpreters available.


Perl is not only a Web-scripting language, and looking at is as such only shows a microcosm of its true nature. Perl is, at its most basic level, a text-manipulation language. It provides powerful features that allow the user to easily do some operations that are very complex in C, and also complicates some other things that are easy in C! Perl, in conjunction with CPAN (the Comprehensive Perl Archive Network) offer an enormous amount of "ready-made" modules, that allow code to be reused and shared- database interface modules, CORBA modules, scientific calculation modules, network programming modules, SGML/XML/HTML modules, and so much more. Obviously, because of Perl's powerful and easy text manipulation functions, it was quite natural for web developers to expand their toolbelt to include Perl. Perl can be embedded within HTML documents, run as an SSI (Server-Side Include), or run as its own application (CGI, or Common Gateway Interface). Perl, as applied to CGI and web application design, is designed for the programmer who wants to "output" webpages. A Perl Web application is nothing more or less than a backend program, that interacts with the browser using HTML.


PHP is an embedded scripting language. A PHP-aware webserver parses HTML documents looking for PHP code, processes it, and sends the results back to the browser. PHP's popularity lies in the fact that it is easy to use, and is readily embeddable into HTML documents. Using PHP in conjunction with your favorite HTML editor is an increasingly popular way to provide dynamic web content, with minimal programming. In effect, PHP separates web design from application design. I've worked on a couple large PHP projects where the HTML designers were not even part of the application design team. PHP is developed with the web, and web development in mind.

PHP and Perl: Their Similarities

These languages are both very similar in a lot of areas. Here are few of the most crucial areas that these languages are similar, in my opinion.


Even though PHP or Perl code might be embedded in an HTML document, it is processed by the server and not the client browser. The exception to this (other than misconfigured servers!) is PerlScript, which I know absolutely nothing about.


This article was originally published on Jul 7, 2000
Page 1 of 3

Thanks for your registration, follow us on our social networks to keep up-to-date