#clojure/15 entries

One of the main ways I work with AI since I had a baby 5 months ago is prompting genies from my phone while I'm naptrapped or breastfeeding (did you know newborns feed for ~5 hours per day?! I did not). It’s very sweet and cozy napping with a baby but eventually also boring.

Anyway it’s very cumbersome to review code when building things this way, but I decided that’s mostly fine since for a lot of little personal utilities I have it build I don't really care whether the code is particularly good or not (although I do find lately it writes perfectly passable Clojure, still my language of choice in this age of AI).

I always have it set up CI from the start so the project ships somewhere I can try it out from my phone and give feedback, but sometimes the tools are CLIs or other utilities I want for when I'm back at my desk. In those cases I have Claude write a book about how the project works for me, then I give feedback based on that about what needs to change (either in the project itself or just the prose). The result is that I understand the project and end with an edited book I can reference as documentation. This has been working great for me and has been resulting in many useful personal tools that I'm really enjoying building and using.

To make the process of giving feedback on books (or any other text) easier, I had the AI build itself this little annotation tool. It lets me paste a link in (to e.g. one of the deployed book chapters), then I can highlight particular passages and copy the feedback in a way that is easy for a genie to act on. You could use it for anything that requires taking notes on specific passages of a webpage though.

I've been thinking about versioning (for work) lately and I'm reminded of Rich Hickey's take on it from his Spec-ulation talk. The gist of it is that it’s more useful to think in terms of breakages and accretions as opposed to the more vague notion of “versions”. He (perhaps controversially) suggests that breaking changes should just be considered new things, the concept of having a new “version” of something that is not compatible with the old one is incoherent if you think about it.

Rich Hickey just pushed a new namespace to the core.async library that looks really interesting. The accompanying rationale explains what it's all about in simpler terms than the code, but it feels like a big step forward in making core.async more intuitive to use. Channels are a super useful abstraction, but as the rationale explains, they are still a relatively low-level construct that require expertise and good architectural decisions to use well. This new namespace provides some more abstractions on top of channels that handle, among other things, "all channel I/O, thread lifecycle and coordination with the flow graph". This seems very powerful.

These are very high-level abstractions over an entire system, but I often wonder if this is just the inevitable direction in which software is headed. As we come to understand software systems better and better, and as the tools for generating implementations of solutions to known problems become better and better, it seems like this shift toward ever higher-level abstractions is the natural outcome.

It reminds me a bit of what Hyperfiddle is doing with electric Clojure, abstracting over the entire network, not just the "front" or "back" end of a web app. It's a totally different domain, but similar in that it feels like an impossibly high level to develop at, yet it appears to work very well. I'm excited to out both of these.