[Functional Programming] An Outsider's Guide to Statically Typed Functional Programming (self-published/Leanpub)

An Outsider's Guide to Statically Typed Functional Programming

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.



It’s interesting to see this book here. I’ve been following the author, Brian Marick, on blogs and twitter for many years. He’s got some great insights, but as he admits in the blurb above, he’s learning as he writes and is not sure he’ll have a compelling enough case in the end for static typing. This book is more about static typing in functional languages than about functional languages in general.

I’ll likely read the book once he’s finished depending on whether he convinces himself the case for static typing is strong enough or not. At this point, I would only recommend it for those really wanting to explore the implications of static typing in general because I don’t think it’ll teach much that is applicable to Elixir.

1 Like

My suspicion is that he will get to “it depends” - i.e. there are circumstances where the rigor of static typing is valuable but there are cases where it overcomplicates matters leading to lots of accidental complexity. In the case of Elm and Purescript you can always decide to push functionality into the JavaScript realm and simply interface with it as needed.

However I’m also hoping that another conclusion will emerge: designing / thinking in types is always valuable - regardless whether you are forced to do so by a static type system or whether you are merely disciplined enough to consistently use typespecs in a dynamic language as a way to explicitly express the shape of data that you expect to be handling (even if the guarantees of success typing are rather weak compared to strong static typing).

Dabbling with Elm code really pushed me to use typespecs much more in Erlang/Elixir simply to demonstrate to myself that I had thoroughly considered the shape of data that I’m dealing with.

1 Like

Extremely this! Thinking in high types makes for much better code in every experience I’ve had to date.

Good points, all. I don’t want to be a wet blanket because static types are on my list to teach myself. My own career has taken me through many years of Java, which is statically typed, though quite verbose and limited, and un-functional (:grin:). I definitely see the distinction between thinking in types and coding in types, and I do a lot of thinking that way.

My main point in my initial comment is that it is a bit of an outlier. It’ll certainly broaden the reader’s horizons, but for people with an explicit goal of learning Elixir I’d recommend pretty much every other listed book first.

Well, if we’re only listing Books that can be classified “learning Elixir” books then maybe it’ll have to go. But to be perfectly honest when I selected “Books” it wasn’t clear to me that it was a subcategory of “Learning Resources” - frankly it belongs more in the realm of “other Books of potential interest related to functional programming”.


I think it’s ok here (maybe we’ll change the format or section layout later) - but anyone interested can read the comments and decide accordingly :023: