Like it or not (and, increasingly, folks are not liking it), PHP remains the “defacto standard” language of choice for development of small-to-medium web sites. Any webhosting company worth its service fees provides PHP support on their servers via the Apache APXS module (Windows-based hosts, of course, use Microsoft’s Internet Information Server junk and tie PHP to that).

It’s ubiquitous; you can sign up at almost any webhost, plug in a quick: <?php print "Hello, world!"; ?> and you can be reasonably sure the page you get will just say “Hello, world!”

The problem is there’s a lot wrong with the language. It’s great to see people rip PHP a new one like it so richly deserves … the poster of that comment has the same problem with PHP that I do — it provokes an emotional response (and a quite bad one).

At its core, PHP is “just a tool,” and happens to be one that a LOT of people use. Problem is, it’s seriously broken and it’s very easy for its users to shoot their feet off, staple their hands to the walls, or poke eyes out with it. The “no namespaces” thing is absolutely inexcusable … that is singlehandedly responsible for the majority of security holes and vulnerabilities in today’s PHP applications (as the comment I linked to above mentions, if PHP had namespaces, the register_globals thing and the giant can of worms it brought with it would never have happened. It would have simply been impossible to poison a script’s runtime environment with any variety of “injection attack” with GET or POST variables if the request from the browser lived in its own namespace.

The poster also complains about Unicode support in PHP, which is … “not so good” to say the least. Another issue that I have with it personally is the lack of consistency in function names and argument order between similarly-behaving functions.

Sometimes a function is named subject_verb, other times it’s verb_subject. Still others are subjectverb (no underscore character), and others are verbsubject. The argument list issue is equally annoying: sometimes you call a function like this: subjectverb($subject, $verb); but for other functions, it’s subjectverb($verb, $subject);. My examples are pedantic and stupid, but the point remains: the function name doesn’t necessarily hint at what order arguments should be passed to it.

You can find plenty of better-articulated criticisms of PHP online with a quick Google search, so I leave that as an exercise to my dear readers. I suppose folks are wondering what I prefer to use instead of PHP then for web development, and ironically, PHP is still the language I use for most of the projects I’m working on for assorted clients. I said I hated that it’s the de-facto standard, didn’t I? Now you see why

I don’t prefer to use it, but it’s what is most prevalent right now.

I write my own little “experiments” in Python, a much nicer/cleaner language that fills me with much happiness. I haven’t yet “taken the plunge” in properly exploring the CMS landscape with Python, though I played with Zope 3 enough to know I fucking hate it Fortunately, there’s a bunch of frameworks for Python apart from Zope, and there’s also plenty of libraries around if you want to just roll your own.

A bigger conceptual issue with PHP is just how closely-tied it is to HTML. Languages like Perl and Python are far more “general purpose” than PHP is; PHP’s native syntax permits embedding the language’s tokens and expressions right into plain text (or HTML) files. Perl and Python expect you to separate that crap out — code goes in source code files, and text/content that gets sent to the output goes in its own files. Yes, you can co-mingle content if you really want to, but once you learn the benefits of separating presentation from logic (whether it’s a web app or not), you find yourself never wanting to mix them ever again.

These other “competing” languages can run just as fast (if not much faster, actually) when installed the same way PHP is … PHP’s “trick” for its good speed is that it compiles as a module for a web server (like Apache) and plugs straight in. Python and Perl can also do this, with modules like mod_python and mod_perl (go figure). They even benefit from the same kinds of optimizations — compile once at startup (or first invocation of a particular script) then run from compiled bytecode instead of re-interpreting every file every time it’s requested by a browser, maintain shared state in-memory for multiple threads, etc.

I’d still love to see (and actually, I think it can already be done) a server where dropping a .py file into a publicly-accessible path on the server results in something you can just load in a web browser and have it loaded/compiled/executed by the server without difficulty. That I haven’t seen it yet tells me I haven’t done nearly enough digging or messing with it to try it. It also means I haven’t been paid to develop anything in those languages — it’s generally money that drives my choice of platform and toolkit these days. The work that’s come my way thus far has all been PHP-related stuff. sigh

In my copious free time (heh, yeah right), I suppose I should dig into that a bit deeper, eh?

You never know how many friends you have until you rent a house on the beach.

Hey … I haven’t gone to the beach in quite awhile. Need to fix that