Item — HN Reader

It depends. If you're building an Emacs package or extending your own customizations, having "every buffer accessible" helps, because that way LLM is not dealing with Emacs (so to say), but with Emacs REPL, that has access to everything running within it.

That however doesn't really work well with other languages like Clojure - LLM can poke into clj REPL from the Emacs REPL by tapping to it through emacsclient, in practice - these layers start leaking pretty quickly. For Clojure (or Lisps in general), you need something that changes the fundamental model of how agents work, which is roughly the Unix/pipe model. Agent spawns process -> reads stdout/stderr -> spawns next process. State lives in files. Each tool invocation is stateless. This works for languages with batch-style toolchains (compile, test, run - pretty much any non-lispy lang). An agent that edits files and re-runs `clj` is doing something fundamentally different from what a Clojure developer does.

For Lisps, you need persistent nrepl connection, eval-in-namespace as the primary tool, ability to inspect live values, hot-reload awareness - not "run clj test and parse the output". For that you need specialized MCP. There are plenty of existing solutions. I built mine in Clojure (in babashka)¹. But that's because I use Emacs. If I was using VSCode, I'd probably use BackSeatDriver²

The main point is - Lisp REPLs are great and powerful, and there's no significant obstacle not to utilize them with LLMs. If you're using a homoiconic language and not utilizing the full power of the REPL, really, why?

---

¹ https://github.com/agzam/death-contraptions/tree/main/tools/...

² https://github.com/BetterThanTomorrow/awesome-backseat-drive...

1 comments

Thank you for sharing. I never played with Clojure before but I’m very intrigued by this repl driven workflow from an agentic perspective given it changed the nature and relationship to the program/code.

I’ll look into the links and mentioned programs. Thank you.

I've been programming for over four decades as a hobby and more than twenty years professionally. I have gone through dozens of languages and still trying to learn more. Getting into Clojure still remains one of the best decisions I made in my life. I don't know why mainstream programming media - publishers, meetups, major conferences don't talk about Lisp (as if it doesn't matter at all). Common Lisp perhaps has created this aura of elitist culture (similar to Haskell) - "you have to be this tall to ride this rollercoaster", etc. Turns out, Lisp really is not that difficult. You don't need years of accumulated knowledge to start programming in it. If you know just a single mainstream PL - you already have almost everything you need to start, because pretty much every single programming language has been influenced by Lisp.

And Clojure, unlike Haskell, is way more down-to-earth and enormously practical. I'm not saying Haskell is not, but let's be honest, for anyone to start writing production-grade Haskell would take weeks, not hours. While Clojure needs minutes. These days you can just download the Calva VSCode extension and start playing with it.

Even if one thinks "there's just no way to use it at work", there are so many smaller things they could use it to improve their personal workflows. "Of course, when you only know a hammer, everything looks like a nail", someone might say. Yet, for me, who has seen, learned and used dozens of different "hammers", this one does look quite interesting. For a bunch of pragmatic reasons. And my message to any "hammer-wielding craftsman" - you really don't need to try dozens of hammers to see the value in a good one, and Clojure is a pretty darn good one, I promise.