dcsimg
 

Web Automation: PHP vs. Perl vs. PHP

by Matthew Keller

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.

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.

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

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

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.

Server-Side

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.

Interpretation

As I mentioned before, both PHP and Perl (as applied to Web applications) are interpreted languages. Interpreted languages are not pre-compiled and executed in a binary format, rather, they are parsed by an interpreter on demand and compiled on-the-fly. Because of this, both Perl and PHP are very portable. Both languages can run on any platform that has an interpreter for the language (with subtle difference here and there).

Another benefit of being interpreted is that the coders can tweak their application and immediately see the results and implement the new code, without having to wait for the application to recompile and relink. On the downside, both PHP and Perl are "slower" and "more costly" than their C or C++ equivalent. What this means is that if you wrote a Perl or PHP application in C, it would run "faster" and use less CPU time. I put "faster" and "slower" in quotes because on the Web, unlike on your desktop, application "speed" is dependent on more factors that just the sheer running time of the application.

Syntax and Core Functions

Both PHP and Perl have their roots in UNIX and UNIX-like operating systems (as well as the C language). For this reason, they both have similar syntax and core functions, such as the "chown" and "localtime" functions.

Integration with Apache

mod_perl and mod_PHP are both very well designed modules that allow the interpreter for the language to be embedded into the Apache Web server itself, speeding up run-time execution and offering a wealth of features above and beyond the standard CGI execution. For example, installing mod_perl on the Apache webserver exposes the Apache C API (Application Programming Interface), which allows you to write Apache server modules in Perl instead of C.

Perl and PHP: Their Differences

Here is where the rifts between these two powerful Open Source communities start forming. There are just as many differences as similarities, and I'm only going to touch upon a few of the ones I think are big and important.

Development Focus

Perl is developed as a versatile, powerful language that is easily (trivially, actually) extensible and can serve billions of purposes. Sure, there is a large segment of the Perl community that work on projects such as mod_perl and write Web-savvy modules, such as Lincoln Stein's CGI.pm module, but the focus of Perl development, as a language, is not based on the Web or the Internet.

PHP is developed for Web automation. PHP developers have added features to make Web content generation trivial, as well as provide easy access (trivial, actually) to a wide range of backend databases. Everything about PHP development screams "give me Web-savvy feature."

Target Appeal

PHP appeals greatly to Web-content designers who know HTML inside and out, but want to spice up their site--add a little database interface here, dash a standard "look and feel" template there. PHP also appeals to the person who want to abstract HTML design, from application design. If you want multifile applications that allow you to quickly and painlessly change one file without affecting (we hope) other pages in the application--PHP is your language du jour.

Perl, as far as Web applications go, apply to the more technically minded person, programmer, or power fiend. Perl's infinite extensibility and modular design make it incredibly popular among web application developers who want a single program (usually with a horde of included modules), or a couple programs, to be their application instead of the several hundred HTML pages that the same application might require if it was done in PHP.

Readily Embeddable

I don't know if "embeddable" is a word, but you get the point.

PHP is designed to be embedded within Web documents, thus allowing you to do your Web design separate from your application design.

Although Perl can be embedded in HTML documents exactly like PHP (check out Embperl), Perl is not marketed that way, and when most people think of Perl, they don't think of it as such.

PHP vs. Perl: Which is Better?

The answer: "Yes." PHP and Perl are both powerful languages that can make web application programming, automation, and dynamic content a joy to work with. When I plan out a project for a client, or even for myself, I consider both languages. I look at the amount of time I have to do the project. I look at the number of "pages" it will need to generate. I think about who is going to be maintaining this application after I'm done with it (I only maintain a trivial fraction of my applications). I look at the technologies I'll need to interface with. All of these questions help me to decide which language to use for a given project.

Sometimes, I use both! I have several applications that use both PHP and Perl together. Either it was a PHP-based application, but I needed to do something that PHP couldn't do--or I had a Perl-based application that had parts that would be easier to implement in PHP. They are both powerful, wonderful languages, and I enjoy using them interchangeably.

My Perl-Bias

As I mentioned earlier, nine times out of ten, I'll use Perl over PHP. The main reasons for this is familiarity and extensibility. I am very versed in Perl and can write code quickly, easily, and enjoyably in the language. I'm also a big code-resuser, and enjoy writing hordes of Perl modules to do things that I do frequently. My background as a traditional programmer, also makes the "single program with a horde of included modules" scenario very appealing.

Perl and PHP: Period.

Both Perl and PHP are crucial tools for the Web developer. A lot of the best Web-application developers I know pick one of the languages as their strong language, but keep in mind the other for those times when it just makes sense.

I recommend learning them both. The more I spend with either language, the more I like them both. There are times when I'm programming in PHP and go running back to Perl with tears in my eyes, and there are other times when I blow countless hours trying to make a particular "thing" work in Perl, only to find out that the PHP equivalent took about 3 minutes. Don't get into the zeal wars, understand both languages and you'll see where I'm coming from. Both PHP and Perl are wonderful, extraordinary languages.

Matthew Keller specializes in server technologies, with bias towards Linux, Solaris and the Apache Web server. Besides working for SUNY Potsdam, he provides numerous consulting services, has co-authored a couple books about Apache, and even manages to wrestle a mountain every now and then. Visit his personal Web site.

This article was originally published on Friday Jul 7th 2000
Home
Mobile Site | Full Site