Functional programming is deep
I was once coaching an experience procedural and OO programmer in FP. We were writing a Solitaire game.
At some point, after we had modeled the cards and game board, I suggested we generate every possible move, then filter them for the valid ones. There aren’t that many possible moves in Solitaire, so it wouldn’t be hard. He was surprised because he had never heard of such a technique. It was at that point that I realized how different and deep FP was.
There’s nothing about procedural or OO as paradigms that would make the “generate every possible combination and remove the bad ones” approach difficult. It’s simply not widely used as a technique. But in FP, it is widely used. Why?
For one, we often have lazy lists. It’s not always practical to generate every move and store them in a giant array. However, if you can generate them lazily, it’s not so bad, especially if you can filter them quickly.
For two, we tend to work with data. When your move is represented as data, generating a lot of them in a list seems easy. However, for some reason, constructing a
Move object, then asking it whether it
isValid(), seems quite gratuitous. I’m not sure why.
For three, in FP we tend to break things down a little further than other paradigms. In this case, we are separating out the generation of moves from checking if it’s valid. It turns out it’s harder to write an algorithm to generate only valid moves than it is to generate all moves then filter them for validity.
Anyway, it was quite instructive to see what he was surprised by. It is experiences like these that remind me of how little of our collective FP knowledge is found in books, and how useless reductive definitions of FP are (like “FP is programming with pure functions”).
Book status 📖
The book has not published yet. I’m sorry I brought it up last week. I was super excited! Now I’m kind of a nervous wreck. What they’re telling me is that my book is so unique that their process doesn’t work for it. They finished the text for the book’s web page. It’s making progress.
As you may know, I’m writing a book called Taming Complex Software, which is an introduction to functional programming. It has been a long journey and lots of work, but I’ve turned in the first three chapters for Manning’s Early Access Program.
Each page of my book is laid out by hand. Instead of a lot of text, it uses a much more visual style. My goal for the book is to help functional programming escape from the ivory tower and capture what professional functional programmers actually do. And of course present that in an easily understood way.
I’ll keep you informed as it progresses.
Clojure Media 🍿
This new Q&A site looks very promising. It’s on the clojure.org domain and it’s maintained by the official Clojure team.
Currently recording 🎥
Recently, I started a course called Property-Based Testing with test.check. Property-based testing (PBT) is a powerful tool for generating tests instead of writing them. You’ll love the way PBT makes you think about your system. And you can buy it now in Early Access.
Here are the new lessons this week:
- Building your own simple generators , in which we look at how to build easy generators out of the built-in ones.
- Building complex generators: email address, in which we build two generators that generate random, valid email addresses.
- Building complex generators: matrices, in which we build two generators to build random matrices, using two different styles.
I’ve made the first and fifth lessons free to watch. Go check them out.
Members already have access to the lessons. The Early Access Program is open. If you buy now, you will get the already published material and everything else that comes out at a serious discount. There are already four hours of video, and looking at my plan, this one might be 9-10 hours. But that’s just an estimate. It could be more or less. The uncertainty about it is why there’s such a discount for the Early Access Program.
Clojure Challenge 🤔
Last week’s challenge
The puzzle in Issue 336 was to implement a few properties to test quartiles.
You can check the submissions out here.
Not many submissions this week. Are people interested in Property-Based Testing?
This week’s challenge
Soundex is an algorithm that attempts to encode two similar-sounding English words to the same value. It does this by dropping vowels and encoding consonants to numbers in a lossy way.
The algorithm is described on Wikipedia as “American Soundex”. The challenge this week is to implement Soundex.
As usual, please send me your answers. I’ll share them all in next week’s issue. If you send me one, but you don’t want me to share it publicly, please let me know.