An Outsider’s Guide to Statically Typed Functional Programming
by Brian Marick
This book is about using statically typed functional programming in messy domains. It’s written by someone who found the typical arguments for static FP unpersuasive, both because they focus on overly tidy domains and also because they emphasize principles at the expense of practice (the idioms and habits programmers use).
Dynamically typed functional languages like Clojure and Elixir are now at the point where I feel comfortable basing a commercial application on them. If you use Clojure instead of Java, or Elixir and Phoenix instead of Ruby on Rails, you’ll be fine. Your app might still fail, but it won’t be because of the technology stack.
Statically typed functional languages like Elm, Purescript, Haskell, or Idris are definitely becoming more popular, but (in my opinion) are not clearly safe bets for mainstream applications. By “mainstream”, I mean:
- Applications that require only “ordinary” reliability. I sometimes see HTTP 500 errors on websites. I shrug and try again. Netflix via my Amazon Fire media player occasionally gets stuck loading a TV show. I shrug, back out, click on the show again, and it works. This restriction to ordinary reliability matters, because the static FP languages are much more obviously useful in cases where runtime errors can kill people.
- Applications that work in messy domains. Messy domains are ones like payroll systems that have to deal with decades of special cases negotiated by unions. Or enterprise applications with a long history of salespeople making special deals to close big sales–deals that require special-case code somewhere in the system. Or, generally, any application in direct contact with people who can’t be forced to behave in a consistent, “lawful” way.
- Applications that are continuously growing new features. Sometimes one of those features forces a rethink of a domain model, and a major challenge is getting the architecture to a state where such rethinking doesn’t have a ripple effect that makes every change hugely expensive.
The programmers who work on mainstream applications are rarely the target audience of the static FP literature. They are exactly the target audience for this book. My goal is to make the most compelling case I can that static FP will give you new abilities, especially new abilities for modeling a messy domain riddled with exceptions to the rules. I aim to do that by teaching you idioms, habits, and design patterns that can make this style of programming an ordinary practice for you to perform–rather than a pile of ideas for you to connect.
(For early readers, I should note that I am not yet myself convinced the case is compelling, and I don’t yet know nearly enough of the idioms and patterns. I’m learning as I write, something I’ve always found very effective (but grotesquely inefficient). I warn you of this because I might decide the case is not strong enough. Which will leave this book in an interesting place: “Here’s many pages of explanation of something that turns out not to be good enough. Sorry!”)
As far as the mechanics go, I’m taking what I think is an interesting approach. I’m beginning with Elm, the friendliest but least powerful of the common static FP languages. I’ll then move on to Purescript, a more mainstream, more powerful, but more difficult language. I think learning Purescript as an “add-on” to Elm will be simpler than learning Purescript alone. Both Purescript and Elm are languages that aim to be production-ready alternatives to JavaScript. Finally (but tentatively), I’ll cover Idris, a cutting-edge language that adds new ideas onto Purescript.
). I definitely see the distinction between thinking in types and coding in types, and I do a lot of thinking that way.
