Sigh... monty hall. And functional programming!
We learn an intuition for the Monty Hall problem that is actually intuitive, in contrast to all other intuitions. At least I think so. We also look at why functional programmers get by with less formal verification.
Hello! I hope your week is going well.
New articles
Intuiting Monty Hall
I know. The internet does not need yet another Monty Hall intuition article. BUT! Other people's intuitions are not intuitive. This one, I think, is. And I have not heard anyone else discuss this perspective.
The way I approach it is by first setting up the problem in a shape where people's intuitions are correct (doesn't matter whether you switch doors), and then we processually, slowly, modify the premise into the actual Monty Hall problem. This shows clearly how the counter-intuitive solution works (switching doors causes you to win more often).
Full article (3–8 minute read): Intuiting Monty Hall
Flashcard of the week
I think I got this from reading the first few pages of Algorithm Design with Haskell, although I'm fairly confident the book does not say this specifically – this is my own hyperbole.
Why can pure functional programmers get by with less formal verification?
Formal verification is that thing where we print out our code on paper and then take a pen and write Hoare triplets on every statement, specifying assertions we think are true when the statment starts executing, and assertions we think are true when the statement has finished executing. If all assertions line up, then the program does what we intended it to.
There's a whole book of standard rules that can be applied to help make sure everything lines up. It might sound and look complicated, but even doing it at a basic, sloppy level can reveal a bunch of bugs in the code. It's a neat way to work.
But somehow, pure functional programmers don't need to do it as often. The reason is that
They can use equational reasoning instead.
This is, I think, one of the strongest arguments for equational reasoning I've come across. As fun as sloppy formal verification is, it's still very time consuming and it's not a process humans are good at. Non-functional programmers need it because they mutate state all the time, and mutable state means, quite naturally, that the current state of the program is implicit to the programmer. It has to be dynamically figured out. It's not visible from the code alone.
In contrast, pure functional programming has much less mutable state, and if we want to know the value of something, we can "just" replace it by its definition. We can keep doing this until we are sure we have what we think we have. Humans are great at symbolic manipulation and understanding what a synonym is!
Premium newsletter
The latest premium newsletter went out a few weeks ago.
It had a preview of a future article, a review of Code That Fits In Your Head, links to two of my favourite text adventures you can play for free, and a few more web links. To get access to it, a premium subscription is currently only $2/month, cancelable at any time, no questions asked.
That money also gets you the past issues, which total five longer book reviews/summaries, 22 brief book recommendations, forecasting/world modeling tips, and around 12 great web links.
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.