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

Update

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

Leave a Reply to Drew Cancel reply

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