Before you start diving-in, please read the following sections to navigate this book effectively:
Yet another book? Really?¶
I sincerely wish this “book” wasn’t required. However, when I started learning Haskell, about 18 months ago, I struggled a lot even after referring to some of the best texts out there. For example, I went through almost all of Learn You a Haskell for Greater Good (LYAH), read some chapters from Real World Haskell (RWH), and followed it up with the Yesod Book (because I wanted to start writing webapps ASAP). I also kept stumbling upon a number of blog/tutorials by Michael Snoyman, and School of Haskell.. Even after going through so much reading material, I really struggled through my journey of learning Haskell.
More recently, new members in our team at Vacation Labs tried learning Haskell with the help of The Haskell Book and CIS 194 course. The feedback on the former was that it was too verbose (it’s 1,200+ pages!) and the feedback on the latter was that it was too fast-paced.
Moreover, this book is a need to scratch our own itch at Vacation Labs. We need to get new hires up-to-speed with Haskell as quickly as possible. This book is an attempt to solve our own problem, with a hope, that it benefits the community, at large.
How is this different?¶
While going through so much reading material, and finally delivering our first module written in 34,000 lines of Haskell, I had a few important observations:
- There isn’t a recommended way of doing certain common tasks in Haskell.
- As a corollary to the previous point, it isn’t easy to steer clear from gotchas, pitfalls, and “researchy” ideas (and libraries) that don’t work well in a real-world setting.
- Category theory and lambda calculus are not really required for most applications of Haskell. However, a number of texts go off on a tangent with academic topics, every now and then. Beginners can always come back and read more academically oriented material when they hit a point where they need to write really abstract code. Such academically correct definitions need not be forced upon them when they are still struggling with thinking functionally and how to express logic without using
- Lack of discourse on the design of Haskell programs and using the type-system effectively. A number of people (which included me), are probably learning Haskell and typed functional programming at the same time. Most texts do not try to build the intuition of solving problems in a manner suited to the FP world-view. SICP does this brilliantly, however it uses Scheme which is dynamically typed and mutable.
My goal is to address all these points throughout this book.
So, “One book to rule them all”?¶
Heh, probably not! I am not saying that everything is crap and we should burn the world. All I am saying is, that I feel that there are gaps and this is an attempt is to fill those gaps.
This means that chapters of existing books, existing exercise problems, and existing blog posts will be offered as extra reading material wherever applicable. In addition to that, we will be adding a lot of highly opinionated commentary, extra exercise problems, and open-ended questions that will force you think, and evaluate whether you have really grasped the core concept being discussed.
Help me keep this alive¶
Writing this book is a huge undertaking, which I am not sure I’ll be able to keep-up with (along with running things at Vacation Labs). So, if you find this interesting please do the following to give me that extra motivation :)
- Tweet about the stuff that you found interesting / helpful and link back to this book, so that others may discover it as well.
- Help me fix stuff that is obviously wrong, like typos and syntax errors in code samples. Instructions on how to use the Hypothes.is plugin are given at Highlight & comment freely with Hypothes.is
How to use this book effectively¶
Do not skip the exercises¶
This book is not a novel. You will learn nothing if you just skim through the chapters. You have to solve the exercise problems. The only way to learn Haskell is to practice what you have learnt (in fact, it’s probably true for any new skill).
In later chapters we go back to the problems of earlier chapters and try solving them with the new techniques just introduced. This helps you appreciate what exactly a certain technique / abstraction / library brings to the table. Do not skip re-solving existing problems just because you have solved them earlier. Writing your code with three different techniques is a part of the learning process.
At a number of places there are a few open-ended questions that force you think. Do spend that time in thinking. These are very pointed questions to help you build your intuition for a certain concept and/or understand when to use a certain library / abstraction / technique. Also, a number of questions are purposely unsolvable if you apply only the material introduced till that point. Again, this is important to build motivation for why a certain library / abstraction / technique is required (which is probably introduced later).
Highlight & comment freely with Hypothes.is¶
If you don’t already have one, please create an account with Hypothesis. Hypothesis is a tool for adding annotations, i.e. highlights and comments (think Medium & Disqus, rolled into one) on any webpage. This book is integrated with Hypothesis and you should be able to see a sidebar in your browser:
You can highlight any text and add your comments. Your comments will be visible to all other readers of this book.
Some tips on what kind of comments to add:
- DO point out typos or syntax errors.
- DO point out instructions that did not work for you. The idea is to give bullet-proof instructions to beginners, so that they can spend time in actually learning the language & concepts rather than struggling with installation and dependency issues.
- DO point out places where you struggled with various exercises or documentation. There is a very high chance that others will get stuck at the same spots. I will keep monitoring such comments to see how the text can be evolved to help in such areas. Till such time, “misery loves company” – and it’s good to know that you’re not the only one pulling your hair :-)
- DO leave links to beginner-friendly documentation for various topics if you find something works better than what is included here.
- DO leave links to interesting exercise problems. Try not to get too mathematical or algorithmic with the exercise problem.
- DO NOT post solutions to exercises. It really spoils the fun of learning.
- DO NOT start a stack vs cabal debate. Use that energy to instead convince the authors of stack & cabal to merge their work together and build a kickass unified tool for the ecosystem.