Looking beyond PHP

I saw this article the other day on HN, and it’s something I thought I’d blogged about, but apparently not. Unfortunately, Laurie has a point – although “PHP needs to die” is a bit of a strong statement. The more unfortunate truth is that PHP is dying. This has nothing to do with MVC frameworks taking over, and everything to do with positive evolution in language development coupled with the predictable weight of a large, 16 year old language.

What’s wrong with PHP?

If you’re new here, you should know that I’m a PHP guy. I know I’m an iPhone developer, and it’s not that Objective-C is a bad language, but I’ve been developing with PHP for over 9 years now, and having learned TI-Basic, Java, Python, Javascript, C, C#, Objective-C, and PHP, I’ll still pick PHP any day[1]. So, what’s the problem?

Laurie thinks PHP has become weak because it needs an MVC framework to do anything useful. This is patently false. I do lots of things without frameworks, although I’ve also written my own (as every good PHP dev does :) and found uses for that too. Frameworks organize and logically separate things that, in particular projects, need to be organized and separated. This isn’t the fault of the language, it’s a function of the project’s needs. And certainly, if you’re going to complain about PHP needing an MVC framework, do NOT go running to Ruby on Rails as your better language – He can’t even list the language without mentioning the (MVC) framework! Just because nobody uses the language without the framework does NOT make the framework part of the language.

So, what’s actually wrong with PHP? Mostly little things, but they add up. Death by a thousand cuts. These are the ones I can list in 5 minutes, although there are longer discussions for those interested:

  • Error Messages:
    There’s the infamous “unexpected T_PAAMAYIM_NEKUDOTAYIM”, which is hebrew for ::. Fine historic reasons. But then there’s the more mundane “unexpected T_ENCAPSED_AND_WHITESPACE”. What? According to this website, this means “you are missing curly braces around an associative array element inside a quoted string”. Or maybe “you’re using a reserved word someplace you shouldn’t”. What it tells me is, “Go stare at the line number we reported and see if you can spot the error yourself!” At least there’s some hope of improvement in 5.4
  • Nobody Upgrades:
    Nobody. Ever. 5.2 is deprecated, it contains known security vulnerabilities, but does that stop my webhost from running it? Not in the slightest. Will they ever upgrade? I’d like to know too.[2] How many webhosting companies even offer to run the latest version of PHP? Feel free to leave a comment if your host does. I fully expect no results. What can I as a user do about this? Get a VPS. And manage my own Apache, MySQL, ssh, and all these other things that I really don’t want to and REALLY shouldn’t be managing.
  • Type Hinting:
    So close. All we need is primitive support and type hinted return values. Oh, and type hinted class properties. Why is this such a big deal? Code completion. Seriously, the information it gives your IDE is just as valuable as the type checking itself. At least it’s under discussion.
  • Namespaces:
    You knew this was coming. I mean, yes, 5.3 added them, and we really, really needed them, but I have heard nothing but complaints about the syntax. Now, in fairness, I haven’t been using them, but then, I was scared off by people complaining about the syntax. That and nobody upgrades.
  • Lambda functions and closures:
    While 5.3 was a step forward here, they didn’t come up with the most elegant syntax…

    array_map(function($arg) using ($global) { return $global[$arg]; }, $arr);

    Compare this with python, who brought lambdas to everyone’s attention. Note, however, that PHP supports multi-expression lambdas, where python does not.

    map(lambda arg: global[arg], arr)
  • Array access from method calls:
    It’s really unfortunate that a language who’s core data structure is associative arrays doesn’t play nicely with function calls:

    function foo() {
        return array("bar"=>2, "baz"=>3);
    print foo()["bar"]; //Parse error: syntax error, unexpected '['

    And it’s not because we haven’t asked.

  • Properties:
    Oh wait, what properties? These properties.

The common thread here is that PHP’s syntax is affecting the readability, expressiveness, and quality of my code. It’s not so much that PHP is a bad language as that I’ve been spoiled by the concisely expressive syntax of Python, Javascript, and even C#. For all these languages’ faults, they’ve led me to expect more from language syntax, and syntax cruft is something any large community with mountains of legacy code is going to have trouble resolving.

What are the alternatives?

Now unfortunately, Laurie’s analysis of the (web) language market is quite accurate. Ruby on Rails is the obvious choice, but it’s slow, the documentation is worse than python much less PHP, and you’d better like Rails, because they’re driving the whole ship. And then there’s python, but django never did take off. Python’s really more of a PERL replacement anyway, in the quick and dirty CLI tool sense. And I hope so badly that Node.js really is a passing tangent, because JS is such a crappy language. Just ask Google. So that leaves us with… … yeah. That’s about right.

So what’s next?

Well, let me start by explaining why I believe PHP is amazing:

  • Documentation:
    Seriously the best OSS documentation around, and better than many commercial docs I’ve used.
  • Library support:
    Naming conventions and parameter ordering aside, the number of libraries PHP ships with is incredible.
  • Builtins are fast:
    The interpreter could probably use a little work, but the language is implemented in C, and it’s fast.
  • Low-level Extensibility:
    Magic methods allowing you to add properties, the ArrayAccess, Countable, and Iterator interfaces, which allowed me to create a 1D associative array that supports duplicate values for a key (implemented as a 2D array, but can be passed to library functions expecting 1D arrays!), and many other ways to hack PHP’s default behavior.
  • Dynamic typing + autocasting:
    Yes, like all abstractions it can bite you, but it allows me to (generally) write more expressive and readable code in less space.

And I could go on and on about variable variables, “break #” syntax, type hinting, $this:: support, and all the other little things I love about PHP, but you’ll notice that the bullet points here aren’t particular to PHP per-se, they’re general qualifications of any good web language. If you’re going to replace PHP, if it’s a language I’m going to use, you need at minimum those first three, and I need a compelling reason why you don’t think I need them all.

“I await the Next Big Thing. I want to switch away from PHP, I really do. I don’t want to be the Perl dinosaur. But whatever it is, it doesn’t seem to be here yet. Am I wrong?”
Laurie Voss


While his focus is a little different, and I doubt it takes off, it seems we’re not the only ones who thinks PHP needs a reboot.

Update Again

This guy does a fantastic job of explaining how PHP arrived where it is and where it’s going from here. And fortunately, the summary is that we’re emerging from a dark tunnel into better days :)

[1] Well, any day you want a web app without complex real-time user interaction. Which is most of my apps when I’m not at work.
[2]This isn’t a rant against my hosting provider at all – I like Arvixe – I’m just really tired of running 5.2.16, which isn’t even the latest in the 5.2.x series!

About Bion

I'm a software developer at Modo Payments, a mobile payment provider. When I'm not hacking away the office, you I'm usually at home hacking on something else. Or practicing Aikido. Anyway, I just post things here that Google couldn't help me with, so maybe it'll help you in the future. Since you're reading this, I guess it worked :)
This entry was posted in Technology and tagged , . Bookmark the permalink.

One Response to Looking beyond PHP

  1. Drew says:

    > How many webhosting companies even offer to run the latest version of PHP?

    For what language is this true? I am not aware of a single instance in which any hosting provider or even OS keeps pace with any language. Forget about the Python 3.x vs 2.x wars. Debian is running four-year-old Python. Lion ships with year-old Python. The situation is even worse than PHP, because Python is used like bash on many OSes, meaning that you can’t upgrade system python without breaking the system, so everybody installs their own Python for every application. It’s a mess.

    Meanwhile the Ruby landscape is so bad that everyone is having their own little holy war about the best package manager to manage all your installed versions of Ruby.

    Really you’ve been spoiled by iOS. It’s the only platform I’m aware of where people (and by people I mean users) actually upgrade in a reasonable timeframe.

    All the things you’ve listed as wrong with PHP are the symptoms, not the disease. PHP is like an old person with cancer. Yes, the fact that the person is bedridden and needs chemotherapy and has trouble getting around town and can’t use an iPad is a problem. But the _real_ problem is that they are just *OLD*. PHP grew up in a time BEFORE CSS. Ponder what the web was like before CSS. PHP grew up in a different era that had a different set of problems, and no amount of slapping some lambda syntax on there is going to get rid of the baggage of the problems it was built to solve for a fifteen-year-old web. This was back before anyone really needed a framework to get anything done, so while the web changed around it, the community never settled on One True Way to write modern applications, so every little PHP library has a little bit of its own framework built in, and lots of developer hours are spent trying to drag the old man kicking and screaming into the AJAX world.

    Python is the 40-year-old in this story. Stable family, kids, and a mortgage to support. It’s a productive language, but it’s worried about it’s future, so Python 3.x is the mid-life crisis, the “am I really still relevant?” moment. The big web explosion happened during Python’s prime, so Python was able to adapt to a frameworks-driven world, with language-level WSGI support and a good standard library, but it was just a little bit of a hack. Django is the One True Way, but there are some other ways, since frameworks happened a little further in the lifecycle.

    Ruby is the rebellious teenager, filled with angst for its parents. The web explosion happened before Ruby really came to prominence, so it was able to benefit from growing up in a web 2.0 world and being able to tackle all the modern problems without the baggage. The trouble with Ruby is it hasn’t decided what it wants to be when it grows up yet, so it’s quite rough around the edges in terms of documentation, stability, and support. But it will get there eventually, it’s just going through a weird phase.

    Then you have the Haskells and Gos of the world, the prodigy children that have a lot of promise, but it will take some time to see if they are really viable replacements, let alone to grow them up into such replacements. They bring a lot of weird ideas to the world, some of which will pan out, and some of which won’t.

    All of this to say, the real difference between the languages is “age”, and by “age” I mean more of a spiritual age than a date of invention (Lisp, for instance, is a very young language). You are not going to get a language with PHP’s documentation and support that also has nice lambdas and monkey patching, because a young language and an old language are mutually exclusive.

    Probably the strongest replacement for you, if you are willing to lose a little stability and gain a little modernity, is Python. Another strong candidate would be C#, which is technically newer than Ruby but because of all the MSDN baggage is spiritually closer to Python in terms of expressivity and stability. Then you have the weird hybrids. Clojure is a shockingly-modern language that has a very old VM. Scala is another option. F# is a third old-new hybrid.

    The point of all of this is to say that you’re not going to fundamentally affect the spiritual age of a language by piling on some new features (look at C++0x). Even Python knows this, that’s why they’re trying the reboot, even though there’s the very real possibility it will kill them.

Leave a Reply to Drew Cancel reply

Your email address will not be published. Required fields are marked *