Home / The future of PHP ... at a distance

The future of PHP ... at a distance

First a short disclaimer: It’s been quite a few years since I have last been subscribed to the internals mailing list. I still hang out in one of the popular core developer IRC channels, follow quite a few core developers on twitter, and chat with people at conferences--which allows me to still keep up with things to some degree. I do of course still work daily with PHP. So for better or for worse this lets me see PHP's future at a bit of distance from core development.

The Future

To me it feels like PHP development has become much better structured thanks to the RFC process. In my humble opinion, the advantages of the RFC process boil down to providing a clearer path for new contributors to get their features in. It also enables non-core developers to more easily participate in testing and providing feedback as there is a minimal amount of documentation even before the feature makes it into a stable release. At the same time PHP traditionally only had lots of implicit unwritten processes; some of the longtime contributors also picked PHP as their pet project because of how it was managed, at least to some degree. Processes also bring their problems, like different points of view on what the processes actually say (for example what changes require a simple- and which require a 2/3-majority). Regardless, I think overall things have gotten a lot better.

But there is another thing starting to shake the tree: the growing relevance of alternative implementations of PHP. The one catching most of the headlines is Facebook's HHVM project, though there are also others like HippyVM (PyPy based). I have been critical of Facebook's initial efforts at trying to reimplement PHP; however they now no longer require a compilation step and since moving to a JIT based approach, the performance improvements are more significant. More importantly, Facebook is actively trying to enable anyone to run their chosen PHP framework on top of HHVM. They are even soliciting feedback from framework authors where they would like HHVM to go next in terms of language features. If you compare this to current PHP internals–where it seems to be a never ending battle between concerns with backwards compatibility and framework authors asking for new language features to enable easier development–its quite a considerable change. However, at least for now, HHVM does not support Windows, which is still one of the main platforms for PHP developers. The fact that Facebook is including its own syntax with HHVM and even a PHP-inspired language of its own called “Hack”, also worries me as it can lead to fragmentation of the community.

But there are other reasons to be worried. Do we really want Facebook to have final say in how the language evolves? I am not even sure if Facebook really wants this responsibility. Other scripting languages have already had to deal with this situation with various popular reimplementations of Ruby (JRuby, IronRuby) and Python (Jython, IronPython) having scooped up large parts of their user base. Facebook has hired quite a few PHP core developers over the years which at least means they are familiar with the PHP project internals and can ensure a higher level of trust between PHP internals and HHVM. Rasmus does seem to be sympathetic to HHVM and "competition is good" seems to be mentioned quite a lot from both sides. To me a key requirement for this all to make sense is for more non-Facebook employees to get involved in HHVM development. This would ensure that the project wouldn't blow up if for some reason Facebook loses interest. It would also help in making the internal decision process on HHVM more transparent.

A good step in the direction of transparency is that Facebook is now spearheading writing of a proper specification for the PHP language, which has been welcomed by the PHP core developer team. What is interesting here is that a few PHP oddities are being brought out into the open--results of oversights or simply just past optimizations that affect behavior. Facebook in several places chose to then define such behavior to be open to the implementor, freeing Facebook and anyone else from having to implement such questionable behavior. This of course may mean that code will not work as expected in different implementations, but at the least it makes potentially troublesome areas of behavior more transparent. In fact, HHVM has diverged from PHP core behavior in most of these places already, yet still lots of PHP projects already run fine on HHVM.

Note I am not focusing on HHVM performance here, which while quite stellar even for real world use, is not the main thing that excites me about it. After all PHP core has been improving performance of PHP considerably with every PHP release and the future looks to keep that “promise” thanks to PHPNG. While this should be good news, here we get back to the issues I still see in the RFC process. PHPNG was developed as an experiment by Zend behind closed doors; as it turned out to be quite successful at boosting performance, Zend is pushing to make their efforts the base for master, i.e. all future development. However many core developers note that there are still a lot of inconsistencies and a total lack of documentation. Moreover master hasn’t stood still while Zend has begun its efforts, so a lot of contributors that got their changes into master would then have to go through those efforts once more. These discussions on the core mailing list are showing the cracks that still exist in the RFC process. So I am more excited about how HHVM can help push the core developer team to a more transparent and end-user-community-oriented development process.

Speaking of the RFC process: a recent RFC resulted is the decision to skip PHP6 and go straight to PHP7 as the next major version. Personally I could have lived with the RFC going in either direction but its great that we finally have a voting system in place for this kind of stuff. So with that I would like to end this post on a positive note, PHP7 FTW!

PS: This is an updated version of a previous blog post of mine. I’ve shortened it a bit and updated it to reflect things that have happened since then.

Guest author dossier

  • Name: Lukas Kahwe Smith
  • Twitter: @lsmith
  • Website: http://pooteeweet.org
  • Work affiliation: Liip AG
  • Drupal/FOSS role: Liaison to the Symfony2 community
  • Current projects: Symfony CMF / PHPCR
  • When/which PHP you started with: “Some PHP4 beta in 1999”
  • About: Lukas makes regular appearances at conferences around the globe and has left an impression in various parts of the PHP community, not the least of which as co-release-manager for PHP 5.3 and launching wiki.php.net. He is also quite interested in database technology. When he is away from his keyboard he is usually playing at some ultimate frisbee tournament around the world.

Also in the Future of PHP series

  1. Future of PHP series landing page
  2. Perspectives on the future of PHP – "The Future of PHP" series intro, Jeffrey A. "jam" McGuire
  3. The future of PHP ... at a distance – Lukas Kahwe Smith
  4. Composer – Dependency Management in PHP – Lorna Mitchell
  5. The Future of PHP is Shared Power Tools – Ryan Weaver
  6. PHP is getting Faster – Richard Miller
  7. PSR-What? Shared Standards for a Bright Future – Lorna Mitchell
  8. Voices of the ElePHPant / Acquia Podcast Ultimate Showdown Part 1 & Part 2 - Acquia Podcast audio/video with Cal Evans and Jeffrey A. "jam" McGuire
  9. PHP: Under the Hood, Running the Web - Michelangelo van Dam
  10. A Symfony Shop Embraces Drupal 8 & Gets Down to Business - Acquia Podcast audio/video interview with Chris Jolly
  11. Building Bridges, Linking Islands - Larry Garfield
  12. Drupal & PHP: Linking Islands, the podcast – Part 1 & Part 2 - Acquia Podcast audio/video interview with Larry Garfield
  13. PHP: Getting the job done, really easily – Acquia Podcast audio/video interview with Stephan Hochdörfer
  14. Get more done, better & faster – together. – Acquia Podcast audio/video interview with Dustin Whittle
  15. New Wave PHP – Audio/video interview and conference session presentation with Lorna Jane Mitchell
  16. Writing secure PHP: "F.I.E.O." and more – Acquia Podcast audio/video interview with Chris Cornutt
  17. PHP: The entire world is your development team – Beth Tucker Long – Acquia Podcast audio/video interview

Image credit

future_paper.jpg image by Kristian Bjornard: https://www.flickr.com/photos/bjornmeansbear/723987842

License: https://creativecommons.org/licenses/by-sa/2.0/

Comments

Posted on by Sam P (not verified).

Honestly I don't care much about the version numbers but this will make up for an interesting interview question as well as us Php folks the butt of most jokes by other language developers. I wish they had kept a sequential numbering.

Add new comment

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.

Filtered HTML

  • Use [acphone_sales], [acphone_sales_text], [acphone_support], [acphone_international], [acphone_devcloud], [acphone_extra1] and [acphone_extra2] as placeholders for Acquia phone numbers. Add class "acquia-phones-link" to wrapper element to make number a link.
  • To post pieces of code, surround them with <code>...</code> tags. For PHP code, you can use <?php ... ?>, which will also colour it based on syntax.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Allowed HTML tags: <a> <em> <strong> <cite> <blockquote> <code> <ul> <ol> <li> <h4> <h5> <h2> <img>
  • Lines and paragraphs break automatically.
By submitting this form, you accept the Mollom privacy policy.