This book is the culmination of many brash years and hard lessons. The story starts all the way back when I migrated from C++ into perl. The perl programming language was amazingly powerful compared to the low-level manipulations and bookkeeping of C++. (The fact that it was “slow” never bothered me – I would rather write powerful, effective slow code than weak, buggy fast code.) In the world of perl, there was the idea of an “anonymous subroutine” that could be passed around and manipulated. You could also directly manipulate the symbol table. The symbol table is the collection of function names available to the program. Between these two things, I realized that I could code at a higher level: I could write subroutines that returned subroutines and store those into the symbol table, effectively having my code write code at runtime. In perl, these subroutine factories are called “template functions.” I proceeded to write some truly unreadable – but truly powerful – perl.
I shared this revelation with my friend and mentor, Brian Hurt. He was the grizzled veteran developer who seemed to have seen it all. Brian told me that what I was doing was this thing called “functional programming,” and encouraged me to look into proper functional languages, specifically OCaml, and its derivative, JoCaml. I was immediately hooked. By 2008, I presented “Why Rubyists Should Learn OCaml” to the Ruby Users Group of Minnesota (Ruby.MN).1 There was a power in functional programming that was truly incredible compared to the then-standard way of writing code. Moreover, my mathematical background played very nicely with functional programming: the fact that state did not change meant that I could employ the same
kind of reasoning to my programs that I employed with mathematical equations. I presumed at the time that a functional programming language would rise and fundamentally transform what it means to program, much as Java ascended and made Object Oriented Programming ubiquitous. So far, this hasn’t happened.
