Neither developers nor the language are what's wrong with PHP

I recently wrote about how pointless and repetitive anti-PHP rants are, and I'd like to expand on that theme. When you strip away all the hyperbole that PHP detractors layer onto their discussion of the language, I'd say you're left with one reasonably uncontested fact and one popular claim:

1. Success (fact): PHP powers more websites than any other language, or at any rate has a much greater share than Python, Ruby, Clojure etc.
2. Failure (claim): PHP applications are on average less secure, or less robust, or less well architected, or less something than anything written in those languages.

Anti-PHP rants often focus on attacking the success, using the failure as a weapon. But to frame the discussion in this way is to reveal more about the frustration of the ranter - "how dare PHP be so successful?" - than about PHP itself: there's little scope, or desire, for pragmatic explanations of what I've previously called:

... the genuinely interesting phenomena: why is PHP (still) so popular? what adaptations for survival have arisen from, say, its pragmatism, its sloppiness or its decade-plus iterative design? why are the aspects of a language that opinion-formers focus on not the ones that contribute to its longevity?

On the other hand, pro-PHP ripostes try to dismiss the failure, by showing it to be a necessary consequence of the success. But this can end up as a metric war: who has the best numerical measures of something fuzzy like "insecurity", so that PHP can go head to head with... and so on. It's almost boring as the original anti-PHP rants. It gets us nowhere, but merely justifies our preconceptions.

Let's instead take both the success and failure as a given; I want to address them unflinchingly and without excuse, and see how we can move beyond them. What can we do to make any web application - whatever its technology, averaged across the internet - more likely to be secure, robust and well architected.

(Speaking of charm or lack thereof, at some points in the discussion below, especially if you're a PHP programmer like me, you might think that I'm insulting you, or your co-workers. I can only apologise in advance, not least because, well: sometimes I am, sort of; but really only hypothetically, if that makes you any less likely to hit me. I don't want you to think that, like an anti-PHP ranter, I'm disclaiming these insults purely so that I can make them! Rather, I set out with the fixed intent of not flattering PHP, in order to see where the discussion ends up.)

The long downward tail of charmless web applications

If instinct suggests there's a reasonable if fuzzy measure of a web applications fitness for purpose, encompassing all the ideas in the failure statement above, and if we're happy that the measure can be explained, if not always quantified so much as qualified, then as a shorthand we can refer to this as an application's charm. If you prefer quantization, think of it as some kind of weighted average of all the qualities desirable in an application; if you prefer gut feeling and discursive justification, then think of it an intuitive and noncontinuous measure: I'm happy not to argue the specifics.

On average, our failure statement claims that PHP web applications have on average less charm than what I'll refer to concisely as their Py/Ru/jure equivalents. But if we also accept that there's some great work going on in the higher tiers of PHP charm - in frameworks like CodeIgniter, Laravel and CakePHP, and larger hybrid framework-apps like Drupal and Wordpress - then this suggests that a long tail of charmlessness is dragging down the average. You don't have to accept that yourself, but you might want to talk to, say, some of the co-maintainers of Drupal core first, and at least get some idea of their combined expertise before dismissing it as not being of as high a standard as the the talent in the Py/Ru/jure communities.

So how come so many PHP applications lack charm? Is it really easier to, say, code a MySQL injection in PHP than in Py/Ru/jure? I'm not convinced that's the case: if you get as far as finding cgi.FieldStorage(), you can easily do as much damage as if you find out about $_GET. Is it easier to write maintainably in any given language? Well, there are structures inherent to all of these languages, that very much promote maintainability when used properly within a given language's idiom.

Perhaps PHP's idioms and influences of style can account for an application's charmlessness? Well, such idiomatic arguments are dangerously close to aesthetic ones; besides, I have little truck with even weak versions of Whorfianism, especially when it comes to a deliberate intellectual exercise like programming. When you're programming, your thought processes and ideas are being generated and moulded in a lexical level far above the programming language and its idioms; what you do and don't decide to program are only tangentially dictated by the language, and then mostly at the level of syntax. Besides, all of these languages - PHP included - have their frameworks, which help to redefine those idioms into something more robust and standardized like MVC; conversely, all of those frameworks are similarly as easy to avoid, if you're a poor enough developer...

In fact, let's take that last point, and run with it. Let's accept the worst - or at any rate least complimentary working hypothesis, yet again, and say outright that: along with attracting a similar share of charming programmers as Py/Ru/jure attracts, PHP also attracts more than its fair share of the talentless. There's my biggest insult, right there, and I ask you once again to refrain from hitting me for it....

Because: I'm definitely not saying that you're an idiot if you work in PHP - if I were, then I'd be an idiot with you - but that, compared to other languages, when talented PHP programmers look downwards into the vast community beneath them, compared to when other programmers look down, there's a much longer downward tail of the less talented beneath them, mirroring that same downward tail of charmless apps.

Community evolution and negative pressures

What does it mean, for a programming language to preferentially attract undertalented developers into its concomitant community? Edsger Dijkstra suggested that the teaching of BASIC "mutilates the mind beyond recovery", but I see no obvious equivalent effect in PHP. It has a C-like syntax, very similar to other languages; and whatever uncomplimentary things one might like to say about Java or Perl programmers, they're qualitatively different insults from those aimed at PHP, its apparently charmless applications and its allegedly undertalented practitioners.

Besides, any hypothesis that a language causes active damage to a programmer's prowess needs to be backed with proof: Jeff Atwood makes the important point that an entire generation grew up learning BASIC; where is the evidence of widespread retardation among these programmers, compared to the select few who avoided it? The point is that, unless anyone can turn their subjective dislike of curly brackets into reputable, objective studies, I'm happy to propose and (it's my blog, after all) accept that PHP's syntax is neither obviously preferential to a lack of talent, nor does it have a quality which makes its users somehow mentally degenerate.

Instead, I think there's a sense in which PHP's success - widespread and inclusive - is at the very same time its failure - quickly learned and nonselecting. Communities like PHP's can evolve in the same way as any other population evolves: individuals exhibit random traits; a particular environment translates those traits into a likelihood of longevity; over time, individuals or their descendants exhibit different traits, adapted to suit the environment. But if the environment is not particularly harsh, then very little selection occurs. Only a negative evolutionary pressure, a harsh environment, can if you like weed out a lack of developer talent.

In PHP, its community and its applications, therefore, we see demonstrated the results of having low barriers to entry. PHP is easy to pick up. It's easy to use. It's easy to find a web hosting company that will support it. It's easy, in fact, for a web hosting company to do so: it's an eminently hostable environment. Py/Ru/jure, on the other hand, must somehow deter a greater fraction of untalented developers. You could spend days arguing about why that's the case.

Is that good or bad, for PHP or for Py/Ru/jure? As with the other questions mentioned above, that can so easily turn into a solicitation of opinion and prejudice, I don't answer that here. But what's clear is that there is no straightforward mechanism for increasing the average developer talent in a language, because you would have to bolt a post-hoc barrier to entry onto an existing language; what would one even look like; how would it work; most ominously, what might its unintended consequences be? And you certainly can't improve the average standard of developer talent by trying to attract them to your preferred language: as a positive evolutionary pressure, that can only help to stir the population up a bit.

There's no escape. We must live with the likelihood that untalented developers can end up building charmless applications, and a (unfairly large) proportion of those will be PHP applications.

If you can't beat 'em, manage 'em

So what's the solution? If the PHP community really does contain more than its fair share of untalented developers (and I accept that only provisionally); if there's no obvious way of improving that, given PHP's low barriers to entry; if PHP developers are unlikely to be prevented from developing in PHP if they want to, if that's the first tool to hand, if that's the framework they know; then how do we improve the charm of the applications that do get released?

A simple question with a simple answer: after all, how do we ever do that? Management. Or, if you're worried that I'm talking about pointy-haired bosses, you can call it direction instead.

When we discuss the pro's and con's of a language, we so often focus on the language itself, and the manner in which its building blocks get turned into code by developers. If we discuss any kind of abstraction at all, then it tends to be a computer-science abstraction, like a hashing algorithm, functional programming, or MVC. But there's a sense in which code is just code; the mental effort of a programmer - like other, more prosaic powers - isn't particularly distinguished, except by the ways in which we contain it, channel it and direct its use; software management gives software development a purpose.

What are the ways in which a language, especially but not exclusively PHP, can benefit from managerial direction?

• People If PHP does have its fair share of bad programmers, we need to stop assuming PHP developers are roughly equivalent based on simplistic CV metrics. Companies and organizations need to have upskilling and training programmes. They should cultivate a love of programming for its own sake, an understanding of what constitutes well-written PHP, and - yes - an interest in other programming languages and their advantages.
• Process Any project should be run in ways which mitigate risk, which prize good development and the urge to deliver well-written software in a timely manner. Code should be reviewed regularly, and security and architecting made top priorities. By all means use Scrum, Kanban or Waterfall if you like; but if you do, then treat them with sufficient respect to make them robust, but not so much respect as to make them restricting: the processes must serve the project, not the other way around. Have processes which ship early and often, and which promote the successful completion of features and projects over egos and prejudices.
• Standards General, basic standards like HTML5, HTTP/REST and Unicode should not just be adopted but embraced. They should be scouted out when they're still in their infancy; and the act of discovering them and bringing them to the attention of others should be rewarded. The PHP community's leaders are already providing exciting, even heartwarming levels of direction through structures like the PHP Framework Interop Group, providing PHP with standards like the PHP Standard Recommendations. PHP developers should consider directing this process from within the community, at whatever level they find themselves; and this should be praised as much as (if not more) than good code. Code is silver, but docs are gold.

Of course, there are many more ways in which good management of software projects can help take advantage of the good aspects of the underlying technology and its practitioners, while mitigating the worse effects of the bad aspects.

Wait, you might complain, this has all become very fuzzy indeed by this point. And, yes, I'd agree that, we've now reached a level of abstraction high enough that it would be easy to lose track of our original complaints: specifically about PHP; specifically about the relative charmlessness of applications built in it.

To which I would reply: good. That's the whole point of what I am trying to say. Because, once you stop worrying about this problem at the level of syntax holy wars, what gradually becomes clearer is that the charmlessness of PHP applications is not an unavoidable consequence of the level of talent of PHP programmers. We only permit it to be so when we don't properly manage PHP software projects. When a PHP project is well managed, it can exhibit just as much developer charm as a project in any other language.

Summary, or tl;dr

If the source of bad web applications is bad programming practices, then whether or not PHP attracts more than its fair share of developers who indulge in those practices is not something we can straightforwardly control. In addition, talented developers should be encouraged to program in languages they're comfortable with. With all that in mind, the way that we improve programming in any language is by treating programming as an exercise which is given purpose, structure and charm by sound managerial direction, not by complaining about the specific technology used.