About the Book
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!")
So: that's what the book's about. I hope it works out. 112 pages in (as of May 18, 2017), it looks promising.
"Always wanted to learn FP but never found such a good start for an outsider. Awesome!" – Yuri Oliviera, tweet of 8 June 2017.
"I just love the casual style this book is written in, that also happens to be a fantastic guide to Elm!" – Igal Tabachnik, tweet of 23 June 2017.
"I'm really liking your book. Thanks for all the work making it so straightforward to read." – Bill Tucker, tweet of 28 August 2017.
"Reading @marick's 'OutsideFp' book. Thoroughly engrossing and a great introduction to #FP using @elmlang. Can't wait for @purescript part." – Lee Owen, tweet of 10 September 2017
"I'm really enjoying your book. I've written a couple thousand lines of Elm prior to reading it and this book is filling in the idioms that I was missing. Thanks for writing it!" – Jason Stiebs, tweet of 16 January 2018
About the Author
Brian Marick first learned to program in 1976, using the Tutor language. He has since done real programming in C, Common Lisp, Java, Ruby, Clojure, Elixir, and Elm. Much of his career, though, has been spent consulting, first on software testing, then–after he lucked into being one of the authors of the Manifesto for Agile Software Development–on testing and programming on Agile teams. He's written four books, three of which you can still buy: The Craft of Software Testing (horribly out of date), Everyday Scripting with Ruby, and Functional Programming for the Object-Oriented Programmer (almost entirely about dynamically-typed functional languages). He's currently trying to make a modest living writing webapps for schools of veterinary medicine, deliberately using advanced languages and techniques so that he has real-world examples to use in books, training, and consulting.