An Outsider's Guide to Statically Typed Functional Programming
An Outsider's Guide to Statically Typed Functional Programming
Free!
Minimum price
$22.00
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'd 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 that won't be because of the technology stack.

Some statically typed languages mix functional programming and object-oriented programming. Some of them, like F# and Scala, are also safe choices.

This book was conceived as an attempt to demonstrate that the purer statically typed languages – ones like Elm, Haskell, and PureScript – are suitable for adoption by the early mainstream. That would require that they be well suited to handling messy domains, have the surrounding infrastructure necessary for language success in the modern day, and that the "how" of using the language features is well understood and accessible to a mainstream audience.

If so, the book would be poised to catch a wave.

"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.

Alas, I've concluded that five years is an underestimate. The languages have progressed, but not fast enough. That is, their advantages over mixed or dynamic languages are small enough that accepting their extra hassle and risk isn't a bet I'd care to make.

To be clear: these languages are solid, as languages. However, they require more dedication and work than more established languages, and I don't think they yet pay that back. It's not that they don't have benefits – it's that the cost is too high.

That leaves two possible uses for the book.

First, the language I'm most likely to be wrong about is Elm, a language for the browser front end. This book covers it in considerable depth.

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

One way it may stand out from other Elm books is that I make a concerted effort to explain idioms and useful habits of thought. I try to go beyond "here's how you do this in Elm" to "here's how it fits into the FP programmer's way of approaching problems."

Second, some people find it useful to learn new ideas (like functional style) in the purest form. It makes the ideas stand out more clearly. It can innoculate you against falling back too easily into old habits when using a mixed language, or it can make the "why" behind features in the mixed language stand out more clearly.

If that's your learning style, the Elm section of this book can be for you, because the novelties it explains also appear in the mixed languages.

"Always wanted to learn FP but never found such a good start for an outsider. Awesome!" – Yuri Oliviera, tweet of 8 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.

But Elm is a deliberately minimalist language. What about the features it removes from other pure FP languages like Haskell and PureScript? Those features have potential.

"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 think the features aren't as important as Elm's because they (mostly) don't appear in the mixed languages that you're more likely to use. However, the book does introduce PureScript and tries to explain ideas like type classes and effects differently than the conventional ways, which I generally found unnecessarily difficult to understand.

However, until I stop being "five years ahead of everything" and the pure languages become safer, the PureScript parts of the book are of intellectual, rather than practical, interest.

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.

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
      • Maybe.map 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

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, publishers and universities use Leanpub to publish amazing in-progress and completed books and courses, just like this one. You can use Leanpub to write, publish and sell your book or course 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