Scott's Blog

You can tell that the PHP designers struggled to avoid making PHP too much like Perl. The problem is, in haphazardly adopting some parts and rejecting others, they produced a language that can be even stranger to use. Here’s a good paper describing some of the issues.

In February I had the opportunity to make a reasonably complex mod_perl-based site (using HTML::Mason to do the templating), and in October, I made a reasonably complex PHP-based site. I feel that I’ve now used both to capacity. The verdict? They both work very well, but they both have serious limitations. You need to use the right tool for the job.

With mod_perl, you spend more time dealing with low-level stuff. Exactly how do you want to maintain session data? How do you want do synchronization? It harder to start a project but it does offer amazing flexibility. You can store session data however and wherever you want. Do you have a unique requirement like, say, needing to store your session data on a WebDAV server? No problem. Once your wizards get it working reliably, you never have to touch it again.

PHP, on the other hand, gives you sessions right out of the box. They just work. Unless you want to do something slightly beyond trivial. For instance, one of my PHP sites needed to copy a variable from one session to another (due to naming issues I couldn’t just merge the two sessions into one). I struggled for two days before realizing that I was absolutely screwed. Forget having two sessions open simultaneously: PHP makes it impossible to open one session, close it, and then open another. It’s an astounding limitation. PHP’s libraries grew directly out of the needs of the people that wrote them. None of them have really been fleshed out completely. For instance, you can’t use the FTP library to read a remote file into a string — you have to save it as a file in /tmp, read the file into a string, then delete the file. There’s just no design forethought.

With mod_perl, you have pretty much every module on CPAN at your disposal. Over 25,000. That’s a hell of a lot of functionality at your disposal. Frankly, it’s daunting. You need to spend a fair amount of time just managing the modules you’re using. Is Apache::Session::Flex being buggy? Try Apache::Session::File. With PHP, you don’t need to spend any time managing externals: if it’s not built into the language, you’re pretty well hosed.

Perl is outrageously expressive. There are 5 different ways to write any single concept. This makes it hard for one programmer to read another programmer’s code. I imagine it’s a bit like the British Isles a few hundered years ago: Perl programmers really have to concentrate to understand each other’s thick accents. On the one hand, it leads to an amazingly rich culture. On the other, it leads to fragmentation.

PHP is exactly the opposite. It’s got very clear idioms for very common operations making the code easier to read for others. The problem is, uncommon operations are very difficult. For instance, to prevent PHP from transparently duplicating an object when performing an assignment or calling a function, you need to mark it with an ampersand. You must to scatter ampersands everywhere! If you forget a simple ampersand, you’re now operating on an exact duplicate of the object and any changes you make silently disappear when the script ends. It can be outrageously difficult to debug this sort of thing. For complex data processing, definitely avoid using PHP objects! If you forget one ampersand it might take days to try to track it down.

mod_perl can drive your memory usage through the roof if you’re not careful. The programmer needs to remember at all times to walk very lightly in the process space. A single Apache process can collect a fair amount of garbage as it handles hundreds of requests before terminating. With PHP, you can be fairly careless how you handle memory and files because all resources are automaticalliy released when the script ends.

Both scale to millions of hits without too much trouble (IMDB (modperl) and (insert PHP example here)). However, when code corpus gets big, they both tend to fall over. Small to medium sites with tight, well-disciplined development teams can use them well, but they are both unsuitable for big projects. Perl allows better encapsulation and modularity, but it also has a weirder syntax.

What happens when you need to make deep changes to your project? Well, refactoring Perl is usually painful. Refactoring PHP, however, thanks to its odd usage of global variables and lack of “use strict” is an absolutely monstrous task that should be avoided at all costs. Witness how large PHP projects typically fork and rewrite, rather than refactor. Unit testing and automated testing is much easier in Perl than in PHP. In fact, many Perl modules include very good test suites right in their distributions.

So, what does it all mean? I suppose you could think of PHP as a small, powered snowblower. It is extremely good at clearing your driveway when it snows, but that’s about all it can do. When things start getting unique, say, if it occasionally rains frogs instead of snow, you’re stuck.

Perl is more like a snow shovel. It requires a little more sweat, a little more skill, and a little more time, but it is also extremely good at clearing your driveway of snow. It can also clear your sidewalk and front porch, and is just as good with mud or frogs as it is with snow. You can use it as a sled, fend off an intruder, grill food on it, … In fact, whatever it is you want to do, somebody else has probably already done it and uploaded a module to CPAN.

So which one should you use? Well, as always, that depends entirely on the problem you’re trying to solve.