It is with great pleasure that I announce the second edition of the Functional Programming in PHP book that I have been working on. There is twice the content of the first edition of the book as well as updates for PHP 7 and Facebook’s HHVM (HipHop Virtual Machine). There are now more functional techniques and patterns included with pipelines, pattern matching and flat maps among them. I have added a section of the book dedicated to the handy syntax and functionality that HHVM can provide functional programmers with.

It is with great pleasure that I announce the second edition of the Functional Programming in PHP book that I have been working on. There is twice the content of the first edition of the book as well as updates for PHP 7 and Facebook’s HHVM (HipHop Virtual Machine).

There are now more functional techniques and patterns included with pipelines, pattern matching and flat maps among them. I have added a section of the book dedicated to the handy syntax and functionality that HHVM can provide functional programmers with.

In addition I have, of course, listened to reader feedback and gone into a lot more detail about functions themselves, type signatures and their use, functional programming history and provided more examples of functional code in use. There is also a glossary of terms and appendices on libraries, REPLs and the frequently requested guide to using the UTF-8 ellipsis effectively in various editors.

On top of all that the book has been completely reorganised into a more logical structure with a better chapter breakdown.

So if you’re the kind of programmer who likes clean and easy to test code resulting in less bugs this is the PHP book for you. Even if functional programming isn’t really your thing all the techniques in the book will help you to become a better object oriented or procedural programmer.

To get your copy head on over to the books website for purchase links.

Chaos in the old world! First HipHop, years ago, and no one bats an eye. Then suddenly, HHVM happens, introduces Hack, and all hell breaks loose - Facebook made a new PHP and broke/fixed everything (depending on who you ask). Furthermore, Zephir spawns and threatens with C-level compilation of all your PHP code, with full support for current PHP extensions. It's mushroom growth time for alternative PHP runtimes, and HippyVM appears as well.

Amid the sea of changes, another splash was heard: PHPNG.

As introduced by Manuel Lemos, PHPNG is a new branch of PHP coming to a yet undetermined future version of PHP.

Wait, what?

This somewhat cheesily named (NG = new generation) and clumsily presented version of PHP is the core team's attempt to rival part of what HHVM and Zephir have been doing - improving PHP's performance to levels no other language can catch up with.

Like Manuel says, it was presented by Dmitry Stogov in an internals newsgroup thread. Dmitry is responsible for performance and optimization at Zend, and mostly deals with the Zend Engine. The NG upgrade focuses on rewriting core parts of the Zend Engine to enable better memory allocation on PHP's data types, and on adding JIT compilation similar to HHVM which lets PHP be compiled down to C on execution, improving speed of subsequent runs of the same code.

As with any "Make PHP better" attempt, this one has its pros and cons.

Pros

Continue reading %PHP Fights HHVM and Zephir with PHPNG%

Yesterday I gave a talk about HHVM and Hack at the monthly webtuesday here in Zurich. The slides can be found here

It was a great evening, thanks to Netcetera for hosting it, thanks to Joel and the webtuesday crew for organizing it and also thanks to Johannes for chiming in when we talked about PHP internals.

If you have any question abut HHVM or related things, just ask in the comments, contact me on twitter or meet me personally, if you're nearby (aka in Switzerland).

Yesterday I gave a talk about HHVM and Hack at the monthly webtuesday here in Zurich. The slides can be found here

It was a great evening, thanks to Netcetera for hosting it, thanks to Joel and the webtuesday crew for organizing it and also thanks to Johannes for chiming in when we talked about PHP internals.

If you have any question abut HHVM or related things, just ask in the comments, contact me on twitter or meet me personally, if you’re nearby (aka in Switzerland).

Yesterday I gave a talk about HHVM and Hack at the monthly webtuesday here in Zurich. The slides can be found here

It was a great evening, thanks to Netcetera for hosting it, thanks to Joel and the webtuesday crew for organizing it and also thanks to Johannes for chiming in when we talked about PHP internals.

If you have any question abut HHVM or related things, just ask in the comments, contact me on twitter or meet me personally, if you’re nearby (aka in Switzerland).

Since its inception the slow running speed of PHP has been widely publicised and over the years there have been a number of improvements. The first Zend Engine arrived with PHP4 and delivered various performance enhancements (among other features). Each release since this time has delivered some sort of increased efficiency in one way or another.

It has become more interesting recently however with three projects looking for improvements in different ways. The core has adopted the Zend OPcache for future versions of PHP, Facebook has been working on a just in time compiler called HipHop VM and the team that brought us Phalcon framework have created Zephir.

All of these projects have chosen to tackle the issue of PHP’s speed via different avenues. It has therefore left one simple question - who’s making the biggest improvements? Who’s the fastest?

With this question in my mind I decided to do something quite ridiculous and write a simple benchmarking setup to test the various ways these projects can be employed. Yes, there is one outright winner in this particular benchmark, but it is important not to get hung up on that.

Like I mentioned all of these techniques are different and therefore they are likely to be a better fit for differing situations. Although winning in terms of outright speed in this particular test it may not work for you from another perspective. Each carries with it certain side effects or caveats that you’ll need to take into consideration.

You should take all factors into consideration and additionally bear in mind that all benchmarks are flawed. The only way to truly test it out is to use real algorithms in a production environment. By using this benchmark code I am focusing on one particular and simplified problem.

Of course, as in this case, it is not always reasonably possible to port a sufficiently complex and realistic problem to all benchmark targets. So it is typical to pick a trivial, but computationally intense problem that can easily be implemented in all of the benchmark subjects.

Now that I have addressed some of the fundamental assumptions of benchmarks; let’s meet the contenders!

The contenders

HHVM

We’ll begin by introducing Facebook’s PHP runtime, which has been receiving a lot of attention recently. The project is interchangeably known as HHVM, HipHop VM and less frequently HipHop Virtual Machine.

Facebook originally created HipHop VM to replace HPHPc which was their PHP to C++ compiler. They also sought to speed up their application infrastructure through the use of just in time compilation. More recently they have put a lot of effort into improving compatibility with existing PHP libraries (including Idiorm and Paris).

This means that it is now possible to run many PHP applications directly on HHVM and take advantage of its JIT (just in time compiler) to increase the speed of code. There are still some rough edges and some aspects that will not work, but there are regular commits on the project from the core team. It would seem that eventually HHVM will become fully compatible parallel runtime for PHP code.

PHP 5.5 and OPcache

PHP and Zend have also been busy trying to make PHP faster and with the advent of OPcache they have shaved between 10% to 20% off of PHP processes. It is a modern replacement for the bytecode cache features of the APC PECL extension. Unlike APC it doesn’t have the userland memory key/value store and it is entirely focused on the caching and optimisation of PHP code.

I am not au fait with the techniques that these caches use, but reading through the available documentation I found the following high level explanation. Zend OPcache offers increased “performance by storing precompiled bytecode in shared memory” to reduce reads from disk. Additionally it will apply a number of “bytecode optimization patterns” to the code decreasing execution times.

Zephir

In a separate effort and taking a different direction the team behind the Phalcon framework for PHP have been working on Zephir. Phalcon is a web application framework written in C and bound as a PHP extension with the aim of being the fastest framework for PHP. It is worth mentioning here that Phalcon certainly is not the first to take this approach with

Truncated by Planet PHP, read more at the original (another 11132 bytes)

This entry is part 1 of 2 in the series HHVM and HackFacebook started to work on HipHop for PHP in 2008. Their goal was to speed up the PHP execution speed and the first version of the project was composed of the tandem HPHPc/HPHPi. HPHPc is a PHP to C++ transpiler which was used […]

Continue reading %HHVM and Hack – Can We Expect Them to Replace PHP?%

Its been quite a few years since I have been last subscribed to the internals mailing list. I still hang out in one of the popular core dev IRC channels, follow quite a few on twitter. So I still manage to stay on top of what is happening more or less but not the details in the discussions. Just wanted to put this as a disclaimer. Any opinions in this blog post are opinions formed watching something at a distance and this always runs the risk of being quite wrong or more impartial.

To me it feels like PHP development has become much better structured. It also feels like the RFC process has enabled an influx of new contributors that previously simply didn't know how to get their stuff in. There were a bunch of old devs opposed to adding this documented "processes", saying that "open source is about fun and processes kill the fun". But to me that was always shining through that argument was that there is always an implicit process and that process is usually ideal for the current people "in power". As such, there is nothing wrong with that, since if the current people can handle the load, why bother trying to please a theoretical new contributor? But while several core contributors, like Rasmus, Derick and Ilia, have sustained pretty significant levels of contributions, many others have drastically reduced their contributions. More over as the feature scope increases it makes a lot of sense to also grow the number of maintainers. However I guess the really active core group of contributors in most open source project I know tends to hover around 10-20. The beauty of clearer processes is that it can also help in clearer delegation, which can lead to subgroups within an open source organization that again have an inner circle of 10-20 really active people. Now from all I hear "discussions" on the internal mailing list still have a tendency to generate lots of less than helpful traffic.

But everything could be turned up side down in the near future. I have been critical of Facebook's initial efforts at trying to reimplement PHP. A change of direction towards a JIT without a code compilation requirement however have made their efforts significantly more viable. More importantly Facebook is now actively trying to enable anyone to run their chosen PHP framework on top of HHVM. They are even actively 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 mostly the older developers concerned with backwards compatibility, no doubt one of the reasons why PHP has been able to catch 80% of the internet, and framework authors asking for new language features to enable easier development. Make no mistake adopting Facebook specific syntax in frameworks will of course make that code incompatible with PHP itself. Some of this could be "fixed" by a "compiler" that transforms HHVM specific features to normal PHP code, but that would be probably more sad than ironic. Also what about windows users, still a very significant portion of the PHP user base?

None the less the proposition seems tasty when wearing my framework hat. But while this is exciting, its at least as much troubling to me. 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. I guess 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. Then again I assume these reimplementations have actually also helped grow or at least sustain their use bases. Facebook has hired quite a few of previous PHP core developers though I am not entirely sure how involved they are in HHVM development. But at the very least it could ensure that there is a bit of a trust relationship between PHP internals and HHVM, which is of course quite important in the open source world. Rasmus also seems to be sympathetic to HHVM. 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 en

Truncated by Planet PHP, read more at the original (another 2177 bytes)

This weekend I had the opportunity to attend and speak at Symfony Camp UA in Kiev. This event was organized already for the 5th time and draws many developers from the region. While I did spend the entire week before doing an intensive Russian course in Odessa (just for fun, no Liip has no plans to open an office in Russia), I did my talk on REST in English. Next to mine the only other talk in English was delivered by Pawel, who spoke about Sylius. It was great to finally meet Pawel in person! At any rate all other talks were in Russian. It was semi possible to follow the Russian talks if the slides contained enough code but in the end I spend most of the time talking to people sitting on the comfy chairs in front of the conference room. There were two questions that came up multiple times, so I figure I also answer them quickly here.

DELETE and 404

I started my talk on RESTing with Symfony2 with an introduction to REST itself. On slide 7 of my talk I explained the concept of "safe" and "idempotent" HTTP methods. Many people were surprised when I explained that DELETE should be idempotent, meaning that sending a DELETE request to a resource that has been removed should infact not return a 404. However, after doing some additional research now, it seems like there is acually a debate on this topic. Personally, I think a 404 should only be returned in case the URI is known to be invalid. So for example if I know my URLs should look like /notes/\d+ and I get a DELETE request to /notes/foo then a 404 would be appropriate. Otherwise I think that a 204 is the correct response. The reason is that when I DELETE, all I care about is that the resource was removed. If I wanted to know if it existed previously, I would need to do a GET request (REST does not try to keep requests to a minimum). Now obviously there could be a race condition, but lets say I have read a resource, generate a UI an provide a "delete" button. When I click that button, do I really care if I was the one that deleted the record or if someone else already deleted it before me? If I would receive a 404, I would think that I constructed my URL incorrectly and that I need to check if the server changed the URL.

UPDATE: So there has been a lengthy debate on twitter following this post. First up it seems as if most likely idempotence in REST is limited to the results on the server and not to the actual response. Quoting wikipedia on this:

"Methods PUT and DELETE are defined to be idempotent, meaning that multiple identical requests should have the same effect as a single request (Note that idempotence refers to the state of the system after the request has completed, so while the action the server takes (e.g. deleting a record) or the response code it returns may be different on subsequent requests, the system state will be the same every time)."

In this sense it would no be a violation to return a different response status code for a deleted resource than for the request that actually triggers the delete. Now to make things fun, the German wikipedia entry disagrees. All things said, I still maintain that the points I raised above mean that most likely you want to return a 2xx code and not a 4xx. I would find a 404 highly confusing but in case I know for sure that the resource used to exist a 410 might be appropriate.

HHVM

Several people asked me about my opinion about HHVM. If I look back to the original announcement by Facebook for HipHop, then I have to say I was totally underwelhmed by their gains. Given all the effort and complexity getting twice the performance seemed like such a little gain, given that every single PHP 5 minor release has given speedup in the range of 20%. I felt that their time would have been better spend helping on those improvements and maybe writing a PHP to C-extension convert. Now HHVM is much more interesting because it at least gets rid of a lot of the pains of HipHop as it can be used in development more easily. In terms of performance the speed ups are mostly for longer running computation heavy requests otherwise they are quite small compared to PHP 5.5 with OpCache. The memory footprint reductions are however quite significant even for requests that do not do a lot of number chrunching. What makes HHVM really interesting is that they are just at the very beginning of adding optimizations to their JIT. So there seems to be the potential for significant further speed ups in the near future. So given that HHVM now runs with many popular frameworks and libraries we are certainly keeping an eye on HHVM. We will hopefully soon publish a blog post with some more details on our performance analysis of HHVM.