Hi there! My name is Sandy Maguire --- you might know me from my work on Polysemy and Thinking with Types.

One of purely functional programming's greatest strengths is its powerful abstraction capabilities. We proudly exclaim that our functions are referentially transparent, and because of that, our bugs will always be shallow. And this is often true.

10x is often cited as the magic number beyond which technology is good enough to overcome network effects. I'm personally convinced that writing Haskell is 10x better than any other popular programming language I've tried. But if functional programming is so good, why hasn't it yet taken over the world?

This is a very serious question. If we're right about this, why haven't we won?

Design and Interpretation of Haskell Programs is my answer to this question. Haskell hasn't taken market share because we collectively don't yet know how to write real applications with it. Abstraction is our language's greatest strength, but all of our "best practices" evangelize doing everything directly in IO. Is it really any wonder that nonbelievers aren't convinced when we show them an imperative C program that just happens to be compiled with GHC?

Instead of giving up, this book encourages us to take a heavy focus on designing leak-free abstractions, on building programs that can be reasoned about algebraically, and on completely separating business logic from interpretation details.

But I can't do it all by myself. Writing a book is a hard, gruelling process, that's made much easier by knowing that people care about the end result. If you're a conscientious engineer, unhappy with the status-quo of large, unmaintainable, "production-grade" Haskell, then this book is for you. By pledging, you let me know that this book is worth writing. In addition, your early feedback will help make this book the best it can possibly be.

With your help, together we can tame software complexity and write codebases we're proud of.