Fixing PHP: Perhaps more contributors is the solution

I had an alternate take on a point in this excellent post.

However, falling back on cavalier attitudes like the ones behind the statement “nothing is stopping you from contributing” is both insulting and counter-productive.

The alternate view is that lots and lots of things stop people from contributing to PHP: from a possibly daunting learning curve to lack of experience with a language engine to lack of C experience to the occasionally frosty nature of Internals.

It’s a pie-in-the-sky idea that will never happen, but if more of PHP was written in PHP, more people could contribute meaningfully; perhaps it would be easier to write tests, and fix problems.

Of course that potentially (if not probably) means re-writing the Zend Engine (think PyPy or Rubinius) and that’s just not going to happen, probably ever (for some unknown value of ‘ever’).


Burned down, fell over, THEN sank into the swamp

So, a very long time ago, I had to write a very small cart app as an adjunct/add-on to a customer’s full store. The idea was, they’re going to sell a very select subset of products and they don’t want to do a huge install and pay for lots of new hardware and software. Make it run – and well – on the couple of spare boxes.

I did it in Rails but the performance was awful. So, as a side-project while I was working on optimizations, I re-built it from off-the-shelf PHP parts, and it was blazing fast. I used the bare minimum of parts – a simple router, a simple ORM, and my own dispatch/controller (that was conceptually stolen from Rails).

Like I said, it was a bare minimum app. It didn’t do a TON of things. As customers are want to do, they came back and asked, “Where are all the other things? The things it needs to do?”

“It doesn’t do those things”, I replied. “It says right here in the contract, ‘we aren’t going to do those things’, those things are to come later.”

Well, they were going to think about it, since we were going to charge money for those things. I started a little “plugin” thing to bide my time while they thought about it.

They thought about it and decided they didn’t want to pay for those things. Project cancelled.

Time passed and I had reason to pull out the codebase again. “Hey”, I said, “let’s implement some of those things to make it more attractive”. Before I could get an answer, this project was cancelled.

More time passed, and I began a huge “refactoring” of our existing product. It started off by folding in some bits from the tiny app, but eventually it became clear it needed to use a real, unified “stack” since getting all these disparate pieces together was actually more fragile than the ball-of-mud approach. So I abandoned it, yet again, and used the functionality provided by the framework we chose.

I was looking for some other file when I came across it in a directory called “misc” in a directory called “prototypes and saved things” in my project folder. So I put it up on Github.

It’s incredibly boring: it’s just a little PHP thing to let you hook into a “controller” (say, an MVC type thing) and call a set of defined thingees in an order you want. It’s a really, really dumb pre-and-post-dispatch type deal.

The story is far more interesting than the code.

Quickie: Enabling network connections in Zend Server CE

PROTIP: Zend Server CE ships with MySQL’s skip-networking enabled. You probably want to turn that off, if you need to use something that doesn’t support domain sockets, like JDBC.

Their my.cnf is in /usr/local/zend/mysql/data (as opposed to some sort of /etc/ type deal). Just comment out skip-networking and restart MySQL and all is sweetness and light.

Friends don’t let friends create badly-informed presentations

Sometimes I find myself in a position of defending PHP and it makes me crazy. Look, I’m a Zend Certified Engineer whose day job is writing PHP, I’ve written probably millions of lines of PHP.

I wish PHP wasnt’ the best solution for our company.

But it is! Sure, I can make a series of cases for just about any language from Python to Scala, but I strongly believe that just about anyone with half a brain will agree that today PHP is the best choice for our application and our company.

So I’m in a position of simultaneously agreeing with rather a lot of anti-PHP positions and yet in a position to defend it, because so many criticisms are based on elitism (or “nerd prick waving” as I more commonly call it) or ignorance of what it’s like to work on PHP in a professional manner.

The source of my rage is this piece of shit, seemingly written as red meat for a nerd conference. Ok, fine. Still tweaked my own “I can’t believe people buy this shit” reflex.

It starts off innocently enough: by appending a specific PHP session ID to any PHP file that accepts a PHP session ID in the URL you get the PHP logo. It’s a lamentable “feature” that IIRC has been removed (or will be Real Soon Now). It’s a dumb, dumb idea that needs to go; professional tools don’t need cutesy easter eggs.

Moving on the preso quotes Rasmus on language design, some stuff he said about 10 years ago. Look, we get it: Rasmus isn’t a language designer in the way Larry Wall or Martin Ordersky is. His comments were slightly out of context, though. His point is that there’s a difference between academic and pragmatic approaches to software, not that “HAHAHA BUGS ARE TOTALLY OK”.

It then moves into the bog-standard whining about PHP – it’s got some dubious functionality, it’s got incredible inconsistency in function naming/arguments/etc.

I know that the uber-elite haxors do everything in in the standard editor and don’t need any sort of help ever, but out here in the real world, we have to keep lots of things in our head, so we use tools to help. Here’s what an incompent person like me does when faced with inconsistent function arguments:



Golly, it’s like the computer tells me what I need to type so I don’t have to care about inconsistent arguments.

I chose to use the wonderful PHPStorm IDE for that, but I get a similar effect in MacVim and BBEdit. I’m sure I can do it in Emacs, too. In fact I’m pretty sure in just about any editor worth using will help.

So shut up about this. It’s a solved problem. Unless you’re stupid, I guess.

Moving on, the authors complain about “misconfigured web servers” as a PHP problem because as everyone knows, using Django gives a magical ability to configure web servers.


Anyway it goes on like this for a while, as the authors “show their ass” as we say down home; those unfamilar with down-home Southern phrases can insert “show their incredible ignorance”. Eg, there’s “no real debugger” except for an expensive one and printing to the console; they don’t even mention the wonderful XDebug. I suppose it’s so “not real” it’s not worth mentioning? No “interactive console”? Well, yes, except for the half-a-dozen you can find on Github with no effort at all (I use phpsh, by Facebook of all people, but I’m sure it won’t meet the high standards of the authors of this preso. Even if it does use Python.).

I’m also curious about the statement “makes no difference of debug/production”, because I use that on multiple projects. I have deployed projects where to “take the site live” I change a single word. And in changing that single word it automagically knows to disable debug logging, it knows to use the production cache and not the file-local cache, and so on. Golly I must have fallen through some sort of wormhole into some alternate universe where I have the “good” version of PHP.

Near the end of the preso, these morons show their ignorance in 2 grand ways.

First, they are unable to distinguish between the model architecture of a framework and the primitive functions of the standard library. Just look at pages 29 and 30 of the preso: they seem to genuinely believe that the only way to query a database in PHP is to type $stmt->execute() all damn day, whereas in Python it’s just! One! Line!

Hey, dickheads: we have very powerful frameworks in PHP now. It’s just one line for me, too.


Oh, they try to talk about frameworks, and I guess there’s a language barrier, because they then try to claim that PHP frameworks are bad because PHP wasn’t developed with MVC in mind. Pop quiz, dickface: Python was? (I know some Python and I’ve read about its history and I’m going to go ahead and say, um, no, it wasn’t developed with MVC in mind.)

They even ask (page 31) “Why does this still feel like vanilla PHP?”. My god, the staggering ignorance here. Talk shit that Cake, Symfony, ZF and all the others are half-ass Rails clones all you want, but anyone who uses this stuff day in and day out, it isn’t “vanilla”.

But the crowning achievement of this is what’s the most offensive and amusingly ironic bit of the entire preso: glorious page 44.

“There are many good PHP developers available”

  • actually rather not the case
  • and even if it is: good developers?


You spend an entire presentation showing how little you know about the day-to-day use of PHP – you can’t even discriminate between a language and a framework, and your closer is to insult everyone?

Pure. Fucking. Genius. It’s too bad someone who knows a little about professional PHP development didn’t follow my advice: friends don’t let friends create badly-informed presentations.

Oh, and before I go: Facebook tried to switch to Python, twice, and gave up. They couldn’t scale it, they couldn’t create code fast enough. It turned out to be quicker to translate PHP to C++ than to covert to Python.

Eat a dick, ignorant Kraut morons.

Goto was a bad idea, though. I’ll give you that.

There’s a reason PHP “lives in the past”

One of the reasons PHP has a completely awful reputation is that a not-inconsequential number of its core users – people either with commit karma or enough pull to influence decisions on internals – revere backwards compatibility as the most holy thing.

Today in awful BC reverence and general WTF are you thinking? we have and the blog post, “The Plot to Kill PHP MySQL Extension“.

The summation part is pretty accurate, but then goes wildly off the rails in “The PHP 5 adoption fiasco all over again?”.

So what was wrong with PHP 5? Many details, but I think I can sum it up to not being 100.0% compatible with PHP 4. Nobody wants to change code that just works.

If by “just works” you mean any number of things – possibly host to SQL injection or XSS attacks, awkward or inefficient to maintain due to poor design, or unable to take advantage of useful features added to the language, sure.

In many cases, code that was running well in PHP 4, would still run well on PHP 5, except that it would probably throw many deprecated syntax notices that only seems to make it look like the code was wrong, despite there was nothing wrong about it.

Except there was something wrong with it: its features were deprecated. The exact why varies with feature to feature, but the bottom line is, these features are no longer desired in PHP and will be removed in the future without notice, or in general, however it used to work was wrong or bad or we just felt like changing it.


Simply put the core group is driven by consensus. There is no BDFL. Decisions are made by vote, generally based on RFCs and patches submitted to the group and stored on the wiki. Zend, “the PHP company”, has no special say in the direction of PHP (although Zeev and Andi have commit karma, as do several people who work for Zend in some capacity).

It is said that you can’t participate in Internals unless your shit-slinging arm is strong. This is true. It’s a blessing and a curse, like most open source communities. Discussions can get hot-headed and end up so far afield of what’s being discussed, the entire point is lost and it’s highly unlikely the feature/bug/whatever will get the attention it otherwise might merit. On the plus side, these arguments can sometimes produce a lot of interesting debate and thought about how people actually use software in the real world. One of the merits of PHP is it’s not driven by an academic’s desire for “purity” or a company’s desire to meet a checklist of features for sales sheets.

Yes, namespaces arrived way too late and closures are a half-ass implementation, but it more-or-less works as well as most other stuff out there, when used in a safe and sane manner.


So these features, marked as deprecated, somehow survived the shit-storm that is internals. Agree or disagree, the community came to a consensus: something is wrong, and here’s how we’re going to change it. They produced good enough code with few enough bugs, and it made it in.

The author then goes wildly off the rails:

PHP core developers wanted everybody to replace var class variable declarations with public declarations. You may ask: what was the point of that? In my opinion, none.

You’re high as a kite. Have an argument about the usefulness of visibility in methods and properties, but that’s the point.

The author then goes on to ramble about property visibility, and throws in one of my FAVORITE bugaboos from Internals:

It introduced theprivate and protected declarations, so the old var declarations should be replaced withpublic to be more consistent. Be more consistent with what? Java, I suppose. But PHP is not Java.

(Emphasis mine).

If I was in the mood to enter an Internals-like shit-slinging contest, I’d say something along the lines of, “Oh, blow it out your ass, I can name half a dozen OO languages with property and method visibility, you’re picking on Java because Java scares the peons”. Or something like that. Then I’d get banned from Internals for being a dick.

I don’t know why people on Internals (and elsewhere in the PHP community) through around Java as a hand grenade. Java has its problems – oh boy does Java have its problems – but, like PHP, the language, class libraries, the JVM, all that falls under the Java moniker, works well in lots of different ways to solve lots of different problems.

And to me, PHP is really a scripty, slightly insane servlet platform. The two share a lot of similarities, more than a lot of people are comfortable admitting.

Moving on:

So, is this PHP mysql extension deprecation really necessary. I don’t think so, but that is just my opinion. At most it will avoid the need to maintain the documentation of multiple extensions to access MySQL databases.

Yes, it has nothing to do with weaning a generation of fragile brains off the idea of

select * from foo where id=$_GET['thingee']

and using prepared statements (standard in PDO). Nope, none at all.

But wait, there’s more!

So, for the PHP developers that have old code to access MySQL databases this idea will not be beneficial at all. Once the deprecation becomes official, it will start annoying PHP developers that do not want to waste time rewriting code that always worked for many years.

It took me perhaps an hour in BBEdit to upgrade our old-ass PHP4 app to use MySQLi. PDO might take a little longer. In other words, cry me a fucking river.

So I am afraid the first PHP version that introduces this deprecation will suffer from the same adoption delay problems as PHP 5.

What, “OH NOES, I might have to change something!”?

PROTIP: using the fine PHPUnit code lets you test things. It’s really cool. But then again, it uses those scary objects and it’s strongly influenced by Java and its unit-testing practices, and as you said, PHP is not Java. So I guess good unit tests are a bad idea for PHP, too? Not using unit tests in my shop is a great way to get your ass fired.

I believe that conservatism with respect to software platforms is always a good, default stance. Don’t make changes for the changes sake, or because something happened to be fashionable enough to end up on Reddit and Hacker News. But this is a forward-thinking business and our job is to invent the future.

And for FUD’s/fuck’s sake, this discussion is not even about ending PHP’s support for MySQL as some people seem to think. We’re talking about ending the PHP4-era MySQL code in favor of the code the community has reached a consensus about as betterfasterstronger.

Engineer the future now. Yesterday’s for mice and gods. Knock it off with the BC holy writ. Get over it, PHP4 sucked.

The Last PHP Discussion Ever

(Subtitled, “from me, until I decide to have another one”)

I’ve always sort of had a love-hate relationship with PHP. I think a lot of people do. It’s a tremendously enabling platform – it ships on Linux and Mac OS X and has plenty of Windows support, it’s pretty easy to enable, and easy to pick up. On the other hand, it can be immensely frustrating: until version 5 it shipped with some of the most idiotic defaults and compared to other more traditional programming languages, it has some … rough edges.

Like my loud-mouthed tech types, I had written – over and over and over – The Definative Takedown of PHP. Epic in scope, so powerful and compelling Rasmus himself would give a tearful apology to the U.N. for unleashing this abomination on the world; Terry Chay would be so moved he’d devote the rest of his life to writing quines in Ruby.

Of course it was never perfect, and under constant revision, I never published it.

And, as much as I complain about PHP, I also began to outgrow hating on it. I came to a certain type of acceptance of PHP. In doing so, I realized all that frothing anger about inconsistent function arguments across the standard library was not the reason I was so annoyed at PHP all the time.

I finally pinned it down to one thing; one thing that summed up my annoyance with PHP, both in our enterprise and in the world at large. It is this:

PHP gets chosen “by default” because of its strengths, and its weaknesses are not only ignored, they are not accounted for in said choosing. By the time your devs and ops may be having issues, you may be in a position where weaknesses now outweigh strengths, but you’re too invested in PHP to reconsider. You chose it because “we’re a PHP shop”, not because you objectively weighed pros and cons.

And really, that’s it. That’s all. That’s my only real complaint about PHP.

I think the “state of the art” of PHP, as I write this, is generally worlds apart from what the bulk of the PHP community actually use as development practices (although I think this is changing).

In many ways it looks like PHP wants to occupy a kind of Java-esque place; it wants to be Java, but without the compilation step, and with a better deployment story, and without the complexity of things like JNI and RMI and all that stuff. And that’s great. There’s nothing at all wrong with that.

But it means that you (probably) need to employ some sort of of different practices. The hacky front-end your intern coded up is probably not going to be what you’ll want to base a product on; you may think he’s rapidly innovating now but the devil’s not just in the details, it’s support, maintenance, and ongoing development.

This is not to say that purely effective PHP means total object orientation, but it’s clear OO is the way to go. There will probably never be a day in which PHP is OO-only – the procedural functions will probably always remain – but the state of the art, and all the time and emphasis, seems to be pushing towards OO as the preferred way of writing PHP code of any size and complexity.

Likewise, you probably need to think about how to best write code like that. You’ll probably want unit testing. You’ll probably want to do some sort of continuous integration. You’ll probably want to make sure your source control is really working for you. You’ll want to explore the SPL and start thinking about creating Iterable classes instead of endlessly looping over array slices. You’ll want to use a framework. You’ll probably want MVC. You’ll want to seriously and with some rigor, constrain your use of the standard library. You’ll want to design for security.

It may be nothing like how you work today, and almost certainly isn’t how the intern whipped up the thing you think is awesome.

And not everyone needs all these development methodologies. Unit testing is a good idea, but the degree to which your enterprise does unit testing is probably entirely an internal decision. Not everyone favors a rigid source control system. But if you’re not doing any of them? Switching to Ruby won’t save you but let’s face it: you’re not exactly gaining anything by using PHP. ‘Agile’ is more than shitting out some code quickly.

PHP is not entirely suited to every possible task in the world. It does not excel at writing daemons, or perhaps doing high-performance computing. As an example, I wrote a script in PHP to do an import of some XML – over 35,000 individual XML files, each being read, parsed, and doing a large number of database operations. It took about 4.5 hours and used 110% CPU and a lot of memory. I rewrote it in another popular scripting language, and cut time own to under an hour and CPU usage to about 90%. In another case, we learned that a certain application had implemented its own crypto rather than make the user compile any extension. This meant in practical terms, it would only ever be but so fast; each page load did this crypto BS. Had it been done with the C extension it would have been orders of magnitude faster.

This is a knock against PHP only in the sense that we had to make the call: step outside the PHP garden, or accept its limitations. Some were upset at the idea of having to have this component not be written in PHP, but that’s back to my central point: you must accept that the most ideal PHP architectures are probably loosely coupled and front-end oriented.

I tweeted the other day that “canonical” PHP was actually shockingly productive. And I think it’s true. PHP gets a bad rap from a lot of people, because they expect things out of it that it never really promises.

Make a responsible choice. Be willing to openly discuss its downsides and things that are possibly wrong with it, especially if you’re a PHP shop used to working in the PHP4 paradigm or with PHP4 applications from an ops perspective. “It’s a web app and we know PHP” isn’t the end of the discussion.