PHP revisited

I’ve been able to stay away from PHP-based projects for quite some time. Until recently. I needed a small API. The idea was that the API would be transferred to a relatively old server that had been running stable for years and the client didn’t want to risk installing additional script interpreters on it. It might even have been my own suggestion, it would be a really small API, requiring no special changes on an already operational 24x7 managed server. On top of it I’d write a modern style front-end, running entirely in the browser.

Of course the API that was intended to be simple got a bit more complex. I wanted the API to output clean JSON messages, which required some data mangling, as data was stored in CSV’s, TSV’s, and misused XML-files or only accessible through crappy soapy API’s. So what does present-day (well, the Red Hat PHP version I was able to use is still in 5.x-series) PHP look like? TL;DR: sometimes it was definitely ugly, but at I can happily live with the code.

Note that this isn’t a rebuttal comparable to the quality of for example this JavaScript review, I’ve never studied computer science properly. I’m pretty pragmatic and like things that work for me :) (ideally in both meanings of that sentence).

Intermezzo: WordPress

The last time I even touched PHP has been years ago. Not even a WordPress install, but coincidentally another client needed technical assistance with hosting a WordPress instance which was built by a design agency. I found out I’m still no fan of that CMS (from a developer’s perspective). While I haven’t dived into core WordPress, somehow the builder of the site managed to clutch together so many plug-ins and JavaScript libraries it turned into a mess that was known to me as Typical WordPress. WordPress is so much (ab)used by amateurs that to the professional much of what they see is such crap that they just want to stay away from it.

The curse of the amateurs

So many amateurs have used PHP to solve their problems in very often the ‘wrong’ way, it has given PHP a bad name. Since documentation is a community effort some of these bad practices trickled down in the documentation, which is still hosting comments on methods over 10 years old. Some of the bad patterns have been voted down. But they are there, and sometimes seem to solve, in a very bad way, a problem of an actual user. And since it solves a problem for one, it probably got copied and copied and copied.

Core PHP

Back to my own personal adventure in PHP. Goal was to keep it simple. And I could start from scratch. I decided: No framework, no dependencies, just plain PHP.

I really appreciate consistency and predictable naming in a language. PHP has a history. Some methods are old. Sometimes they are inconsistent with newer methods. Sometimes PHP is object oriented, other times it exposes more of a functional style (like ruby ;) this is no bad thing per se). Regular expressions in strings are ugly, and who decided that prefixing preg_-was a good naming convention?:

preg_match("/^P500/", $line_of_text)

But mapping and reducing arrays, works pretty good.

array_reduce(
    $bytes, function ($stream, $byte) {
        return $stream .= pack('C', $byte);
    }
);

Most functions in PHP are globally scoped, which has lead to a situation that seems to be hard to recover from: ugly naming and overlapping functionality, multiple XML processors and too many ways to do loops. But note that JavaScript has many of these same problems, something that may have to do with organic growth and a lack of obsession with language design (less applicable to JavaScript these days I’d say) and/or steady pressure on releasing new features.

Some examples

The subject typically comes at the end (which still feels weird, but I’ve seen it before):

• implode("", $array) joins an array of string with an empty string.
• implode($array) does the same

but if you’re using substr:

• string substr ( string $string , int $start [, int $length ] )

And while preg_match("/\d/", $string) indeed matches all digits in a string (“subject at the end”-rule), which returns 1 (and not true or the actual matches (why?)) when it found one (or more), 0 when none (not false or null (false is reserved for errors (from an era (<2004) in which exceptions didn’t exist)). To get the matches you pass another, empty variable, at the end, to fill it up.

unpack() returns an array; pack() takes an array? I like to be able to make such assumptions, but no. It takes one to many parameters. PHP has adopted the spread operator though, like in modern style javascript, to spread the elements in the array into the parameter-list. These kind of quirky choices bother me.

I can continue

• strpos, but many other functions called str_something
• str_replace takes search, replace, subject, but str_pad takes the input subject and then additional parameters.

The curse of the amateurs

When a field is clean, releasing a few strangers on the field typically leaves the field clean. An already littered field, on the other hand, seems to introduce neglect of all parties. That’s the curse of PHP. The main reason PHP has become so popular is that it was so simple to get started with. Most shared hosts have been offering the language by default for at least 20 years. The language was less advanced back then, and the rough field got inhabited quickly by an enthusiastic crowd. Littering. I strongly believe that a better designed language would have led to better programming practices.

Bottom line

You can write perfectly fine code in PHP. I typically approach languages I’m not overly familiar with ‘you should be able to do this, right?’ and try to find out (and if it doesn’t it seems I might have to learn a new paradigm :) ). PHP now can do most of these things that I want these days (objects, map/reduce, etc.). But it carries legacy. Legacy that might still confuse newbies in respect to the best way to use the language. Its ugly past still pops up in searches. Despite the good efforts on the side of PHP, though, it seems like PHP is decreasing in popularity. Will I take another PHP project. Nah, I try to focus on languages that make me happy and productive ;). But this wasn’t a PHP project from the start. Be pragmatic is one of my guiding principles. And this was pure pragmatism. I would happily take the same path again. PHP isn’t that bad.

Image is a snippet of the source code, which can be reviewed in full on Github