A quick Twitter check shows that most tweets recently mentioning PHP-FIG have veered towards the less than impressed end of the spectrum, and I can’t blame those folk who are either disgusted at recent discussions or staking out marshmallows for when the flames rise up again. As I stated in a thread yesterday, I’m currently embarrassed by my association with the group. Whether people like it or not, the conduct of the group casts a shadow on all of its members, and I don’t want its dancing fires of madness reflecting on me.
The list is being overrun by emotionally charged language, derailed threads, personalised attacks, ad-hoc rule enforcement, one-upmanship, and a zero-compromise attitude when debating. In between these, real work is getting done. However, this gets a fraction of the attention, publicity and participation.
If folk want to contribute something useful, Lukas Kahwe Smith is proposing some security related standards (which may go forward as PSR-8 if/when an acceptance vote is organised). Matthew Weier O’Phinney and others are powering through the PSR-7 HTTP messages proposal. There’s other PSRs in progress too! PSR-6 for a caching interface and PSR-5 for a PHPDoc Standard.
The outcome of these “dramas” is to hide all of this good work behind a wall of horse manure. This crap also alienates potential contributors, discourages collaboration, and turns us into a laughing stock on social media. In fact, I’m feeling like I’ve heard something like this before…
There’s an ongoing joke between many people who follow PHP internals development (or used to follow) that it is a toxic kindergarten.
– Anthony Ferrara: http://blog.ircmaxell.com/2013/09/rambling-on-internals.html
Yes, it’s time to invoke Anthony “Sir Clarity” Ferrara. Run ye for yonder hills. Anthony makes a bunch of useful points that apply to PHP-FIG just as they do to PHP Internals so it’s well worth re-reading that article and ruminating on its contents. While closing that article, Anthony makes the most obvious point of all:
…unless people realize and talk about the problems, they can never be solved.
Going back on threads for the past few months, I’ve listed a set of “rules” that people have mentioned or, at least, never objected to. I would ask PHP-FIG members to a) read them, b) make comments if they want, c) suggest additions, d) consider a +1, and e) consider calling out people if they breach them.
Let’s start diverting some of this high energy effort into PSRs…
With HHVM 3.0 now released, it’s probably time to start talking about HHVM and the new Hack Language. It’s becoming hard to ignore some of the fantastical notions spreading on the grapevine about HHVM. There is talk of significant performance improvements, a multitude of new features courtesy of Hack, that PHP Internals is actually now outnumbered by HHVM contributors. There is even treasonous talk of PHP’s Zend Engine being put out to pasture.
Perhaps worse, HHVM 3.0 is following in 2.0’s steps: It is steadily eroding away at the notion that Facebook is going to abandon HHVM tomorrow (specifically at tea time once Mark has finished his crumpets) and it’s reinforcing the notion that Facebook actually wants people to adopt HHVM…as if running framework test suites and blogging about PHP parity every other day didn’t clue you in. Before 2.0, you’d swear the whole project was either top secret or had been disavowed.
This Was Inevitable…
PHP is not the only language to have faced multiple implementations. Ruby MRI (Matz’s Ruby Interpreter) is the “original” Ruby. It now puts up with JRuby, Rubinius, IronRuby, MagLev and MacRuby (where would we be without an Objective-C option, right?). Python is also not alone. It has alternatives (a lot of them) but you’d most likely recognise IronPython, PyPy, and Jython.
PHP is merely doing what it does best – creeping up on other languages and stealthily “borrowing” the best of their advantages. This time it’s not actually PHP doing the creeping, however, and beating PHP at the catchup game is a big deal. Just in case you haven’t heard – even HHVM is hardly the only option for PHP either. You can use Zephir to write PHP-like code which compiles to a PHP extension. Recently, I heard about HippyVM which appears to be in its infancy though those kids can grow up very fast (and it’s association with PyPy means it can’t be dismissed out of hand). There’s also the penultimate “opt-out” options for converting PHP out to Java, for example. The ultimate option being to just maintain the output and dump PHP altogether. Never overestimate your PHP code’s permanence ;).
I haven’t really discussed HHVM anywhere because the equation Facebook presented us with just didn’t add up for my particular circumstances. Now it does. HHVM is becoming ever more compelling as the weeks roll by. The PHP parity quest, the Hack Language, the shift to FastCGI and, most importantly, HHVM’s rapid improvement over time are creating something extremely attractive. Yes, it performs really well, but that’s not always the most relevant factor to programmers on the ground churning out everyday applications.
To PHP or not to PHP?
I’m seriously thinking about using the damn thing! This poses one small troubling question which keeps gnawing away at my poor brain: What is PHP?
PHP is a language without a specification to define all of its behaviour. It exists as one implementation that other alternatives must struggle to copy. It’s a hard slog, I have no doubt, and the fact that people undertake that slog is a testament to PHP’s place among programming languages. It’s also a serious problem. If the slog is hard enough, and it definitely must be without a specification, then the motivation is there to depart from PHP entirely. Which is exactly what is happening with the Hack Language. It is not PHP. And that PHP parity quest? That will not result in PHP either. Currently that is a problem, for now, until people get around to figuring out that something that’s almost PHP is actually good enough. It’s already good enough to write applications on using the most popular frameworks we have.
That one implementation of PHP is managed by PHP Internals, a group which (while I don’t want to tar all its members with the same brush!) is commonly described in terms that are not flattering.
The group has, at various times, been accused of being dysfunctional, disconnected from programmers on the ground, of being hostile and obnoxious, and has members who appear to vote against RFCs for no perceivable cause and do so frequently. In other words, the reputation of PHP-Internals doth suck eggs. Anthony Ferrara referred to it as “a toxic kindergarten” and Phil Sturgeon described it more poetically as “a cold, harsh, unwelcome land”.
I remember when Composer arrived. You may too. Here was this tool that installed stuff automatically from Github while resolving dependencies. It was revolutionary. It was so revolutionary, that I barely believed it was real because it was too much to hope for. Even as Composer took PHP by storm, there were still people stubbornly clinging to the notion that this upstart could not possibly replace PEAR. They were wrong. PEAR is dead. Some readers may still use it daily, some may even still be clinging to the final strands of hope that it will rise again, and I know it still releases code. I’ll amend my erroneous prognosis to “being in the grips of an irreversible terminal illness”. Better? I feel sorry for the PEAR group, and I am grateful for their years of work, but programmers never wanted PEAR. That was PEAR’s undoing – everything programmers knew at large about PEAR was not what they really wanted.
I wonder if PHP Internals has realized that they are facing the exact same problem?
Do I actually want to spend the next decade waiting for PHP to add Generics as a feature? No. Do I want to wait even 2 years for scalar typehinting? No. What about Collections? Surely I can wait 6 months and rely on SPL until then? No. Can’t I at least be reasonable and wait for PHP 6 to level the performance playing field? NO!
Bear in mind that HHVM+Hack doesn’t just add those. It has what I would consider years of PHP’s potential drip-fed headline features packed into just the existing version. The very first official version. What will get added in the next version? I don’t know, but I’m excited to find out.
Did Facebook Just Kill PHP?
PHP, as we know it, is starting to smell. It has gone from being the only PHP in town, to being the slowest, with the least number of features, and the one that’s subject to dysfunctional governance. The new PHP is called Hack, a new language with only the briefest of documentation since you can learn the other 99.9% of this language over on the PHP manual. The name is perfectly chosen. It’s exactly what it appears to be – a hacked version of the PHP language. Something that a population of programmers, perhaps irked by having to use PHP and impatient with PHP Internals, might put together by adding borrowed parts from Java and other programming languages.
The best is yet to come. What happens when PHP Internals decides to implement, say, Generics but with a syntax that differs from Hack? Will Facebook rewrite all the lines of Hack code and update its manual? I’m sure they will, in their imaginations, while laughing very loudly at the idea. They use <?hh instead of <?php for a reason. The whole language supports easy migration away from PHP (the original, the Zend Engine one, whatever we’re calling it now) – it’s not designed to allow migration from Hack back to PHP by giving up features. The value of any migration is, in this case, a one way street. That migration certainly has value. It obviously has value.
No, Hack is something else. It might spark a few arguments over not playing nice by copying PHP’s new syntax, but he who builds first doesn’t have any reason to go along with he who came late…
PHP isn’t really dead, of course. It will exist for years to come. Even I will likely still be using it in 2020. Without my crystal ball, I can only guess at the future. However, looking at HHVM+Hack and then at PHP, I am scratching my head trying to figure out how PHP can continue on its current trajectory. The HHVM guys are not stupid people – they took a language that is easy to learn, used by countless programmers, and simply made it faster and better. If you ignore Hack, they just made it faster. A lot faster.
Perhaps, I have a few neurons misfiring and I’ve arrived at the wrong conclusion due to their misbehaviour. I suppose that’s possible. Maybe.
I guess we’ll just have to wait and see how PHP Internals ends up evolving PHP to meet this new challenge. Just don’t take too long, people – I’m an impatient programmer and I like shiny new things that equate to cheaper hosting bills and improved source code.
- Building a Better PHP with HHVM and Hack: Part 1 (engineyard.com)
- Hack Isn’t PHP (marco.org)
- How will HHVM influence PHP? (shout.setfive.com)