An Outsider's Guide to Statically Typed Functional Programming
An Outsider's Guide to Statically Typed Functional Programming
Minimum price
Suggested price
An Outsider's Guide to Statically Typed Functional Programming

Last updated on 2018-04-05

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!")

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.

So: that's what the book's about. I hope it works out. 112 pages in (as of May 18, 2017), it looks promising.


"Brian @marick is always five years ahead of everything so I'll be buying this." – Michael Feathers, author of Working Effectively with Legacy Code, tweet of 23 May 2017.

"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

Table of Contents

    • Introduction
      • Why bother with static functional languages?
      • Why is this book called an “outsider’s” guide?
      • What the book covers
      • How the book covers it
      • Prerequisites
      • The exercises
      • The back of the book
      • About the cover
      • Your problems and questions
      • Change log
      • Thanks for the help
  • I Elm
    • 1. Functions
      • Applying functions
      • Defining functions
      • Partially-applied functions
      • Idiom: Self goes last
      • Flip: a function that only cares about functions
      • Point-free style
      • Function composition
      • let
      • Two apparently pointless functions
      • What now?
    • 2. Some types
      • The old problem with static typing
      • Concrete types
      • Function types
      • Quantified types
      • Elm cheats, a bit
      • Functions that take functions as arguments
      • What now?
    • 3. Type annotations
      • Terminology. Yay. Terminology
      • Elm is still in charge
      • Narrowing
      • What now?
    • 4. A digression: immutability
      • Building lists
      • Eu sou verde, e daí?
      • “Purity” and other jargon
      • Practical implications: the outside world
      • What now?
    • 5. Maybe and its idioms
      • Making use of Maybe
      • and pipelines of iffy computations
      • At the end of the pipeline
      • Haven’t I seen map somewhere before?
      • Lists of Maybes
      • Multiple Maybe arguments
      • What now?
    • 6. A teaser: designing with types
      • Taking “type-driven” all the way
      • What now?
    • 7. Sum types
      • Sum types explicitly name cases
      • The whole story on sum type declarations
      • Importing modules containing sum types
      • A bit more on pattern matching
      • What now?
    • 8. Sum type idioms
      • Making invalid values impossible
      • Grouping related data
      • Heterogeneous data
      • Abstractions that destroy: Int and Float
      • Generalizing tagged types using phantom types
      • Type aliases: Tagged Percent Float is an OK password, but…
      • What now?
    • 9. Working with the outside world
      • The Elm Architecture (structure)
      • The Elm Architecture (behavior)
      • Producing HTML
      • Random numbers
      • Our first app: a peculiar counter
      • Subscribing to events
      • Responding to browser events
      • What now?
    • 10. Types and program structure
      • Types tie the Elm Architecture together
      • Type variables and libraries
      • What now?
    • 11. Records
      • Making and manipulating records
      • Record types
      • Pattern matching
      • Records are product types
      • Nested records
      • What now?
  • II The ToInt Saga
    • 12. Conventional testing
      • Installation and directory layout
      • Structure of a test
      • The Result type
      • Expect functions
      • Characterizing String.toInt
      • Explaining my results
      • What does the repl know, and when does it know it?
      • What now?
    • 13. Recursion and folding
      • Tail recursion
      • Folding
      • The performance of lists
      • Two types of recursion
      • What now?
    • 14. Surviving a messy problem: a real toInt
      • Recursion and wrappers
      • Lazy evaluation
      • Visibility and testing
      • toInt at last
      • What now?
  • III The Saga of the Animation App
    • 15. Architecture and animation
      • A nested architecture
      • Basic animation
      • Time travel
      • Libraries that create Cmd values
      • What now?
    • 16. Pragmatics of multiple modules
      • Circular module dependencies
      • Hiding implementation details
      • What now?
    • 17. A refactoring
      • What now?
    • 18. Animation extras
      • Names
      • A repeating animation
      • Falling realistically
      • Simultaneous animations (an exercise)
      • Multi-step animations (an exercise)
      • Sending messages during animations
      • What now?
    • 19. Text input, form state, and validation
      • Storing state
      • Fields can make invalid values impossible
      • Tracking validation state
      • What now?
    • 20. This app’s structure
    • 21. Design tidbits
      • Tagged types in practice
      • Defining and using operators
      • Information hiding and partitioning
      • Simplifying via deferred computation
      • Ordering computation
      • Too many tuples
      • What now?
    • 22. Continuation-passing style as a design inspiration
      • Continuation-passing style
      • Continuation-passing style for humans
      • The solution, sketched
      • Sequencing animations
      • Looking ahead to PureScript and similar languages
      • What now?
  • IV Lenses and Laws
    • 23. Dictionaries and arrays
      • Dictionaries
      • Arrays
      • About data structures
      • What now?
    • 24. Nested structures, law-based design, and a kind of polymorphism
      • Planning a solution
      • Lenses work with records and tuples
      • Using lenses and laws with Dict
      • Combining lenses
      • The Upsert lens
      • Phantom types, Elm records, and polymorphism
      • The Humble lens and its laws
      • Using lenses
      • Working with sum types
      • Terminology, again
      • What now?
    • 25. Monoids, laws, and the avoidance of creepiness
      • Lens composition behaves sensibly
      • Motivating monoids
      • Spot the Monoid
      • Function composition is not quite a Monoid
      • Can lenses be an instance of Category?
      • About creepiness
      • What now?
    • 26. Error handling, pipelines, and JSON
      • The example app
      • The three errors
      • A version with no error handling
      • A version with branchy error handling
      • A version with flow-style error handling
      • A new lens type
      • Flowing state through a pipeline
      • Reporting an error via HTTP
      • Unstunting exercises
      • What now?
    • 27. JSON decoders, functors, and type constructors
      • Functor and its laws
      • What’s up with Result? (type constructors)
      • Are functions functors?
      • Equality
      • Are JSON decoders functors?
      • Using functors
      • Metaphors
      • What now?
  • V Design Topics
    • 28. Combining records and sum types
    • 29. More examples of making invalid values impossible
  • VI Purescript
    • 30. Blundering into PureScript
      • PureScript expects projects
      • Starting the repl
      • Trying out functions
      • Printing types
      • Numbers
      • Lists and arrays
      • Defining functions
      • Anonymous functions
      • Type signatures
      • Type classes and type signatures
      • Oh pretty boy, can’t you Show me nothing but surrender?
      • Sum types
      • Phantom types and type aliases
      • Implementing Show
      • Adding type annotations to values
      • Modules and imports
      • A module definition
      • import variants (reference)
      • Import style
      • Total and partial functions
      • Pipelines
      • Records
      • Result is Either
      • What now?
    • 31. Finer-grained access to the outside world
      • Two random numbers at once
      • Adding functions to effects
      • Composing effects
      • What now?
  • VII A Child’s Garden of Type Classes
  • VIII Idris and Dependent Types
  • Appendices
    • Glossary
    • A quick but incomplete Elm reference
      • Declaring a module
      • Importing modules
      • Types with literal syntax
      • Types
      • Records
      • Type annotations
      • Pattern matching
      • Other control structures
    • Differences between Elm and Purescript
      • Your favorite types
      • Type annotations
      • Importing modules
      • The repl
      • Records
    • Which type class do I want?
    • How can I make my type less creepy?
    • The singular truth about functions
      • Single-argument functions
      • How point-free style works
    • Functions all the way down
      • Thunks
      • Boolean values as functions
      • This way lies madness
    • For fun: William James’s story of the squirrel
  • Notes

About the Author

Brian Marick
Brian Marick

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.

The Leanpub 45-day 100% Happiness Guarantee

Within 45 days of purchase you can get a 100% refund on any Leanpub purchase, in two clicks.

See full terms...

Write and Publish on Leanpub

Authors and publishers use Leanpub to publish amazing in-progress and completed ebooks, just like this one. You can use Leanpub to write, publish and sell your book as well! Leanpub is a powerful platform for serious authors, combining a simple, elegant writing and publishing workflow with a store focused on selling in-progress ebooks. Leanpub is a magical typewriter for authors: just write in plain text, and to publish your ebook, just click a button. It really is that easy.

Learn more about writing on Leanpub