A year ago today, I started at Facebook. I’ve been using PHP for the last twelve years, and before I got there, I thought I had seen most PHP-related problems. I had deployed software on all manners of systems, but since I’ve worked at Facebook, my appreciation for how important PHP is has changed.
Earlier this year, another implementation of the PHP runtime emerged. This is nothing really new, as over the last few years, there had been several others — Quercus, Project Zero, Roadsend, and phc, to name a few. The main difference between them and HipHop for PHP is in the numbers. Nearly all of Facebook’s production traffic is served with HipHop. This consists of several million lines of code, worked on by several hundred engineers. Some run Apache and PHP; others run the HipHop interpreter.
One of the reasons for writing HipHop was to improve performance. The current Zend Engine is already pretty well optimized, and most changes result in a performance improvement of only a few percent. By building a code transformer, we were initially able to improve performance by 100 to 200 percent, and our current benchmarks show that in 2010, it’s improved an additional 200 percent.
This isn’t an article about HipHop and how awesome it is, though. What I’m trying to convey is our love affair with PHP. Take a look at the top hundred sites by traffic, size, or whatever other metric you fancy, and there is a high chance that they’re using PHP.
One of the main reasons I think PHP has become so popular is the critical mass that it acquired while it was growing up, but what was the original cause of that? It all comes down to its simplicity and the other options that were available at the time. Back then, your host offered Perl, ASP, or PHP. Of those, PHP was the simplest to learn, write, read, and debug. This made the barrier to entry much lower than the others.
It became easy to take a basic HTML web page, change the file extension, and sprinkle in a few lines of code from the documentation to make it dynamic. Now, there is no guarantee that it’s going to be good PHP, but the person who made the change was usually happy with the result.
Another reason PHP has become so popular is the documentation, which is second to none. It’s almost always up-to-date — and not just in English. Its central location, user comments, and easy search, among other things, make it the best resource for learning PHP. No books are required if you already know how to code. Before PHP, my background was Perl, and reading the manual was all I needed to make the switch.
One of the biggest reasons for PHP’s popularity is you, a member of the community. I recently discussed this with a friend, and we agreed that — especially compared to those surrounding other languages — PHP’s community is large, vibrant, and welcoming. There are dozens of user groups all over the world that meet on a monthly basis, along with larger conferences (and unconferences) that run throughout the year, all of which make it easy to be involved. One of my friends’ observations, while attending PHP London, was that someone who had just picked up the language that day was able to talk with a couple of contributors to the language core. Attendees at PHP-related events form a diverse group.
PHP is now in its teenage years, and the enterprise market is finally starting to warm up. Companies that wouldn’t normally have taken a second glance are now writing some large-scale systems with it. There are also a lot of companies built on providing consultation services, support, and training.
PHP’s growing pains are starting to show, though. For example, there isn’t a formal language specification — the current implementation itself is the specification, and it’s grown organically over the years. As things were needed, based on the trends of the Web, features were added. The last major version included closures, namespaces, and some other object-oriented goodies. The next version is going to include traits, scalar type hinting and some other languages changes. Developing modern PHP can be hard, but code written for PHP 4 — for the most part — still works.
There is also no single entity or foundation that is responsible for the direction or funding of development. The majority of PHP’s contributors are volunteers, doing so without any direct financial gain. The rest do so on behalf of their employers — Oracle, IBM, Microsoft, Yahoo, and Facebook, to name a few.
Contribute!
Just as using the language is easy, so is giving back. Most of the contributors don’t write a single bit of C, and know nothing about how the internal engine works. The simplest way to contribute is with documentation, and it doesn’t even need to be English — there are 32 languages represented in the manual, and 10 of those are nearly complete translations.
To get involved with documentation, the only thing you need to know is that the format used is DocBook. While it can be somewhat complex to understand, it does a good job of abstracting the actual documentation from the output format so the same source can produce the PDF, HTML and the Windows compiled formats. There is a live editor you can use anonymously to generate patches. There is also a wiki page that explains more.
The next team that could use your help is
PHP Quality Assurance. They take on the task
of writing tests for PHP to make sure things aren’t broken when changes are
made to the runtime. The implementation of the test format is extremely
simple. Various
sections are concatenated
together to produce a single phpt file that tests a particular
function or behavior.
--TEST--
Test that PHP can count
--FILE--
<?php
echo 1+1;
?>
--EXPECT--
2The test runner script will take the FILE section and run it
with the PHP binary specified in the TEST_PHP_EXECUTABLE
environment variable. The output of this will then be compared to the
EXPECT section to see if the test passed.
For more complex output, there is an EXPECTF section which
takes formatted output for things that may change, such as line numbers, dates
or directory paths. These are all
documented.
For the last three years, there has been an event called TestFest where someone presents to a user group on how to write tests and how to contribute back. We’ve had over a thousand tests contributed this way, although few continue to contribute after the event is over.
If writing tests or documentation sounds like too much work, then simply running a release candidate of the next version with your own test suite is helpful. If something starts failing, then report it. Regressions do happen from time to time.
Open source is ingrained in most tech companies, be it the operating system, web server, database, programming language, or some hot new framework, but it often isn’t a two-way street. Many people take without contributing back, and that’s fine — there are no expectations with most software licenses — but if your own project’s or company’s success depends on an open source project, can you really afford not to give back in some form?
A final thought
Take a few minutes and look at your technology stack. How directly tied to the success of a project are you? Can you open source something others might find useful in 2011?
