The most infamous two letters of our time - humans do not like machines, and absolutely hate those who do.
> I voiced a valid concern
Not unwarranted. When you treat a homoiconic language just like any other, LLMs do sometimes get messy with paren-balancing, but most models correct it on a second-third try. You still get some benefits - e.g., Clojure is the most token efficient mainstreamish PL.
To get the most benefit from it, one must teach the model to treat it just like a human programmer would. It makes no sense to treat Clojure like Python or Go, or C - it's like ordering a pair of swim fins and jumping into water with the unpacked box. Lisp dialects shine when you use the REPL (true Lisp REPL - not some faux-repl like Python's), so you have to "teach" the model a way to operate the live REPL, not passively reading/writing "static" code that's fed into it batch-style. When you do that, models not only get much better grasp of where the syntactic elements should be, they start reasoning about the program in a way more interesting fashion, empirically evaling pieces on the fly, interactively - without juggling state, without compiling, without even having to save things (until proven to work).
Does that make Clojure "the best LLM-suited PL"? Not really - there's simply no such thing. For sure though, the homoiconic nature of the language absolutely makes it enormously interesting and well-suited for it.
I bet you're just treating it like any other (non-homoiconic) language. An agent that edits files and re-runs `clj` is doing something fundamentally different from what a Clojure developer typically does. When you give the agent a REPL - things get far more interesting.
Well, that's not how a Clojure dev normally would write it. If you're not using the REPL (with or without AI) - you're missing the point/misusing the tool. Therefore "remains shockingly bad" perspective is unfair - it's like using a screwdriver to remove nails while complaining that it keeps bending.
I'm happy to hear any thoughts you have on the best way to make use of it. Presently I use emacs and cider but I'm not altogether unhappy with IntelliJ or VSCode
So yes, you're already using Clojure REPL with CIDER, right? Then why not make AI use it as well? You can do that directly from Emacs, with ECA¹ for example. Which on its own won't change anything - it still be in that batch-style mode - LLM spawns process -> reads stdout/stderr -> spawns next process. What you'd need on top of that is an MCP that "understands" nrepl. You can find many different ones, I built my own (written in Clojure, runs with babashka)²
Alternatively, you can use Dmitry Sotnikov's agentic tool³. Dima is a well-known Clojurista (with published books, etc.) I have not tried that myself because I prefer staying in Emacs, but it might be even easier choice for someone else.
It's okay when you use it just like any other PL, which is roughly the Unix/pipe model - batch-style. Agent spawns process -> reads stdout/stderr -> spawns next process. State lives in-between the calls and in files. Each tool invocation is stateless.
Things get far more interesting when you give an LLM a true Lisp REPL. LLM stops guessing and starts empirically analyzing current state of things and produces working solution faster, costing far less tokens. And you get to watch it solve things interactively, e.g. I often let AI poke through our UI (via Playwright-driven Clojurescript REPL), while monitoring situation in k8s - through nrepl port, connected to Clojure REPL.
Oh, come on. I get when people complain about AI-assisted writing. It's mostly about signal-to-noise. Yes, AI makes it trivially cheap to produce "correct but empty" content - articles that are technically accurate, well-structured, and say absolutely nothing a reader couldn't get by prompting an LLM themselves.
Yet sometimes you do need to see a genuine human struggle, ideation, and a real problem behind the article. Let's try not be dismissive off the bat. I understand your style objection is a proxy. Your actual complaint is probably the feel of absence of a specific, earned perspective. Perhaps, it "doesn't speak to you" because you have not encountered the overlapping problems that article may help you with.
That isn't prose - it's educational, informational, well-structured and has code snippets. Let's not devalue someone's genuine work only because they decided to use AI-assistance - there could be legit reasons, from language barrier to lack of time. Good writing is hard. With and without AI. Not everyone commands the skill of writing, let's not rob them of the opportunity to cultivate it. Sometimes, it starts with dull, spiritless paragraphs.
Really? I've used dozens of languages and honestly, I just can't wrap my head around how ugly Lua code can get. At first, I tried treating it as "javascript with no bad parts", turns out, modern JS is far, far better than 1996 JS and nicer than Lua. The most annoying part about Lua is that I never know how to format it for better readability - should I add line breaks, or not, etc. lua-fmt often just makes it worse.
When I found Fennel I immediately moved to it, even though it was "experimental". Since then, I just don't want to deal with Lua, aside from some small one-liners.
> Lisp from my understanding is incredibly polarizing
No it's not! It's as "polarizing" as "group theory" or "set theory". Lisp is fucking math - it maps closely to formal mathematical/logical notation. You just can't "hate" math - you can be confused by it, be unfamiliar with it, intimidated by it. But hatred directed at something that is simply precise and consistent says more about the person than the thing.
This is basically a reoccurring theme on every programming forum, whenever a Lispy PL gets mentioned. There are tons of confused programmers who look at Lisp examples and "hate" it. Without a single practical experience of using Lisp. They don't know anything about structural editing, they never experienced REPL-driven development. And I'm not talking about shit like "Python REPL", which is a bleak attempt, a shallow shell compared to the "true Lisp REPL".
It takes a bit of time and curiosity to realize how enormously powerful, beautiful and practical the idea of Lisp is. And it's really sad that smart people refuse it outright, without even attempting to understand it. Sure, it may take some time to discard the old habits that took years to build and accept this unfamiliar thing. Yet there's a point, after which comes the realization that Lisp can literally replace every single programming language with better ergonomics. I'm so mad at myself for wasting huge chunk of my life, chasing things of lesser importance, instead of just figuring out Lisp sooner.
I guess, to a degree you're right - you either hate Lisp or love Lisp, there's no in-between. But "hate" means you simply don't know it. Once you do - there's no way not to fall in love.
Of course easier to explain the "strategy pattern" to a florist, instead of saying "imagine a function that takes a function". Who the hell understands functions? Such a mind-bending concept, literally nobody really knows how they work. Einstein famously complained about it. Too bad he didn't know OOP - would've been so much easier. I couldn't grok general and special relativity for so long, thank god I've found Java - it made it so much easier. I don't know what Persian mathematicians been smoking in 12th century to come up with this utterly fucked up idea of a function. And fuck Leibniz as well.
This is a great comparison and I've been wondering about it for a while.
Between babashka, janet(i discovered it just now), fennel, guile.
Which one would be a better scripting language?
Please tell me you experience, and if you are interested, we can work on a small article and benchmark about this.
It's platform-dependent isn't it? Otherwise, the practical differences between Lisp dialects are negligible. For me writing either in Janet or Fennel or Clojure feels almost like writing in the same language.
Babashka has replaced bash-scripting for me. I don't hate Bash, but why would I ever choose to use a language that has no true REPL, if I don't have to? bb is pretty much Clojure, which is the greatest choice if you're dealing with data - any data. Clojure is incredibly data-driven, which wins me over Janet. I also reach out to nbb whenever I need to deal with Node. e.g. scraping scripts driven by Playwright.
Janet is great when you need tiny runtime or you're dealing with subprocess-heavy scripts - Janet feels closer to actual shell syntax; or when you have to embed it to C/C++ program.
Fennel is indispensable for any Lua - mpv, Hammerspoon, AwesomeWM and Neovim configs, etc.
> Clojure is incredibly data-driven, which wins me over Janet.
I'm curious what differences you see? I've been all in on Janet, but barely used Clojure. What more data driven aspects does Clojure have .... offer? My mental model/assumption's always been that Janet's Clojure without JVM and (sadly) not so pure. I don't use any of Janet's C interop facilities. I'd love to know what I'm missing
afaik, Janet's immutable structs/tuples are flat copies - no structural sharing. Clojure uses HAMTs. So it's truly immutable by default - you'd transform data without intermediate allocations.
In Clojure, the standard library already knows about your data - it has the tools to group, index, validate, serialize, and transform maps/vectors/sets without you reinventing them. In Janet, you have the building blocks but it feels like you're assembling the furniture yourself.
The trade-off is that babashka adds ~200ms to cold start and can be pretty memory hungry, but god, Clojure is so nice to deal with data. For small scripts it may not matter. For processing log files or CSVs with millions of rows, it does.
this is good to know :) my use for janet hasn't involved much processing of external data but i'll keep bb in mind when the use case arises. thank you for the information!
True. But for things that they all can do, normal scripting (replacing bash/powershell, etc.), creating CLI and TUI apps, I would like to do a comparison of them.
1. which one is more pleasant to write
2. which one has the better echo system and tooling
3. performance benchmarks
4. portability
> studied them in school - but i quickly forgot and never got around
Because industry lied to you, promising "simplicity and riches". The industry didn't just overcomplicate programming. It institutionalized the complication. Why? Because complexity is a moat.
Complex frameworks need certified experts. Certified experts charge more. Companies built around expertise need the complexity to persist. So the complexity gets marketed as sophistication.
They've promised: "Java/C# will get you hired anywhere", but you're hired to write xml (these days yaml). "OOP models the real world", they said. The real world doesn't have abstract factory visitors. "Design patterns make you senior", but you only learned workarounds for language deficiencies. "Learn the framework, get the job". Framework dies, you start over. "Specialization is valuable". you're now hostage to one ecosystem.
A programmer who understands fundamentals is dangerous to this system. The fundamentals:
- a function transforms input to output.
- composition builds complexity from simplicity.
- types describe what's possible.
- effects should be explicit.
And then you realize that Lisp is the skeleton key. All that above is Lisp, or came from Lisp. Every language is either: Lisp with different syntax, or C with different syntax, or arguing between the two.
If you learn Lisp, you don't learn a language. You learn what languages are. You're no longer a consumer of a programming language or two, or a few. You are native speaker in all of them.
The most infamous two letters of our time - humans do not like machines, and absolutely hate those who do.
> I voiced a valid concern
Not unwarranted. When you treat a homoiconic language just like any other, LLMs do sometimes get messy with paren-balancing, but most models correct it on a second-third try. You still get some benefits - e.g., Clojure is the most token efficient mainstreamish PL.
To get the most benefit from it, one must teach the model to treat it just like a human programmer would. It makes no sense to treat Clojure like Python or Go, or C - it's like ordering a pair of swim fins and jumping into water with the unpacked box. Lisp dialects shine when you use the REPL (true Lisp REPL - not some faux-repl like Python's), so you have to "teach" the model a way to operate the live REPL, not passively reading/writing "static" code that's fed into it batch-style. When you do that, models not only get much better grasp of where the syntactic elements should be, they start reasoning about the program in a way more interesting fashion, empirically evaling pieces on the fly, interactively - without juggling state, without compiling, without even having to save things (until proven to work).
Does that make Clojure "the best LLM-suited PL"? Not really - there's simply no such thing. For sure though, the homoiconic nature of the language absolutely makes it enormously interesting and well-suited for it.
reply