Book review: Functional Programming in PHP

I was asked by php[architect] a while back to review "Functional Programming in PHP, 2nd Ed" by Simon Holywell. I've been sitting on this review for a while, so it's time to finally get it done.

Disclosures

• I was provided with a free copy of the book, both paper and digital, for the purpose of review.
• I have received no other compensation, and neither php[architect] nor Simon Holywell reviewed this review before publication.
• The review is based on the paper version of the book. It's possible that some issues raised have since been corrected in the digital version; I have not checked.
• I have written for php[architect] in the past and likely will in the future but have no active business relationship with them, or with the author.
• The views expressed here are my own and do not reflect the opinion of my employer, Congresswoman, or my brother's cat (who would likely view it as beneath her to read, because she's a cat).

With that out of the way, on to the review.

Introduction

I really wanted to like this book. I've been a long-time advocate for functional programming in PHP, or at least functional-esque programming, and have presented on the topic before at numerous conferences. It's also a really hard topic to explain well, especially the more advanced concepts that, in a sense, don't really apply in PHP or any other non-functional-centric language. Coding in a functional-esque way, even without going all-in on purely functional all-the-things, can and does greatly improve the quality of one's code in almost any language. I was, therefore, really hoping for a book I could recommend to PHP developers on the hows and whys of functional PHP.

Sadly, I don't believe this is that book. It starts strongly enough, with a solid conceptual introduction to functional programming as a concept and a light-hearted, abbreviated history of computation. Most readers will already know some parts of it but are almost certain to pick up a few nuggets of interesting historical information anyway; I did. The theory parts tend to be good overall, and the first two chapters are well worth the read.

The wrong type of book

Unfortunately, the rest of the book is all over the place.

First, I must state that the publication date of the book is October 2016; I am writing this in November 2018. PHP develops impressively fast so it's not fair to criticize a PHP book for being out of date 2 years after it's published. That said, I do believe it is fair to criticize a PHP book for being out of date the day it's released. Despite being published less than two months before the release of PHP 7.1, the book's target PHP version is... 5.4. There's even a nod or two PHP 5.3 users. That's despite PHP 5.4 having been End of Life for a year already by the time it was published.

In its defense, there's not a great deal that has changed in PHP's functional capabilities since 5.4. The main additions are generators (PHP 5.5) and the iterable type declaration (PHP 7.1), which makes it easier to type declare an infinite stream of values, which is the type of problem space where functional style programming excels. However, the book spends a great deal of time talking about types in PHP, but does so in a PHP 5 mindset. That's despite even having a chapter toward the end talking about fun new features in later versions of PHP, up through 7.0 and some hints of 7.1, so it's not like the book was stuck in editing for multiple years.

That's already problematic, but it's compounded by the fact that... types are not really part of functional programming. Many functional languages (Haskell and Rust come to mind) have extremely robust typing systems that put PHP to shame, but many others (LISP for instance) have no syntactic types at all. The question of types is orthogonal to functional programming, and I fully support more explicitly typed PHP in virtually all circumstances, but to talk about types in PHP, and and so from a PHP 5 point of view, and then not even use them in 99% of the sample code in the rest of the book is both confusing and disappointing.

The book also spends a great deal of time talking about HHVM/Hack, Facebook's alternative PHP engine. Again, bearing in mind 2016 it's fair to talk about HHVM, as at the time it was still a viable PHP alternative. (Facebook has since declared that they're taking HHVM in a different direction and won't be maintaining PHP compatibility, making it a full fork and thus largely irrelevant to PHP developers.) However, despite spending an entire chapter (chapter 5) on HHVM, there's barely one page that is at all relevant to the topic at hand: HHVM's short lambda expressions (a shorter way to write anonymous functions) gets one page, while the rest of the chapter talks mainly about... Hack's more robust type features, which are completely irrelevant to a book on functional programming. Even if it weren't that Hack is no longer of concern to PHP developers I would recommend skipping all of chapter 5 as off topic.

A functional narrative

Chapter 3 goes over various language features, and aside from the afore-ranted question of types and language version does a pretty good job of reviewing the relevant bits with examples that are useful, even if needfully trivial. One nice example is a when() function, which collapses a conditional into a function call:

function when ($condition, $do, $otherwise = null) {
  if ($condition) return $do();
  elseif($otherwise) return $otherwise();
}

Other basic topics such as recursion, array_map()/array_filter(), etc. are covered decently well.

Unfortunately, when getting to more advanced topics the author chose to defer to 3rd party libraries. Rather than demonstrate how to implement more interesting functional tooling in PHP, and how useful it can be, the book instead recommends downloading a number of 3rd party libraries and using them without really explaining how they work. While that may be a good approach for production code, this is supposed to be a book on how to write functional code in PHP: So let the reader write functional code! Glossing over how a reduce operation, or currying, or promises work under the hood in favor of "let this other library do it and be happy" is not very educational. It also seems to flip flop between "here's how we'd write it" and "just use this library" with no pattern I can discern.

With that large caveat, though, the chapter on common functional patterns is pretty good. It covers the most common functional-ish design patterns, at least as well as they can exist in PHP. Unfortunately the examples are so contrived that I'm left wondering "how is this useful in practice?" That is a very common problem for programming books, as examples simple enough to explain but complex enough to demonstrate are hard to come by, but it is a problem here.

That challenge becomes even more apparent when talking about everyone's favorite hate-target in functional programming: Monads. (Quick, hide your children!) The book makes a valiant effort to explain what they are, but it feels in many ways like every other monad tutorial I've read that covers the theory but doesn't manage to sell the "why" in a non-Haskell language. The Maybe monad is somewhat better explained, as it is the most applicable to PHP developers, but the example code is still using largely theory so I'm still left with a sense of "OK, cool, but... why should I, a PHP developer, care?"

That, I think, is the largest failing of the book. Despite a valiant effort, I'm still left at the end wondering "OK, cool, but... why should I as a PHP developer care?" The lack of an obvious narrative, the overly-generic examples, and PHP's syntactic weaknesses (which are in no way the author's fault, of course), leave me with a general sense of "meh" about the topic. Even the example of a "domain specific language in PHP" left me wanting, as it's just an over-engineered and slow way to output HTML. (I've built one of those myself before. It wasn't that exciting.) I wanted something that really showed off the benefits of a functional style, and that's not it.

I went in wanting to see where functional programming would make my code considerably better; I didn't find it.

General issues

I also have to be critical of the book production process. While reading, I ran across numerous typos and other grammatical issues. While none were so egregious as to make the text unreadable they were quite jarring. I would have expected them to be caught in the editorial process. (As a note, they may have been corrected in the digital versions of the book. I have not checked and I don't know php[architect]'s policy on such corrections. I was reviewing the print copy.)

The print version of the book also uses a very cheap printing format. I am normally not a font-nerd; I can't tell Arial from Helvetica, which means I don't get invited to graphic designer parties. Nonetheless, the layout chosen for the book is poor even by my un-enlightened standards. The text is too small, and the font and ink choices make it feel like a typewriter rather than 21st century printer. It made the whole text difficult to read and the difference between prose and code sample harder to discern.

The author's choice of placeholder text was also odd. It freely flipped between the standard foo/bar standbys, contextual "hello world"-level text, and references to African pop music. While I have no problem with African pop music I am only an ignorant American so didn't recognize it as such until I googled some of the phrases used for this article; I honestly thought they were Australian Aboriginal names at first (as the author is Australian). I'm not going to knock the book for African pop references, but the mix-and-match between that and even more generic text was confusing. It would also help to state what they are and avoid confusing the majority of the likely reader base that is not going to recognize African pop. (That would also be a helpful leverage to create a consistent narrative and example throughout the book to show real-world examples; let's build a fully-functional music index site or something!)

Conclusion

As PHP evolves, it has very slowly been picking up more functional-friendly functionality. (And she sells C shells by the sea shore.) That's a chicken-and-egg problem, as there's little use for more of it while functional programming is still fringe in PHP, yet it's not going to stop being fringe until support for it is stronger. What we need is better developer-education to get more people adopting functional techniques so that the need for better language features becomes even more evident.

"Functional Programming in PHP" tries to be such developer-education, but I fear it falls short. While its coverage of functional history and theory is fine, it comes up lacking when trying to make the case for actually using it. Some of that blame falls to PHP itself for having mediocre built-in functional tooling, but the whole point of such a book should be to compensate for that lack. It doesn't manage to do so. It just can't close the sale enough for me to care, and I'm already a functional advocate.

Add to that how badly the book has aged (given that it was already badly aged when it went to print) and the pointless diversions on typing and HHVM, and the result is a package I can respect for trying but cannot really recommend.

"Functional Programming in PHP, 2nd Ed" by Simon Hollywell is available now from php[architect] in both PDF ($22 USD) and print ($29 USD).