PurelyFunctional.tv Newsletter 399: is more layers better?
Issue 399 - October 12, 2020 · Archives · Subscribe
Clojure Tip 💡
is more layers better?
Chapters 8 & 9 of Grokking Simplicity, my book on functional programming, are all about stratified design. In stratified design, we learn to build our software up in layers.
One psychological challenge that I face constantly as an author is the ever-present fear that people will take my recommendations too far. I keep thinking of examples like Design Patterns where people definitely take them too far. What if someone reads my stratified design chapters and starts telling everyone "Eric says more layers are better?"
As we talked about last week, I'm more interested in the right layers than in more layers. I don't recommend adding in layers for no reason. The idea is to find a layer that makes the layer on top easier to write. A few powerful layers can get you really far.
But I'm positive people are going to read my chapters incorrectly and learn the wrong thing. It's inevitable. I've written enough online, and read enough old ideas from the original sources to know how much ideas can be distorted.
Some people might tell me "so what if people misinterpret you? Ignore them!" But they're my readers. I have to care about them or what's the point of writing a book? So the only solution I can see is living within the tension between fear and care. And then keep writing.
Awesome book 📖
When the ideas of the Agile Manifesto started making their way through the industry, they came by way of a ray of hope. Programmers were tired of what is now called waterfall. Process was King, and he was a despot.
Agile whispered of the existence of a better way. Finally, we could focus on delivering good software instead of clinging to a bureaucratic process. In my experience, the current state of the industry is far better than it was in the old waterfall days. But in many ways, we traded one big document of requirements for lots of little documents of requirements (called tickets or stories). It was an improvement that came with, ironically, a lot of fear of process and a lot of process to fear.
I read Shape Up with a lot of hope mixed with cynicism. For all the process phobia that Agile brought, what people call Agile these days is very prescriptive. But does it do what it says on the tin? Does it help us deliver value? The process doesn't seem to encourage good software. It encourages incremental changes to software and hopes that someone is steering it toward value. But in my experience, with the common tools and processes, it's so easy to write stories that the ticket system is flooded with poorly thought-through ideas. And the programmers are too busy trying to keep up to think, either.
Is what we need a new process? Less process? More thought? More space for programmers? Shape Up describes a new process with a lot more up-front thought and that gives a space for programmers to build in value and quality. I like this process. But I wonder if we can all count on it. It requires very thoughtful leadership and a lot of trust. Can we hope for that?
Quarantine update 😷
I know a lot of people are going through tougher times than I am. If you, for any reason, can't afford my courses, and you think the courses will help you, please hit reply and I will set you up. It's a small gesture I can make, but it might help.
I don't want to shame you or anybody that we should be using this time to work on our skills. The number one priority is your health and safety. I know I haven't been able to work very much, let alone learn some new skill. But if learning Clojure is important to you, and you can't afford it, just hit reply and I'll set you up. Keeping busy can keep us sane.
Also, if you just want to subscribe for a paid membership, I have opened them back up for the moment. Register here.
Stay healthy. Wash your hands. Stay at home. Wear a mask. Take care of loved ones.
Book update 📖
You can buy Grokking Simplicity and use the coupon code TSSIMPLICITY for 50% off.
I've completed the content for the book. There are still a few rounds of revisions left, but the book is written. And the layout and other finalizations for print are still pending. No promises, but the publisher is optimistic that it will be published before the end of they year.
It would really help me out if you could let Manning know how important this book has been for you, if you've read the early access version. A good way to do that would be to Tweet at them. The best is if you write it yourself. Or you can click here for a pre-written Tweet.
Clojure Challenge 🤔
Last week's challenge
- Guitar frets - submissions
Please do participate in the discussion at the submission links above. It's active and it's a great way to get comments on your code.
This week's challenge
Digit search
This is one of those weird programming puzzles with no real point except practice. But it's considered Very Hard in JavaScript. Let's see how we do in Clojure.
Write a function that takes a sequence of integers. You're tr
ying to
get all 10 digits by looking through the numbers sequentially. When you
have found one instance of every decimal digit, return whatever number
you were on when you found the last one. If you get to the end of the
sequence without finding all the digits (for instance, maybe there was
no 9), then just return nil.
Example
(digit-search [5175 4538 2926 5057 6401 4376 2280 6137]) ;=> 5057
;; digits found: 517- 4-38 29-6 -0
(digit-search [5719 7218 3989 8161 2676 3847 6896 3370]) ;=> 3370
;; digits found: 5719 -2-8 3--- —6- ---- —4- ---- ---0
(digit-search [4883 3876 7769 9846 9546 9634 9696 2832]) ;=> nil
;; digits found: 48-3 —76 ---9 ---- -5— ---- ---- 2---
;; 0 and 1 are missing
Thanks to this site for the challenge idea where it is considered Very Hard level in JavaScript.
Please submit your solutions as comments to this gist. Discussion is welcome.
Rock on!
Eric Normand
