All Unkept
Posted in: Python, PHP, Django  —  July 04, 2012 at 10:22 PM

PHP, Python and Persuasion

by Luke Plant

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”).

  1. 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.

  2. 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.

  3. 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.

  4. 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).

  5. Experience

    The vast majority of PHP developers that I've come across have not used any other serious web frameworks. That is why they can say things like “PHP is the best web platform... ever.”

    To make such a statement, you need to have in-depth knowledge of a large number of alternative web platforms — if not all the web platforms in existence. However, the author did not demonstrate any knowledge of any alternatives. You are never going to persuade anyone that way. Rather, it will lead people simply to dismiss your opinions entirely. Being ready to make pronouncements on subjects for which you clearly don't have a fraction of the required knowledge is a sign that nothing you say is trustworthy.

    However, the problem goes both ways. Eevee's rant, and Jeff's, both contain statements that are to some degree out of date (or appear out of date to someone on the other side who knows the 'standard solution' for the problems highlighted). The reason for this is obvious. If you feel passionately about how bad something is, you will stop using it, and your level of knowledge of the technology will go down. This does lead to a bit of a problem. Those who are unwilling to work with technology X because of how bad it is can always be dismissed as being ignorant of it.

    A facet of this problem is that it is extremely easy to underestimate something that you don't have knowledge of — for instance, you can simply underestimate the size of a competing community.

    I'll admit I was surprised to learn that PHP has a package manager with 1900 packages in its main repository. However, the author who pointed that out might be more surprised to know some of the following figures:

    Python:

    • PyPI has 20,000 packages
      • over 2,400 are Django related
      • over 2,000 are Plone related
      • over 800 are Zope3 related
      • over 800 are Zope2 related
      • over 130 are Turbogears related

    Perl:

    • CPAN has:
      • 107,764 Perl modules
      • 9,827 authors

    Let's add Haskell, as an example of a minority language if ever there was one, and not the first language you'd think of for building web sites:

    • Hackage has 5376 packages:
      • 350 in the 'Web' category
      • 55 for ‘Yesod’ (one web framework)

    I'm sure other languages can boast similar or much better figures. I don't even know where to look with Java — it's quite possibly so large that the idea of a central repository doesn't even make sense.

    PHP, despite having huge numbers of developers, looks rather small in comparison. Now, all of these statistics are flawed in a variety of ways, PHP's included, and the bigger a community is, the more they will be flawed — for example, PyPI download stats will often be way out because people are using mirrors etc — but this doesn't affect the point I'm making.

    The point is that all the communities are large, and these figures are just the tip of the iceberg in terms of how much is going on in each and every community. And from within a community, you can see some big figures and think “well I doubt anyone could seriously be competing with that!”. This is true no matter what community you belong to. And it makes it difficult to communicate in a meaningful way. Very few can honestly say that they've evaluated the alternatives in a fair way, because the alternatives are so huge.

Conclusion

I'm not sure I have a conclusion actually. These are just some of the pitfalls we face in communicating across different technology communities. I often forget these things, especially when communicating on the internet, and this post is here mainly to help me remember!

Because of the broad spectrum of PHP users, I do think that arguments against PHP are going to have to be more individual to be effective.

For example, suppose you have a customer that wants PHP for a website that deals with money in some way e.g. a shop. I might attempt to shock them by using phpsh to demonstrate PHP's inability to get some basic arithmetic questions correct. I would explain that all languages have problems with floating point arithmetic, which is why other languages have good solutions to this problem e.g. Python's decimal module, which makes it easy to get things right. PHP has nothing approaching this (and yes I know about BCMath and GNU Multiple Precision bindings). Rather, PHP's fundamental attitude is to 1) silently ignore errors, 2) attempt to paper over errors and 3) silently convert your data even if that means losing information. Is this the language you want to handle your data?

For a different situation, I think you'll need a completely different argument. And for many situations, don't even try if you think your words are going to come over as insulting, since that will be counter-productive. That often applies to the internet, and I need to remember that!

Comments §

blog comments powered by Disqus