>This is why Lisp never catches on.

>[…]The same thing happens in other languages with macros (like C and assembler).

Uh, C definitely caught on.

Common Lisp has these capabilities _without_ dev tooling, via its:

- Conditions[0]

- Evaluation and Compilation[1]

I use both extensively while developing, debugging and analysing. With SLIME (this is a standard and very very slimmed out development aid) you add a debugger hook that allows restart, return from, move down, move up and etc into your available RESTARTs.

[0] https://www.lispworks.com/documentation/HyperSpec/Body/09_.h...

[1] https://www.lispworks.com/documentation/HyperSpec/Body/03_.h...

What’s missing in most languages is truly native hot reload. Python, for all its dynamicism and being lisp for dictionaries, surprisingly can’t really do it. Maybe node can, but as far as I can tell typescript can’t and I’m not letting the shoggoths touch plain js.

You might be interested in Lean. It's my favorite lisp, even though it's really not at all a lisp. It's a nice programming language, and it lets you really hack on commands, macros, syntax, and elaboration.

One thing that has surprised me is how good LLMs are writing Lisp macros. All the annoying boilerplate and backtick-comma arithmetic (',' anyone?) that has ground my gears over the years, they cheerfully churn out correctly. I still review it to make sure they haven't done it in a needlessly complicated way, but I wonder if that is just me being superstitious.

I shouldn't have been surprised, because that part of macro writing is purely mechanical syntax transformation—just a "take these tokens and return those tokens" function that one should expect LLMs to be good at. But I was surprised, because for me that was always the hard part.

So now I can think up new macros to abstract over patterns in my code—the part of macro-writing that I enjoy—and then push a magic "implement this" button to make it work.

What I'm not sure of yet is whether this is an evolutionary dead end—a train stop on the way to "you'll never look at code again, so what does it matter what programming language you used to use". Yes, I still look at my code, and this is a pretty nice train stop, wherever the tracks lead to.

Lean is the dependently typed language with a SotA metaprogramming system. Lean itself is a language written using this system.

Have you looked into tree calculus at all?

>What you need is for your LLM to be able to understand enough context to be able to make a change with as few token as possible, so if your code isn't expressive enough

Recently there's an article on language plasticity in the era of AI/LLM and why D language is very well suited for this era [1].

Perhaps we need a proper benchmark similar to Beaver but for AI assisted coding for different programming languages instead of Text-to-SQL [2].

[1] Language Plasticity is More Important Than Ever:

https://blog.dlang.org/2026/08/10/language-plasticity-is-mor...

[2] BEAVER: An Enterprise Benchmark for Text-to-SQL:

https://beaverbench.github.io/#overview

I remember the old discussion between clojure programmers and someone who works in a strongly typed language. The argument was “types allow you to be certain that if you change some code, an unrelated but affected part of the codebase will also be flagged and it is not missed” the clojure guy response was “why would you ever design a program where a change in one place affects the other”.

I do think this is an unrelated win of functional languages that hasn’t yet been “discovered” by the vibe coder crowd - FP’s whole premise was that it makes your code depend on much much less things so you can “fit it in your head and reason about”… that’s like the perfect sweet spot for agentic as well, we just haven’t seen tools utilize that in earnest.

Additionally, if there’s more “knowledge” of the code and best practices and such baked into your model, it has to spend fewer tokens reasoning about it or even potentially looking it up. I think even one web search to retrieve additional information not also in the model will probably blow up any supposed benefit you’d get by a slightly more token-efficient language.

APL would win in that regard.

I came across a very similar project recently.

https://github.com/DeadMeme5441/arrodes

It seems to be a bit more integrated than what you describe here because it's completely built around a Clojure REPL

Which extension do you use?

Fair enough haha you got me

[delayed]

Bad performance is much less excusable these days (https://danluu.com/perf-opt/) and usually it's more the result of architecture and data structure choice than presence/absence of things out of the box of some language (though in the case of C++, it seems that everyone who gets obsessed with performance just says to avoid the included stdlib no matter the compiler; so much for that box). Your question seems to me to betray an assumption that Common Lisp is particularly functional (and overall suffers from some sort of functional programming performance trade-offs), when it's not. Common Lisp is unopinionated, multi-paradigm, but at its core is mutation-friendly, compilation friendly (compile is a function available to call at runtime), and object-oriented (CLOS being the first ANSI standardized OOP system, it's more flexible than most OO systems and methods do not belong to classes). There are also many implementations of Common Lisp, including two long-standing commercial ones, so should performance (whether raw throughput, or memory size, or whatever your metrics) not quite be to your liking out of the box with one, you might consider another before giving up and choosing an entirely different language or spending time/tokens trying to better optimize your existing code. That said, SBCL is probably the most popular, and has a pretty sophisticated optimizing compiler that produces pretty fast native code by default, while allowing you to specify your own assembly ops without actually having to write separate assembly files. (You can specify the assembly with more Lisp code.) See for instance https://www.stylewarning.com/posts/nbody/

Common Lisp is not a functional language. You can write functional-paradigm code in CL but it will happily let you write old-school imperative style, OOP, etc.

The de facto open source implementation, SBCL, has a solid compiler and garbage collector. It produces fast code.

Interesting take and similar to something I've recently been working on. Have a look at janet-num.[1] Plain numeric C kernels under Janet.

Janet for orchestration, C for the frame loop.

[1] https://github.com/jennystats/janet-num

https://pricklypear.rocks/

Folks have found it useful to just point gippity at the page and ask questions

I built a OCaml core with a webserver - then made my scripting language on top a custom scheme. I love your idea! I think you would find that a solid interpreted language living in a webserver is an extremely useful think to have. Let me know if you build it!

And I think this point is a poor as any made in the article.

Last I attempted to write some smaller ocaml project I used LLMs for support (but wrote myself). They generally weren’t excellent.

Honestly, types don’t help as much as people want them to. The LLM does best on popular languages, especially those whose use and feel is also mainstream.

That is to say, pick a niche language like Odin, and it may incorrectly start to over-apply Go’isms - knowledge from one language bleeds into how it approaches others.

OCaml core + interpreted Lisp on top really feels like total enlightment, I have to say.

The dynamic features you get with a full blown REPL are, in some specific cases, worth the trade off you get by losing the guardrails (which I call Rubber Baby Buggy Bumpers).

You're right though - strong typing feels like a cheat code.

What the heck this thread is about, Common Lisp has types and you can use them in ways most strongly typed languages wouldn’t let you! They are basically expressions, which gives a lot of flexibility. It may not be always checked statically, but in practice SBCL does a great job at doing it or at least emitting warnings when it can’t prove the code will fail at runtime.

Also if you really want Haskell types you can use Coalton, which is essentially Common Lisp with Haskell types, but lets you interop with Common Lisp seamlessly as Kotlin with Java.

Absolutely this. Plus, LLMs are surprisingly adept (in my experience) at handling gnarly syntactic corners of most widespread strongly typed languages, esp. C++ and Rust.

I've found the same: strong types are disproportionately valuable in LLM coding vs human coding because they essentially function as context and the typechecker actively enforces correctness

And there is a super power to it.

It's possible to write the whole system only by defining the types.

The "glue" can be sloppy but as long as it keeps on the edges the output is most often fine.

Recently I'm on the fence about Rust vs OCaml (but plan to write about it soon) because I have ~700k LoC in Rust but my workflow starts to get seriously dragged down by compilation/tests in isolated worktrees.

I recently also dab with Gluon (as embeddable type safe scripting) and rule-based-development for maximum code control/agents output leverage.

Yes! Maybe the current limitation is due to their limited context and frequent compaction. Where they can lose track of (abc-xyz A B) and what A and B need to be.

I’m not sure if the Common Lisp compiler can be very helpful either, since it’s a dynamic language and A and B could be many different types (duck typing).

Strong types are the way to go, at least for now.

Yeah, I mean it's tough to describe how good it is to use agents with a lisp REPL, but it's really great using agents with a Lisp REPL.

Presumably a DSL would allow you to do more heavy lifting in your specific domain with less tokens.

Let's way you wanted to do a web application using LLMs. Using a web framework would cost less tokens than using the vanilla underlying language (Python, PHP, whatever..), which is again way less tokens than building up from assembly (an LLM should be able to do this given enough time and compute).

Readability for yourself. I find the biggest issue with lots of LLM assisted development is that the agent harness can generate code faster than I can read it. I'm the bottleneck.

There's a "zen" moment felt by folks who've written lots of macros (experienced in Lisps and Forths) where, when designed properly, you really feel like you've "grown" a language and have really walked up the abstraction ladder. My thesis is that macro heavy code when the author designs the macros well are very readable. That an agent's output when stacked upon macros can be a lot simpler to read and understand than in languages where the syntax is less fungible. And if you leave a project for a while and come back, an agent is a perfect tool to help you read your macros and familiarize yourself with the abstraction surface again.

Just a theory though.

sure I agree the LLM doesn't need a DSL to get work done. The point is more that the DSL holds the opinions of whoever built the product

I think what they're saying is that in CL you create DSLs that are tailored for the domain and that will result in lower token use. Not sure about that claim, would like to see some data to backup that assertion. Wouldn't you then need to supply the LLM with a "programming manual" for this new DSL? Wouldn't that cost tokens?

Smalltalk, in image based systems, absolutely. Erlang not as much, it's more of a "crash the actor and try again" than "rewind, pause, and handle errors in-system"

While the open source library ecosystem for CL pales in comparison to Python's or JS's or Java's (or even Julia's, if you talk about certain domain specific stuff), it's not like there's nothing. It really depends on what you're doing, but many sorts of common tasks have a library to help. https://github.com/CodyReichert/awesome-cl Plus, it's straightforward to make use of libraries with a C API, there are a few slower ways to call out to Python libraries, and there's a whole CL implementation built on the JVM if you really need Java libraries...

Common misconception but no.

The models learned to code, the actual language is just a tiny adapter on top.

Why, you are right on all of these. I used Rust a lot before AI, and I use it a lot after. But I recognise the shortcoming of long compilation: it doesn't just shorten how many times I can have feedback in one day, it is also difficult to fit compilation into constrained environments. Like when an ultra secure Kubernetes cluster doesn't let me compile source code anywhere near it, and I have to compile inside of it; my colleagues insistence on using Go here because "Rust is difficult" (it surely is 100% longer to type when prompting an LLM) really has the main benefit that this code compiles fast and easily within the cluster.

So picking languages for their compilation and especially runtime properties is key.

What I've learned, though, is that languages with reckless error handling produce more errors at runtime. My Rust programs just don't crash because I don't need it to be explicit about reaching a "total" approach.

If you're in a C# environment, I see a case for F#. And if you want fast but more solid than Python, why not Mojo? Although who reads code.

This article convinces me. But I suspect like my lack of domain knowledge of Lisp makes me spend time learning the runtime: how and when can I switch to JIT, what's the async story, how does the harness become part of the Lisp program, etc.

But no seriously F# might actually be the perfect agentic coding language. I had the good fortune of learning OCaml a few years ago as the models were getting good. Had a blast.

I think Lisp and an ML are kind of the dynamic (static) duo. I still think MLs are the best for complex projects, but interpreted languages are pretty neat too. Python, Rust, and Golang are all great, also.

I think a tree calculus language might be the actual best - but it's too soon to say

Really, languages are great for LLMs.

The truth is that it really doesn't matter that much.

Use the language that you like (enjoy your favorites!) and that binds well with other tools you're using. I'm currently working on a project that's all C++ (wxWidgets frontend, plus C++ backend). I've used LLM tools with it, no issues. Would be the same with any other language, from what I can tell. I have another project in Go I'll probably try it on at some point soon.

I must be proving your point because I'm a rust head and the argument you gave for rust just seems like the best one haha. And if I had the choice between two vibe-coded pieces of software, and one was written in rust and the other was written in python, I would far prefer to use the rust one.

Spot on! People do really enjoy NOT having to change. We can come up with many excuses why we do not have to do anything different. I'm finding multiple rrasons why I should stick to laravel.

Could be said that it was the path of least resistance, but the funny thing is that most of that resistance is you just being in your own way.

I hated Rust before because it reminded me how inadequate a programmer I am.

It's probably the best language for AI coding though. By far, as far as I can tell.

So now we're believing it's great that LLM's can write macros, thus further obfuscating human maintenance of the code-base, because LLM's can understand and implement it than better than humans.

This isn't the future I wanted, and is why I advocate for trade schools these days.

I miss the days I could listen to music and use my adhd/autism to its fullest potential reading documentation and figuring things out myself.

Of course, these are same people you'd want managing these AI agents in the first place, but reviewing code written by others always kind of sucks, especially when it's assumed the language model knows better than you do which isn't often the case!

Was the PRD perfected on the requirements? Only God knows, and I personally want to be there when it's written.

I noticed you left typescript out

I mean if we're heading towards a future where code gen gets super cheap and super good what stops you from porting the libraries you want?

Loved the post, have been batting around similar ideas w/clojure. I have two questions:

1. Have you had much success w/moar macros in the age of the LLM? I've been impressed by the models' ability to write good ones, but I can tell my taste/judgement for macros isn't quite there. But they tend to be pretty good at writing gnarly ones, and I would love to work more macros into my workflow. Would love your thoughts. (Have I taken "Simple Made Easy" too far and left macro value on the table?)

2. Do your models ever get confused with image-based dev, and state? It's seemed dumb to me to have models keep running `sed` to change files, but it is nice to have a human-readable, filesystem-backed record of definitions. Would love to hear your experience here.

  Also, in most languages an error will crash your program. So if you’re writing code with an LLM it will have to read your crash logs to make some changes and run your program again. In Common Lisp your program won’t crash, it’ll stop and open a debugger with the whole stack and all the variables. You can just point your LLM at the debugger, and it’ll make its fix and resume the program.

I was just explaining this exact thing to somebody a couple days ago - even used ERP as the example. Hear hear, sir

I'm convinced we'll be moving at some point to n-modular redundancy systems, using different languages implementation, simultaneously. For the cost of writing code in n languages tends towards zero now (due to the use of LLMs) and the various stacks and implementations shall then cross-check each others.

There shall be one minimal, ultra-hardened, tiny attack surface, "majority gate" picking the answers that most implementation agrees on.

This shall not only detect a great many implementation issues but also it'll help find security issues and platform defects (say the Common Lisp, Haskell, Rust and Python all agree but the Java one fails: in rare case it'll be due to a JVM bug and finding that out shall be simplified).

Code shall be generated from specs in n languages and ran on n stacks. The gate shall return the answer as soon as a quorum is met and, later on, any bogus answer arriving shall be cause for enquiry.

We'll have such systems, it's just a matter of time.

Lisp is a sharp tool and I think it struggles to scale with large organisations. You would need incredible tech leadership and a very considered org structure and architecture for it to work.

Culturally, I feel a place like Valve could make it work but you could turn around and ask why does an org need to be in service to and arrange itself around a tool.

I think what is referred to here is that an exception doesn't unwind the stack. Even if the exception is uncaught, you can fix the line or value and then resume where the stack was.

IF you're running a debug build. I guess Common Lisp can do this in prod?

Ah, but you forget the attention economy that the internet amplified: only controversial takes are discussed, nobody wants to read your reasonable and nuanced blog post because everybody can silently agree with it already. Without any crucial insight or big controversy nobody will read it. And the latter likes to masquerade as the former most of the time.

Even if there's one dimension, this is not a logically correct statement. Some numbers are bigger than others, but there is no biggest number. Or it could be a partial ordering - say that a number x is "better" than y if y divides x. Then out of the first hundred numbers, some are better than others but there's no single "best".

It need not even be multiple dimensions. https://en.wikipedia.org/wiki/Partially_ordered_set:

“a partial order on a set is an arrangement such that, for certain pairs of elements, one precedes the other. The word partial is used to indicate that not every pair of elements needs to be comparable; that is, there may be pairs for which neither element precedes the other”

Yes! It depends. That's why there are so many languages that still exist. Otherwise it would be a winner-takes-all situation and there would be just one left standing.

Even per dimension there will be different preferences. There's no objectivity in most of them, perhaps even none.

That was my assumption too (not that long ago, laggard that I am), so I expected LLMs to be less good at Common Lisp than, say, Javascript or Java, and surely to suck at Arc (the Lisp that HN is written in). But it's not so. They excel at Common Lisp—which, ok, has decades of history and documentation which the models have all slurped up. But they're even good at Arc, which is pretty far down the long tail. And when they mess up, I put something in agents.md and that issue mostly just goes away.

Not quite, though there does seem to be an advantage for a popular language. Dan Luu explored this at https://danluu.com/pl-tokens/

That really hasn't been my experience, LLMs have done well with Julia since Claude 3.7