PurelyFunctional.tv Newsletter 454: Not a prescriptive process

Issue 454 - December 13, 2021 · Archives · Subscribe

Design Idea 💡

Not a prescriptive process

This essay continues the series about Domain Modeling.

On December 04, I presented a 25-minute version of the organization of my notes on Domain Modeling. It was good to synthesize the information into a presentable form.

I'm glad I gave the talk and learned important things. And I'm grateful to the audience for being a sounding board for incomplete ideas. It really does help to know how my material will be received before I commit to it. I learned that there is a great desire to do better design, at least among programmers.

However, I made a bad choice to present the bulk of domain modeling as a process with discreet phases. I wanted to give a concrete example of how you could use the skills of domain modeling. This presentation gave the impression that I was suggesting a process, which was not my intention.

During the Q&A, most of the questions were about process. They were about how to fit it into the normal sprint cycle, or how long to spend on each phase, or how to convince your manager to let you do the phases. I don't have answers to these questions and it is not what I want the material to be about.

The material I'm preparing is a set of skills and perspectives, not a process. I believe that someone equipped with these skills will tend to write simpler code. They will recognize sources of complexity stemming from a model that does not fit reality. They will have a large tool belt stuffed with useful ways to construct models. And they will see dimensions of the problem that others might not, such as volatility and generality.

I find it valuable to list out operations and their signatures before exploring a data structure. That suggests putting the more abstract signature skills first. And that's how I presented it. There's so much you can learn from your signatures and their properties that will help you when you have to make concrete decisions about data representation. And it's cheaper to modify the design when it's just function signatures, not implementations. I wanted to show that, so I broke it roughly into phases so we can progress from abstract to concrete.

However, that is exactly the opposite of the direction you should take when teaching. You should start with concrete and progress to abstraction. And, in fact, thinking in signatures depends on the skill of data modeling. I couldn't think abstractly without confidence that I could find an appropriate data structure later. That means data modeling is more fundamental. Putting it first makes sense.

Now I'm organizing it more along the lines of what to learn first. And, luckily, that order removes a huge amount of tension from the material. Data modeling is valuable in its own right, so if someone stops reading after the data modeling section, they have learned a useful skill.

It's funny how, as we learn more, we tend to put emphasis on the less fundamental, deeper skill, even though the more fundamental skill is more important. For example, people spend chapters and chapters on monads, hailing them as the best thing ever. But they only have a paragraph on pure functions. Which is more important (especially to a beginner)?

Well, it appears I was falling into that same trap. I'm grateful to the re:Clojure audience for being a sounding board. I've decided that I have enough notes and sketches to start slowly crafting the material. I still don't want to commit to a book yet. But I will publish the pieces on my blog as I finish them. I would appreciate any comments you have. I hope you will enjoy the process of helping the material become the best it can be.

Book update 📘

I wrapped up Grokking Simplicity about this time last year (though it wasn't published until March). Since then, I've gotten so much positive response to it that it makes it all worth it. Thanks so much to all of my readers :)

You can order the book on Amazon. Please consider leaving a rating and/or review. Reviews are a primary signal that Amazon uses to promote the book. And they help others learn whether the book is for them.

You can order the print and/or eBook versions on Manning.com (use TSSIMPLICITY for 50% off).

Pandemic 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.

Stay healthy. Wash your hands. Wear a mask. Get vaccinated if you can. Take care of loved ones.

Clojure Challenge 🤔

Due to a technical error, I failed to include this challenge in the newsletter last week. Sorry! Here it is now.

Last issue's challenge

Issue 452 -- Consecutive numbers -- Submissions

This week's challenge

Backspace jam

Let's say we have users typing keys on the keyboard. We capture the characters they represent in strings. However, sometimes the user hits the backspace key, which removes the previous character. We will represent a backspace key press with a # character. Write a function that applies the behavior of backspace to the string.

Examples

(apply-bs "abc#") ;=> "ab"
(apply-bs "abc###") ;=> ""
(apply-bs "###abc") ;=> "abc"
(apply-bs "there###eir") ;=> "their"

Thanks to this site for the problem idea, where it is rated H ard in Java. The problem has been modified.

Please submit your solutions as comments on this gist.

Rock on!
Eric Normand