Fork me on GitHub
#clojuredesign-podcast
<
2024-02-15
>
nate22:02:37

Have you ever tried to handle one more case only to end up refactoring your entire approach? In our latest episode, we throw our code in a loop, and it throws us for a loop. https://clojuredesign.club/episode/111-loopify/

nate22:02:23

Have you used a single-map application state?

Jason Bullers15:02:14

What you ended up with in this episode with a context object that plays nicely with looping reminded me of this: https://lambdaisland.com/blog/2020-03-29-coffee-grinders-2

neumann01:02:03

@U04RG9F8UJZ Oh yeah! It's pretty similar! Nice find. Our think-do-assimilate pattern came from a coding pattern we first used back in 2018.

Jason Bullers02:02:46

I guess in a sense, this is maybe a candidate for "functional design pattern" in the GoF sense: different people sort of arrive at the same shape of solution by applying principles

neumann06:02:21

Good point!

nate18:02:49

I think what the article ended up with at the end was similar to what we talk about as think-do-assimilate (albiet without the assimilate). One big difference I see is that in think-do-assimilate, the top level function (with the loop) is responsible for ensuring that there's a separation between each of the phases. In coffee grinders, each handler is left to perform think-do-assimilate on its own. That means each one should have a try/catch block for unknown errors (as opposed to our loop which can have just one at the top). I think that think-do-assimilate, with it's emphasis on super-simple small I/O "do" functions, encourages more strict boundaries between pure and impure code. As always, these are tradeoffs to be considered. Either one works well.

Jason Bullers16:02:38

I (think) I see. It's going to need to roll around in the back of my head a bit, though