Preface

Functional programming has been an interest of mine for years. That’s not to say I’ve been an expert in it, or that I’ve done much work in strictly functional languages, just that I’ve been interested in the topic.

Sadly, I’ve long found the available documentation and tutorials on the web to be lack-luster. Most of them either cover the very basics and then stop, or assume you’re already an expert in Haskell and so explain advanced topics in the most convoluted and Haskell-centric way possible. Neither of these did I find useful.

I have also found that the Curse of Monads seems to be true, as nearly every explanation I found about that mythical concept was obtuse, assumed you had three years of advanced mathematical training, or so dumbed-down as to be actively harmful to understanding.

“Once you understand monads, you immediately become incapable of explaining them to anyone else.”

–Gilad Bracha

Combined with PHP’s overall clunky syntax for doing functional-esque code, I generally didn’t go further than “pure functions are your friend,” either in my own code or what I explained to others.

That is, until PHP 7.4.

PHP 7.4’s introduction of short lambdas is, as we’ll see in this book, a game-changer. While it doesn’t make anything new possible, it makes a lot of things suddenly practical. That makes all the difference, so I decided it was time to buckle down and really dig into functional programming. And what better way to learn than to force yourself to teach it to others?

I don’t mean that sarcastically; in fact, that’s been my history with functional programming from the beginning. I submitted a talk to a conference back in 2012 on functional programming before I really knew what I was doing, because that gave me a reason to learn it well enough to be able to explain it. I went on to give it 10 times. This book has had the same effect.

I knew when I started out that I was going to have to actually learn, finally, what all this category theory fuss was about. I did not expect it to be as hard as it was; apparently the Curse of Monads applies to most of category theory. A large part of the issue seems to be that no one can agree on how to call anything; it took reading a dozen tutorials in a half dozen languages to realize just how much the terminology varied, and just how much of a problem that causes for people trying to learn functional programming, category theory, or anything else.

I never would have thought that software engineering could be held up as an example of having consistent terminology, but I suppose all things are relative.

The central crux of this book is Part Two, in which I tackle the hard, academic, theoretical bits. It seems to be a trope that any time someone thinks they have understood monads they write an online tutorial about it, and I suppose I am no different. It is my hope that by writing that section, and rewriting it multiple times, while learning the material itself I was able to straddle the threshold between this world and the next (the one in which one does not understand monads, and the one in which one cannot explain them) long enough to capture a reasonable explanation of them. Should you find that I was successful, I would love to hear about it.

I am indebted to a number of people for their help in making this book happen.

• Nash van Gool, who provided early validation that my early efforts were not entirely incomprehensible.
• Nash and my colleague Chad Carlson, who served as beta testers for the first draft of the manuscript.
• Shayna Steinberg, for reviewing the category theory section and validating it is comprehensible even for non-programmers/mathematicians.
• Bartosz Milewski, whose book and website “Category Theory for Programmers” is the best tome on the subject to date. He also was kind enough to answer my random validation questions on online forums, even though he had no idea why I was asking.
• My editor, Kara Ferguson, without whom it’s quite possible there would be not a single comma in the right place in this entire book.
• Rebekah Simensen, who provided the delightful cover art you have probably already enjoyed. (Assuming you looked at the cover before opening this book, anyway, which seems likely.)

And of course to you, dear reader, as a book that is not read may as well not exist. It is my sincere hope that you find this volume educational, entertaining, and eye-opening. Or at least that it serves you as more than a monitor stand.

May your life be as pure as your code. I wish you well.

–Larry Garfield, @Crell