Happy Learn Haskell Tutorial Vol 1

Written and illustrated by GetContented.

Published on 2024-05-24.

Contents

Previous chapter: 21. Getting Set Up
... 22.1. Volume 2 and Language Features
... 22.2. More Exercises
Next chapter: 23. Many Thanks

22.1. Volume 2 and Language Features 🔗

Question: Are you planning Volume 2 of the book? Or another book with advanced topics (such as Monads, Combinators, the Y combinator, beta-reduction, Generalized Algebraic Data Types, etc.)

Answer: Yes, we’re definitely planning Volume 2. It’s currently being written and will be released in beta book soon.

We like to draw the teaching of topics out into two or three phases, depending on how you see it. These are: 1. getting the student used to reading/seeing a language feature in action in many places, but not talking about the general case too much 2. getting the student to use a language feature in a few places until they’re familiar with using it on their own and know when it should be used and only then 3. understanding the general case, and naming the feature.

Sometimes we will introduce the third “phase” with the first, sometimes with the second, and sometimes only afterward. It really depends on the topic, how complex it is, and how easy it is to understand.

Having said this, Volume 1 has seen Monad and Combinators the entire book. You might be talking about the combinator pattern here. Again, our whole book uses this approach of building up small functions that do tiny things, and then building our programs out of these pieces. That’s the combinator pattern.

What about beta-reductions? Well, that’s just function application, so yes, we’ve been doing that the entire book as well.

However, some of these topics, such as the Y-combinator and Generalised Algebraic Datatypes are incredibly advanced. While we do plan more volumes than just 1 and 2, it’s worth noting that our books exist to describe things to people so they can use them. It’s no good studing GADT’s if you aren’t extremely well versed at using normal ADT’s first, and even then it’s only useful if you’re building something that is worth the extra complexity.

The Y combinator is an example of something so advanced that most people who understand it have trouble explaining how to apply it to a real use-case, or what it’s for. Its sole purpose is to allow you to do calculation in a functional language without any named variables or functions. That is, to show how you can “bootstrap” computation by having nothing more than function application.

In terms of naming language features when we use them, we often find people get incredibly confused when you throw a multitude of jargon at them. Haskell has a lot of names for things, and we’ve witnessed many times where students have started to understand something, then exclaimed the equivalent of “Oh, THAT’s all ((feature)) is, I totally know how THAT works!” We’d rather you got an understanding of what you’re doing so that when we explain what things are, you have a practical base for them.

A nice example of example of this is how we don’t use the word Monad at all in our book, and yet we use them the whole way through (with `do` syntax mostly). Or notice how we don’t use the word currying until about Chapter 13, but we use these features the whole way through the book. We don’t mention these terms becuase you don’t need to know what they are to use them. When you need to know, we introduce the term. This makes things much easier because there's less of it. It's very carefully prepared to be this way.

If we were writing a book for people who had used other languages before, we would definitely introduce more names earlier on, but even then the names can sometimes get in the way. As a good example, the mathematical name for folding in Haskell is catamorphism. It doesn’t help you to know this fact when you start, and it’s not even that helpful later on until you get to see how it contrasts to anamorphisms, which are things that unfold. And what does that mean? It’s when you build up a collection of things from a single seed value.

If we spent more time on terms, the book would be very long and we’d have less space to explain the variety of the features we do cover in a way you can understand easily. Without doing this, you would have less of a chance of actually using it and understanding it. We do this because we care about you getting a good understanding of the material we cover.

22.2. More Exercises 🔗

Question: Why aren’t there more exercises? There need to be more exercises! Show me the exercises!

We believe a staged approach is indispensible when it comes to learning. We’d like to help you avoid as much pain as possible, and we help you to do this by carving out a very different path than most education models do.

We’ve designed this path to go through a number of topics quickly and show you many of the basics over and over in different situations. This means when it comes time to actually do exercises and write porgrams yourself, you’ve got the foundations of how things work in the back of your mind. This makes it vastly easier to begin to craft programs. We believe people get a rounded experience when they’re exposed to something in a variety of contexts, multiple times, so we’ve designed the material toward that aim.

Learning this way, by the time you come to use these things for yourself, you’ll already have an intuitive feel of how they can be used. We then take you through the variations and intricacies of using the basics for yourself with guided exercises, and give you exercises of your own to let you cement this understanding into your own experience. We believe in exercises and repetition, but more importantly, in keeping it interesting. There is no use in having exercises that you aren’t interested in doing.

There is also no point to giving you exercises that are too hard. We like to show you the practical use of something before introducing you to the theory and reasons that things are that way. That's why we keep our lessons small and varied.