[Hidden-tech] The Future of PHP at a distance

[Bram Moreinis]

https://www.acquia.com/blog/future-php-distance

  * Name: Lukas Kahwe Smith
  * Twitter: @lsmith <http://twitter.com/lsmith>
  * Website: http://pooteeweet.org
  * Work affiliation: Liip AG <http://liip.ch>
  * Drupal/FOSS role: Liaison to the Symfony2 community
  * Current projects: Symfony CMF <http://cmf.symfony.com/> / PHPCR
    <http://phpcr.github.io/>
  * 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.

First a short disclaimer: It’s been quite a few years since I have last 
been subscribed to the internals mailing list 
<http://pooteeweet.org/blog/1753>. 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.

To me it feels like PHP development has become much better structured 
thanks to the RFC process <http://wiki.php.net/rfc>. 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 <http://hippyvm.com/> (PyPy based). I have been 
critical of Facebook's initial efforts at trying to reimplement PHP 
<http://pooteeweet.org/blog/1661>; 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 
<http://hhvm.com/blog/875/wow-hhvm-is-fast-too-bad-it-doesnt-run-my-code>. 
They are even soliciting feedback from framework authors 
<http://groups.google.com/forum/#%21msg/php-fig/iwMXyrruwvk/z_ZELhZBAU8J> 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 
<https://wiki.php.net/rfc/annotations> ending 
<https://wiki.php.net/rfc/propertygetsetsyntax-v1.2> battle 
<https://wiki.php.net/rfc/engine_exceptions> 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 
<https://www.acquia.com/%20http%3A//twitter.com/lsmith/status/496588130665771008>, 
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 
<http://www.infoworld.com/t/php-web/believe-the-hype-php-founder-backs-facebooks-hiphop-technology-231012> 
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 
<http://hhvm.com/blog/5723/announcing-a-specification-for-php>, 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 
<http://blog.circleci.com/critiquing-facebooks-new-php-spec/>, 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 
<http://blog.liip.ch/archive/2013/10/29/hhvm-and-symfony2.html>, 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 
<http://zsuraski.blogspot.ch/2014/07/benchmarking-phpng.html>. While 
this should be good news, here we get back to the issues I still see in 
the RFC process <http://twitter.com/derickr/status/499586842279542784>. 
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 <http://wiki.php.net/rfc/php6> 
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 
<http://pooteeweet.org/blog/2259>. I’ve shortened it a bit and updated 
it to reflect things that have happened since then.


-- 


      The Empowered Teacher

Bram Moreinis, Director
http://www.empowered-teacher.com
845-750-6204

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.hidden-tech.net/pipermail/hidden-discuss/attachments/20140911/d9065ff2/attachment.html