This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2024-03-06
Channels
- # babashka (60)
- # beginners (36)
- # clj-kondo (29)
- # clojure (91)
- # clojure-dev (18)
- # clojure-europe (12)
- # clojure-nl (1)
- # clojure-norway (11)
- # clojure-uk (5)
- # clojuredesign-podcast (8)
- # clojurescript (40)
- # core-typed (74)
- # data-science (8)
- # datomic (9)
- # emacs (22)
- # events (5)
- # fulcro (56)
- # gratitude (3)
- # hyperfiddle (11)
- # lsp (6)
- # malli (36)
- # meander (23)
- # off-topic (50)
- # polylith (4)
- # portal (10)
- # reitit (4)
- # schema (1)
- # shadow-cljs (66)
- # squint (3)
- # tools-deps (16)
In episode 113, you talk about "all the little pieces that emerge [while exploring and fiddling]," and during that process, you "discover" the production code. As a bottom-up thinker and tinkerer who needs to try things out to learn and gradually arrive at a solution simultaneously, I love, love, love your approach here. However, simultaneously, it feels a bit antithetical to “hammock-driven development” and the “think-a-lot-and-design-before-coding-heavy process installed in the Clojure community by Hickey. It seems somewhat ironic that Hickey designed a language where interactive programming is encouraged, given that philosophy. Am I wrong to think those are opposed, bottom-up vs. top-down approaches, or are they complementary? Might the ad-hoc and exploratory nature of “fiddle-driven development” lead to poorer design decisions? I’m just thinking out loud here and would love to hear what others think.
I'm not sure how to link to a specific part, but search for "exploratory programming", https://github.com/matthiasn/talk-transcripts/blob/master/Hickey_Rich/DesignInPractice.md
> So we all know, I am just reminding you, Latin for "design" means "not being allowed to code". > I do not actually think that is true. In fact, I think that as we will see as we go through the talk that you do coding throughout the design process. Not necessarily starting to write your system, but exploring what your system might become, learning about the things that are going to be parts of your system, answering questions, and things like that. And it is one of the reasons why I think it is important to work in a language where that kind of work has zero project-y kind of overhead. That you do not need to have started your thing, or be in a project context to start doing exploratory programming. You open up your editor and you go.
I think the rationale is that step 1 is understanding the problem and exploratory programming is a great tool (among others) for learning about the problem.
This type of exploratory programming is common in clojure code bases and goes under the punny name "rich comments": eg. https://github.com/clojure/clojure/blob/f06ef8ad0b3d3ca5cbea64f55e416de1065a65e0/src/clj/clojure/zip.clj#L281
Thanks for reminding me of those excerpts from Rich's design talk, @U7RJTCH6J! I had forgotten about those.
@U01PE7630AC I agree with what @U7RJTCH6J is saying about "learning about the problem". Bottom-up, exploratory programming is all about getting a really clear sense of what you are working with so that your "hammock time" is grounded in reality. The real-world is messy, so I find myself going on walks to figure out how to bring things together. That time is most productive when I have a lot of accurate information to work with.
I love how I can have a "working codebase", but fire up a fiddle to explore a whole new part. I can do that exploration just as freely as if I was starting from scratch. After I figure that new part out, I can start to weave it into the existing thing. That's a superpower in Clojure!