I always find it fascinating to observe conversations in which people’s arguments fail to convince each other. A few days ago we witnessed some PHP debates, kicked off by Jeff Attwood.

I foolishly got slightly involved on one ‘rebuttal’. At church last Sunday I also chatted with a friend who has used PHP and likes it, and this time I tried to put myself in his shoes. It is often much more helpful talking to people in the flesh, and I think it is always enlightening to look at why we fail to convince.

One reason we can’t rule out is simple irrationality. All of us are vulnerable to confirmation bias, and people will often go to great lengths to convince themselves that they are doing the right thing and do not need to change their views or practices. You see this all the time when two groups of people share experiences after having made different decisions about how to spend some leisure time. Both groups are often desperate to believe that they haven’t missed out, and will seek to persuade each other (but in reality, persuade themselves) that they were in the group that had the most fun.

However, just assuming the other person is being irrational doesn’t really help you, and can in fact hinder communication. Below I will attempt to be more constructive in looking at the ways we can fail to convince people. I’ll try not to turn it into a rebuttal to the “PHP isn’t so bad” posts!

In his great rant PHP: a fractal of bad design, ‘Eevee’ has lots of great arguments against PHP, and there were others in different posts. But there are reasons why some will fail to hit home. (This is not a criticism, by the way — many of these problems are unavoidable if you are addressing an audience as mixed as “all the PHP developers in the world”).

Expert understanding. Eevee writes: empty($var) is so extremely not-a-function that anything but a variable, e.g. empty($var || $var2), is a parse error. Why on Earth does the parser need to know about empty? To an experienced programmer, empty() is rather surprising. If you know — or at least have some idea — about how to implement a programming language, you’ll understand terminology like lexer, parser, interpreter etc. So when you try empty($var || $var2) , and it returns a parse error, even though it looks like a function, you think “this programming language must have been designed by complete amateurs — I don’t want anything to do with it”. [ EDIT: changed this paragraph, previously I was getting mixed up between isset() and empty() ] For a less experienced or able programmer, however, none of this is a problem. Programming languages are entirely magic, and one type of magic is no more surprising than another. Talking about what the parser is doing is completely incomprehensible to such a developer. You cannot communicate the reaction you feel, because it requires a deeper level of understanding of how things are supposed to work. Less able or experienced developers are simply unable to assess the quality of the tools they work with.

Craftsmanship For many coders, the only thing that matters is whether PHP allows them to get something done. The quality of the tools or materials being used does not matter. Not only are many coders unable to assess the quality of the tools they using, they wouldn’t care even if they could, because programming is simply about getting something done. Any thought of taking pride in your work is absent. Such a person will never be convinced by arguments that talk about the quality of tools.

Amateur vs professional Eevee accused the PHP world of being created by and filled with amateurs. I suspect that to many PHP developers, that has the same effect as Java people saying to Pythonistas that Python is not ‘enterprise ready’. Many Python developers don’t care about “the Enterprise” in the first place, and the word may even have negative connotations — associations of massively over-engineered and poorly written bloatware written in Java or C#, which could be replaced by a Python project 10 times smaller. Many PHP users simply do not aspire to be professional, because they are happy to be called amateurs — they are amateurs, doing stuff just for fun, pure hobbyists who are not making money out of what they are doing, nor relying on PHP to behave in a sane manner with important data. PHP has brought joy to their life. Does it matter to them that PHP doesn’t live up to some standard they don’t need? Many developers simply do not care that much about the data that goes through their website. “So what if PHP doesn’t have any decent way of handling decimal values? It’s close enough for my needs.” For these people not only is the quality of the tool unimportant, the quality of the result is of little consequence. No-one will die or sue them even if it has major bugs. Also, professionals often have (or feel) obligations to support the code they write, whereas amateurs do not. Therefore amateurs will always trade long-term maintainability for initial deployment speed.

Defending your day job The previous argument doesn’t cover a lot of users, however. Many are using PHP ‘professionally’, and even have customers who may demand that work is done with PHP. (It is perhaps the essential problem of PHP that a language that was designed to be a simple template language for non-programmers has turned into the work-horse of the web, and the network effects caused by adoption amongst amateurs have made it a language for professionals.) Now, most people want to feel good about the work they are doing. And most people are not in a position to have much influence on whether or not they use PHP. If you tell someone “the tool you are using is Bad For The World”, they will get defensive, even if they would rather be using something else. I’m extremely fortunate in the work I do that I get to choose my projects carefully, and then charge a high rate for work that I can take real pride in. It’s actually fairly unkind of me to berate people for using a language that they didn’t really choose — even if they think they are choosing it and will defend it to the death. They are only doing so because the alternative is to say “yes it sucks, and yes I’m doing the world a disservice by continuing to promote it, but it pays the bills”. I’ve occasionally been in a similar situation in the past, and know how demoralising and depressing it is, and it is more comforting to rationalise your current situation. In fact, when I was last in a situation like this, I did come up with a whole bunch of rationalisations, which I still think are valid to some degree. Engineers must be pragmatists at some level. You’re paid to achieve things, not for the internal beauty of your code.

I should take pride in customer satisfaction, because that is what matters.

The language itself is not the only factor. You also must consider: development tools the availability and quality of libraries documentation and support for such libraries availability of people to maintain the software in the future. All of these things depend on human factors and network effects, and can be used to justify a choice on the basis that “lots of other people are choosing this”.

(If you are a “PHP developer” reading this, I apologise for being patronising — this post is not meant to insult, and is not aimed at you but at others).