Dealing with Haskell errors, and how 3G works so well
We learn to read Haskell errors by example, and then we find out which sequence of coin tosses is most likely – and what that has to do with 3G cellular communication.
Hello! I hope your week is going well.
New articles
Reading GHC Errors
Getting a compiler error when working with Haskell is not a slap on the wrist; it is an ongoing conversation between programmer and compiler, where they together try to work out what the programmer really intends to do. Once that conversation is over, the programmer has a pretty good idea of what they want to do, and thus is more likely to have done it correctly. ("If it compiles, it works.")
Reading these error messages can be hard for beginners. Here, we look at a few that came up in one brief work session, and see how to read them.
Full article (5–20 minute read): Reading GHC Errors
Flashcard of the week
When tossing a single coin, we get either heads or tails with equal probability. When tossing two coins, we get either all heads, or all tails, or one of either. I think most of us would agree that "one of either" is the most likely outcome. As we increase the number of coins we toss, we'll find that most often, we'll get a sequence with roughly equal numbers of heads and tails.
This is a consequence of combinatorics: there are only 50 ways we can arrange 50 coins of which one is heads, but there are 126410606437752 ways we can arrange 50 coins of which 25 are heads. So if we are given a random sequence of 50 coins, it is much more likely to be a configuration where half the coins are heads, than it is a configuration where only one coin is heads.
Of all the possible coin flip sequences of 50 coins, there is a subset which are called the typical set, encompassing these most likely sequences. I have two flashcards on the typical set, which illustrate two of their properties.
The typical set is large enough that ...
I already sort of gave away the answer to this.
... it contains almost every sequence encountered in practice.
But then we also have the more difficult question.
The typical set is small enough that ...
The answer to this isn't strictly true for 50 coin tosses, but it becomes true when we extend to infinite sequences.
... all elements are equally probable.
This is known as the asymptotic equipartition property. For any sequence of random values, we can pick out a typical set that encompasses all sequences we'll see in practice, and this set is still small enough that each entry has effectively the same probability.
In principle, this can be used to very efficiently compress data: if we assign a code to each element of the typical set, we will have relatively short codes, but we can still cover all the sequences we'll encounter. Actually doing this in practice turned out to be very difficult. It has been known to be possible since Shannon in 1948, but it is only in the 1990s with the emerging 3G cellular technology that we made the leap and got close to this level of compression. (The information theory community reacted with disbelief at first, but today it powers much of the most impressive radio communication technology we have.)
Premium newsletter
The next premium newsletter is in the making! It will contain the usual, and a review of Code That Fits in Your Head: Heuristics for Software Engineering. If you're interested, a premium subscription is currently only $2/month, cancelable at any time, no questions asked.
That money also gets you the past issues, including the most recent one, which has a list of the 20 best books I've read, along with brief summaries, and pointers on how to make such a list of your own. (It's harder than it sounds.)
To upgrade, click the subscription link at the top of this newsletter and fill in your email again.
Your opinions
I cannot improve without feedback. Reply to this email to share your thoughts on any of the topics above, or anything else!Hello! I hope your week is going well.