PurelyFunctional.tv Newsletter 451: Signature-Driven Development

Written by Eric Normand. Published: November 15, 2021.

Issue 451 - November 15, 2021 · Archives · Subscribe

Design Idea 💡

Signature-Driven Development

This essay continues the series about Domain Modeling.

My friend Bert coined the term Signature-Driven Development while I explained my ideas about FP and modeling. He said that given the signature, writing the body of the function was often straightforward. But he couldn't come up with the signatures I did. That's where the style/skill/paradigm was a mystery to him since he wasn't a functional programmer.

For example, it seemed weird to him for an operation on a shopping cart to take a shopping cart and return a shopping cart (and further to call that "modifying the cart"). He said that never in all his tries would he have thought of that signature. That's a good indication that a lot of the book will focus on coming up with those signatures. Further, when I get the signatures right, it does feel like the implementations are obvious.

It is valuable to spend time working only with signatures (and trivial combinations of them). A signature is:

the name of the function
the names and types of the arguments
the return type

Those pieces of information are more abstract than any possible implementation when done right. You could do it wrong. For instance, the function's name could restate the intended implementation. But done right, the name elevates the function to the right semantic level, likewise with the arguments' names and types. In other words, you're working with meaning, not mechanism. That's the right place to be to think algebraically.

Book update 📘

I wrote Grokking Simplicity because I couldn't find a book for beginner functional programmers. People kept asking what book I recommended and I had no answer. Through countless discussions about what functional programming is and what its value is, I refined the idea of actions, calculations, and data. That idea became the core of the book. I've received lots of messages from people saying that idea was instrumental in their understanding of functional programming. It's very rewarding.

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

Upcoming presentation 📢

December 4th I am speaking at re:clojure 2021. I'm pre-recording my talk this year because last year my internet cut out during my talk.

It's all online so see if you can attend, too! It's all free!

Podcast episode🎙

In my new episode, How far can we stretch technical debt?, I explore the metaphor of technical debt and how it breaks down when we stretch it.

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 🤔

Last issue's challenge

There was no challenge last week.

This week's challenge

Ulam sequence

The Ulam sequence is an interesting mathematical sequence of integers. It starts with [1 2]. At each step, the next element is:

not already in the sequence
a sum of two previous elements
the number must be produced by only one sum
the smallest in case there are multiple candidates

Let's walk through an example.

As we said before, the first two elements are 1 and 2. Those sum to 3, and there's only one way to get it, so 3 is the next element.

[1 2 3]

Now, there are 3 possible sums: 1+2=3, 1+3=4, and 2+3=5. 3 already exists, so it's out. 4 and 5 both only have one way to produce them, but 4 is smaller, so it's the next element.

[1 2 3 4]

Now: 1+2=3 (done), 1+3=4 (done), 1+4=5, 2+3=5, 2+4=6, 3+4=7. 5 is produced two ways, so it's out. 6<7, so the next element is 6.

[1 2 3 4 6]

Your task is to create a lazy Ulam sequence.

Example

(take 2 (ulam)) ;=> (1 2)
(take 5 (ulam)) ;=> (1 2 3 4 6)
(take 17 (ulam)) ;=> (1 2 3 4 6 8 11 13 16 18 26 28 36 38 47 48 53)

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

Please submit your solutions as comments on this gist.

Rock on!
Eric Normand