A pro-PHP Rant

OK – following on from here and a later comment from Tim (and in fact more this rant from Jonas Maurus);

How about somebody sends me some good pro-PHP rants?

So here’s some pro-PHP ranting…

It’s the execution model

Focused on PHP as an Apache module the two big things are it works and it’s scalable. More to the point no one really has an execution model to compare with it, except perhaps Microsoft with ASP 3.0, which they’ve since abandoned. Before you fly off the handle, think about this one.

Tried to explain the basics a long time ago here – the important thing to take from that (compared to mod_perl / mod_python / mod_* or even “X” application server.) is the interpreter returning to a fresh state after every request (no globals hanging around or otherwise). PHP really is shared nothing. You want scaling? Try here.

Meanwhile, in these days of long tail enthusiasm, other than PHP, you don’t get to hear much about when stuff sucks. Put specifically, don’t bring me your FastCGI unless you’re providing free SMS to go with it, so I can alert myself when it goes down. There are smallish sites I own / run, built on PHP, which I don’t look at for months but are still, magically, running next time I go there – be it impression or not, PHP just keeps on running – restart Apache or reboot and it’s back without sysadmin effort.

Being a little more specific, the execution model PHP gets most testing under is mod_php and CGI, where there’s no “long running scripts” and no need for threads. PHP is optimized to that environment. By contrast Perl, Python and Ruby are general purpose languages and optimized to different requirements. The web is just another platform they support, compared to PHP where the web is the primary platform. The can be expressed in terms of configuration settings like max_input_time and post_max_size – with PHP these problems have had someone thinking about them.

Excellent database support

Lets start with the usual nag here – that PHP doesn’t have a common API for database abstraction. Well that’s always been bogus anyway – SQL itself is rarely portable and writing an application against a specific database requires specific work, so that you’re API happens to be the same as that for some other database is largely irrelevant. That said a common API does make the learning curve easier if you start another project with another DB but PHP’s first priority is to expose “vendor specific” features, like pg_send_query or mysql_unbuffered_query. Put another way, most of PHP’s DB APIs have a one to one relationship with the vendors client API and the benefit there is you don’t lose features or have to fight for them.

That’s not to say you can’t have your DB abstraction cake in PHP – the one I trust most is ADOdb – a native PHP implementation (side note – Python devs may be interested to know John also maintains a Python version of ADOdb). There’s also PDO which is getting there and (I’d argue) something that parallels Perl’s DBI. Should also point out PEAR::DB, PEAR::MDB2 and Creole. And don’t get me started on ORM…

What doesn’t get said is PHP may now have the best (as in most stable and feature complete) across the board db support of any of Perl, Python and Ruby, which, seen from one point of view, makes sense given the number of PHP users. That PHP’s DB support is better than Python’s or Ruby’s that’s probably no news but compared to Perl, was recently surprised to discover that DBI lacks support for Oracle collections, which PHP has. Perhaps that’s just a freak but perhaps not – anyone with experiences to share there?

PHP Arrays

Now the computer scientists typically hate PHP’s arrays, which are both indexed and hashed. Reality is they are not only easy for beginners to get in to, they’re very handy for the web problem (e.g. good fit to ad-hoc XML) and for simple iteration, it’s nice that hashes and indexed arrays unified by common syntax and behaviour. Sure they don’t support everything a computer scientist might want, such as (Python);

points = {}
points[(1,2)] = 2
points[(2,4)] = 4

…but on the web, who cares? You’d hardly ever need something like that and where you do, JPGraph makes life easy enough. Meanwhile performance turns out to be not bad by comparison.

BTW, if you want computer science and PHP, take a look at (current favorite bizarre PHP project) J4P5 (a Javascript intepreter written in PHP). Can come up with endless projects of that nature if you’re interested.

More generally, there’s a virtual web ring (how 90’s) of PHP hate which starts from here. 90% of the criticism you’ll find there is simply irrelevant (one day I’m going to do this in detail, if I can be bothered) – these are either not problems for web development or disappear with PHP’s (rollercoaster) learning curve (e.g. the endless functions in global namespace is irrelevant if you’re writing classes). One day I may also do my own take on why PHP sucks (in the sense of Bjarne Stroustrup and: “There are only two kinds of languages: the ones people complain about and the ones nobody uses”) which I’d expect to be a very different story. Today you’ll have to excuse me for focusing only on the good things.

The SPL Extension

Following on from arrays, this is a big reason to use PHP5 if you’re a programmer. It makes a number of classes of web related problem ridiculously easy to solve and gives you syntactic joy should you want it. Some further reading here, here, here, here and here.

PHP 5(.1) XML Support

One for Tim – XML support in PHP 5(.1) is excellent, thanks to libxml2. And it’s not just that the core parser is good, it’s that you’ve got multiple APIs in PHP to it, namely SAX and it’s faster “invert” XML pull reader, SimpleXML and DOM, as well as the supporting cast of XSLT etc. Of course Python, Perl, Ruby etc. also have libxml2 wrappers but this is still a PHP strength, plus libxml2 has become the core of PHP’s XML capabilities, rather than another alternative.

The stuff that says it works… works

Programmers have obsessions with building better cages for themselves, for the sake of a particular paradigm they believe in. Nothing wrong with that but the road to get there is littered with stuff that was broken or partially complete. For the stuff you need for the web, PHP is already there. That’s not to say there isn’t a bunch of unstable code in PHP – just the stuff you’re typically going to use works.

Put another way, PHP has become predictable, at least for me and anyone willing to travel the learning curve. That means if I need to give projects estimates, for example, I know when I can keep to them. I’ve also found it easy to teach to others – takes about a week to get a programmer able to churn out useful PHP if I can work directly with them. I’d rather trade a (slightly more) verbose syntax and delivering on time against 15 minutes syntactic glory, followed by 10 hours bug hunting and another 15 hours workaround. Luckily not everyone thinks this way or progress would have halted.

Unicode and ICU

Having talking about stuff PHP already has, it’s worth being aware that PHP6 is using ICU as part of it’s “core” – see here, here and here. PHP6 already “exists” under CVS and if it’s resticted to the Unicode changes only, it’s less of a step up than PHP5 and may be here sooner rather than later. You might then be able to argue PHP has better Unicode support than Perl and Python.

Stuck in Little boxes

This is bordering on holy war, which I don’t want. Recently language bickering has been back “in”, and if you take it seriously you might believe Perl, Python and PHP are all dead and there is only Ruby. To me that’s simply Ruby (rightly) jostling for a space alongside the others and it’s best put in perspective here.

Being happy in Perl, Python and PHP these days, watching people cry “This rox, everything else sux” borders between amusing and frustrating. Syntax is only one part of the story. Libraries is, to me, the bigger part – what use is great syntax if you can’t do anything with it or need to spend time re-inventing wheels?

For example Perl is like comfortable slippers on the command line – take me away from Getopt::Long and POD::Usage and get screaming. Little things which matter. And have found Perl capable of pushing big blocks of data around a DB at speeds comparable to SQL*Loader.

Meanwhile have used wxPython in earnest once (book due soon!) – none of the other dynamic languages can compare to it – yes there’s wxPerl, wxRuby (**cough** wxHaskell) and even wxPHP but they’re not mature by comparison – check out Activegrid’s IDE download under “/src/python/wxPythonDemos/ide” – these days we can all write our own IDEs… And Python has the dirty secret of excellent Windows support. If I had time to burn I’d love to take this shell namespace extension demo and the Python libssh2 wrapper and do a GMail drive for scp.

The point is people leap on a language then claim, because it does one thing well, it’s the only tool for everything. It’s really a shame time is being spent on wxRuby / wxPerl or otherwise, given that wxPython is already there. It’s far more of a shame that we’ve invented endless template engines for the web – not just the wasted development time – also the wasted user time in identifying and learning to use them (this stuff drives them to Microsoft). And it’s not just the re-invention – it’s that we not even really sharing ideas or seeing them spread – Jeff nailed templates a long time ago but today you’ll find Ruby developers discussing the pros and cons of curly brackets vs. attribute for templates.

Specific to PHP, if you accept there are some things it actually does well, in particular the execution model, it then becomes more a question of how to get the best out of all worlds. In my view (based on what I’m happy with) that’s Perl at your backend for sysadmin, moving data around etc., Python helping users publish their MS Office stuff and PHP serving it to the world.

Along that lines been looking at Fuse and it’s Python and Perl bindings. Have a very specific interest right now which I guess will tell me how stable this stuff is but, all being well, think there’s potential here for hooking up PHP with Perl and Python, via the filesystem, perhaps in conjunction with libxml2.

In short: PHP’s Schwarz is bigger!