PurelyFunctional.tv Newsletter 340: Fewer side-effects is better than more
Clojure Tip 💡
Fewer side-effects is better than more
You probably know that if a function doesn't have any side-effects, it is considered pure. When a function is a pure function, it can be used without regard to when it is called or how many times it is called. It makes parallel programming easier, it makes testing easier, it makes higher-order operations easier.
However, is it better to go from 2 side-effects down to 1? The benefit is not so clear. You're not into pure function territory, but you've made things easier. What about from 10 down to 9? Certainly, if you can go from 10 to 0, you're in the functional programming sweet spot. But do you get benefits for having fewer side-effects if you can't get down to zero?
I believe that you do. It is better to have fewer side-effects, even if you can't get down to zero. Zero is the magic number, but 1 is better than 2. The same benefits apply: a function is 1 side-effect is easier to make parallel, easier to test, and easier to use in higher-order operations, than a function with 2 side-effects. That means it's worth it to refactor even if you can't go all the way.
Awesome book 📖
Apollo: The race to the moon by Charles Murray and Catherine Bly Cox.
What an adventure the Apollo program was! This book was first published in 1989. It tells an amazing story of engineering skill and organizational genius that went into building, testing, and commanding the Apollo missions. It focuses much less on the astronauts and much more on the politics and engineering. I really loved to learn about how the major decisions were made and how mission control came to be.
One last point: I'm not sure about the pedigree of the authors---Murray also wrote The Bell Curve, which is a pseudoscientific racist screed. I didn't know that before reading Apollo, but I wish I had. I didn't notice anything amiss save for perhaps the description of the german rocket scientists and their relationships to the Nazi party. They received very little attention in the book, but if I were to read it again, I'd take everything about them with a grain of salt.
Book status 📖
The book's title has changed and it now has a cover. It used to be called Taming Complex Software. Now it's Grokking Simplicity.
It's still not available yet. You can check out the cover, watch me read the first reviews that have come back (they're positive!), and sign up to learn when it launches. Click here.
Currently recording 🎥
I am now recording 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. Of course, PF.tv members have had access since the beginning, along with all of the other courses.
New lessons this week include:
- Behind the scenes: shrinkage --- in which we shine a microscope on the shrinkage process and watch it happen, step-by-step. Shrinkage is how test.check reports useful failing cases. Without shrinkage, the failing cases would be too big and random.
- Building complex generators: mutation testing --- in which we generate values that are almost correct.
Last week I said that there were three more lessons for properties, and here I am showing you only two. I reviewed the notes for the third one and I had already covered everything. Soon we're going to get into real testing examples. But before that, we have to talk about shrinkage.
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 7 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 339 was to write a symbolic differentiator.
You can check out the submissions here.
This week's challenge
symbolic differentiation, pt 2
Now that we've got a basic symbolic differentiator (and the numeric one), we could simplify the expressions. SICP gives some basic simplifications.
(+ 0 x) => xor additive identity
(* 1 x) => xor multiplicative identity
(+ 1 2) => 3or constant simplification
(* 3 2) => 6or constant simplification
Here's the relevant link into SICP, for reference.
The challenge this week is to integrate these easy simplifications into the differentiator. If you didn't do last week's challenge, grab someone else's code and work from that.
As usual, please send me your implementations. 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.