Anyone who knows me knows that I love Haskell as a programming language. I have used it professionally in several different projects, and I have used it casually in a huge number of projects. While most of my projects have never seen the light of day, several of them have made it that far at varying degrees of quality.
Production code in Haskell is rare. There are lots of experiments, proofs of concept, and academic researches out there, but very few complete applications that we get to see. So there are very few instances that we get to see a successful application, much less get an explanation of how it works.
Since Haskell is so strict in its effect management, it can be very difficult and tricky to assemble an application that can do what what all of your Python/C/Java/Ruby languages have instantly. This by itself makes Haskell much less likeable. You get the benefits of strict type checking and effect management, but then it becomes difficult to make different effects systems work together, and it becomes difficult to build a non-painful effects system.
In the first half of 2017, I finally came to understand a group of patterns that serve very well in production code. These are patterns that I would reach for instantly any time I start a new application or library. As quickly as possible I want to get to the core of my code, so it would be helpful to have an operational framework in place from the beginning that I will not later regret having.
What follows is an ever-growing series of articles discussing patterns to use in setting up new Haskell applications and libraries. At all times I will welcome questions and feedback so I can make the articles better or add supplementary articles to explain sections that I may gloss over in the first pass.
This series is not for advanced users or type theorists. This is for relentlessly pragmatic users who feel that Haskell is a great tool but really need to get things done very quickly without stumbling on every little nook and cranny of the language as they go.