Why Common Lisp is now the best programming language(vivienhenz.com) |
Why Common Lisp is now the best programming language(vivienhenz.com) |
> To my knowledge Common Lisp is the only mainstream language that does all of this.
Sounds like someone who has never used C# and Visual Studio? Even JavaScript is capable of doing this, honestly JavaScript might be the one language with the richest developer tooling of all time (possibly?), sad to say because there's nicer to work with languages out there.
There’s the right tool for the job, there’s compliance with requirements, there’s personal preference.
Don’t let anyone ever tell you you are programming wrong.
Unless of course there are multiple dimensions of "Good". I in my opinion this is exactly the case. There are best languages per dimension, but not absolutely best.
“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”
Maybe you could take CL as a foundation, introduce modern features and uniformity to the language, remove some of the insane complexity, tame the unhygienic macros, and come up with a pretty good language. Since about 7392 different flavors of scheme have tried to do this and mostly failed, I think this is very unlikely.
To be fair, I love Lisp, I dont do a lot with it, though I'm mostly a fan of Racket which is the most modern one outside of maybe Clojure.
But I'm not positive the juice is worth the squeeze, and this article was unconvincing. I mean if you want macros and terse code and a bigger ecosystem, wouldn't Clojure make more sense?
(not a CL expert here)
I still believe that other languages which are understood by developers are and will be required and LLMs are trained on the same dataset so it can write the code.
The best dual path systems are when they use different technology. Hence, an error in one is highly unlikely to infect the other.
This is what static typing provides.
One could argue that this was a large benefit for human coding long before LLMs became useful.
It is why I always preferred strongly-typed languages.
And once we had practical strongly-typed languages with implicit type inference I really couldn't wrap my head around why anyone would prefer dynamic typing other than just inertia due to that being what they were used to.
Previously studies into the benefits of static typing for humans were always a bit flawed because you can't do that with people. And tbh I don't know why but there are a surprising number of people that don't appreciate static typing. My guess is a combination of ego and laziness, which doesn't apply to LLMs.
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.
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.
> C++
I'm a bit confused here.
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.
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.
Type declarations are also optional and compilers can create compile-time warnings about them. Thus for many trivial cases, when using SBCL some obviously wrong types, or typos, or miscounted arguments, can be caught ahead of time without having to execute code. CL is also not duck typed. If abc-xyz is a generic function, selecting which method to call relies on the actual class hierarchies of the given A and B objects, there's no "duck shape" shenanigans.
For static types, well, CL is flexible enough to bolt such a system on top as a library, where you'll have a full ML/Haskell style type system. https://coalton-lang.github.io/ But it seems the relevance for LLMs is rather mixed, much like studies from the last few decades on static/dynamic typing in general: https://danluu.com/pl-tokens/
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.
I dont really understand what macros get you when llms exist since a llm doesnt really need to create dsls to get work done
Again, not a language expert, but: if you can describe your domain or business logic as clearly as a strongly typed language with a rich type system, most of your issues are gone. Enum and Struct with all the other core types plus the match expressions does most of my mental heavy lifting. I do not even track any of the recent language changes.
What I really care about is the shape of what I am describing - does it translate to code? How much do I lose in the translation? I want to try other languages, particularly Lisp but Rust is at this moment my choice. I have my own UI framework (1), my own provenance based business domain generator and a few simple language parsers.
I am building apps where you can, for example, throw a CSV file (2), ask questions in English and get answers - without using an LLM. Parser. Rust is no doubt a great language to express - not as a programmer, but as a prompter. I do not write the code. I ask LLMs to generate it using only basic knowledge of Rust and its type system. This will be the key to work with LLMs for majority of people.
The models learned to code, the actual language is just a tiny adapter on top.
In my circles I've noticed it's very easy for us to rationalize why our previous favorite language is also the perfect language for the agent era.
If your favorite language before was Python, why, LLMs are fluent in it! So much training data! So many libraries! Home of machine learning! None of that pesky compile time, agents don't need compile time safety anyway, they write such good test coverage! It's The Perfect Agentic Coding Language.
If it was Rust, by jove, an agent can easily handle the headache of satisfying the borrow checker, and now you get the best of all worlds! Safety! Near-C runtime performance! Abstractions! The only reason people didn't use Rust before was it was Too Hard and there were Too Many Furries and now it's not hard and you don't have to interact with them, so get on board. It's The Perfect Agentic Coding Language.
If it was Golang, oh my goodness, what a choice. Pretty fast compile time and pretty fast runtime. Agents get a tight feedback loop with build->run->test->edit. Not very complicated, code has to be written in a straightforward banging-rocks-together way. Good stable ecosystem! Rob Pike designed the language for people he said were "not capable of understanding a brilliant language but we want to use them to build good software." That's an arrogant, demeaning way to describe your colleagues but if they're LLM agents it's dead on! It's The Perfect Agentic Coding Language.
I could go on and on. I'm not immune either! My own favorite language is F# and when I feel like self-justifying, I play the same game:
It has access to the .NET ecosystem like C#, but I don't have to constantly remind the agents to prefer a style with immutable data and pure functions, they idiomatically do that in F#. Files have to be in order and can only refer to symbols defined "earlier" in order, if you want mutually-referential types or functions they have to be declared as such in a joint statement, so spaghetti is hard to create: each project's codebase naturally ends up in a layered bottom-to-top architecture. The language is terse enough to be token efficient, without being symbol soup. FSX scripts can be generated during agentic code reviews to demonstrate repros for discovered issues. If there's any type of code that still warrants me jumping in and writing some myself, that code would be data type definitions/domain modelling, and F# is a joy to write those in. It's The Perfect Agentic Coding Language.
Astronaut 2: Always has been...
(module reflection_symbolic)
(comptime
(fn sx-kind (x k) (sym= (syntax-kind x) k))
(fn sx-zero (x) (equal x '0.0))
(fn sx-one (x) (equal x '1.0))
(fn sx-add (a b)
(cond ((sx-zero a) b) ((sx-zero b) a) (otherwise `(f+ ,a ,b))))
(fn sx-neg (a) (if (sx-zero a) a `(fneg ,a)))
(fn sx-sub (a b)
(cond ((sx-zero b) a) ((equal a b) (syntax 0.0)) (otherwise `(f- ,a ,b))))
(fn sx-mul (a b)
(cond ((or (sx-zero a) (sx-zero b)) (syntax 0.0))
((sx-one a) b) ((sx-one b) a) (otherwise `(f* ,a ,b))))
(fn sx-div (a b)
(cond ((sx-zero a) (syntax 0.0)) ((sx-one b) a) (otherwise `(f/ ,a ,b))))
(fn sx-id (a b)
(if (and (syntax-binding a) (syntax-binding b))
(= (syntax-binding a) (syntax-binding b)) (sym= a b)))
(fn sx-lookup (x names vals)
(if (= (len names) 0) x
(if (sx-id x (head names)) (head vals) (sx-lookup x (tail names) (tail vals)))))
(fn sx-map (xs names vals depth)
(if (= (len xs) 0) (list)
(const (sx-expand (head xs) names vals depth) (sx-map (tail xs) names vals depth))))
(fn sx-expand (e names vals depth)
(if (> depth 32) (syntax-error "symbolic expansion exceeds 32 nested helper calls" e)
(cond
((sx-kind e 'symbol) (sx-lookup e names vals))
((not (sx-kind e 'list)) e)
(otherwise
(let ((xs (syntax-children e)))
(let ((op (head xs)))
(cond
((or (sym= op 'let) (sym= op 'let*))
(let ((ns names) (vs vals) (bs (syntax-children (nth xs 1))))
(declare (mutable ns vs))
(dotimes (i (len bs))
(let ((b (syntax-children (nth bs i))))
(let ((v (sx-expand (nth b 1) (if (sym= op 'let*) ns names)
(if (sym= op 'let*) vs vals) depth)))
(set ns (const (head b) ns)) (set vs (const v vs)))))
(if (/= (len xs) 3) (syntax-error "symbolic let requires one pure body expression" e)
(sx-expand (nth xs 2) ns vs depth))))
((sym= op 'the) (sx-expand (nth xs 2) names vals depth))
((or (sym= op 'f+) (sym= op 'f-) (sym= op 'f*) (sym= op 'f/)
(sym= op 'fneg) (sym= op 'fsin) (sym= op 'fcos) (sym= op 'fsqrt)
(sym= op 'tuple) (sym= op 'vec3))
`(,op ,@(sx-map (tail xs) names vals depth)))
(otherwise
(let ((f (fn-ref op)))
(if (/= (len (fn-params f)) (- (len xs) 1))
(syntax-error "symbolic helper call has wrong arity" e)
(sx-expand (fn-body f) (syntax-children (fn-params f))
(sx-map (tail xs) names vals depth) (+ depth 1))))))))))))
(fn sx-diff (e x)
(cond
((or (sx-kind e 'float) (sx-kind e 'integer)) (syntax 0.0))
((sx-kind e 'symbol) (if (sx-id e x) (syntax 1.0) (syntax 0.0)))
((sx-kind e 'list)
(let ((cs (syntax-children e)))
(let ((op (head cs)) (a (nth cs 1)))
(let ((da (sx-diff a x)))
(cond
((sym= op 'fneg) (sx-neg da))
((sym= op 'fsin) (sx-mul `(fcos ,a) da))
((sym= op 'fcos) (sx-neg (sx-mul `(fsin ,a) da)))
((sym= op 'fsqrt) (sx-div da (sx-mul (syntax 2.0) `(fsqrt ,a))))
((= (len cs) 3)
(let ((b (nth cs 2)))
(let ((db (sx-diff b x)))
(cond ((sym= op 'f+) (sx-add da db))
((sym= op 'f-) (sx-sub da db))
((sym= op 'f*) (sx-add (sx-mul da b) (sx-mul a db)))
((sym= op 'f/) (sx-div (sx-sub (sx-mul da b) (sx-mul a db)) (sx-mul b b)))
(otherwise (syntax-error "cannot differentiate this operator" op))))))
(otherwise (syntax-error "cannot differentiate this expression" e)))))))
(otherwise (syntax-error "cannot differentiate this syntax" e))))
(fn sx-partial (f index)
(let ((e (sx-expand (fn-body f) (list) (list) 0)))
(fn-with f 'body (sx-diff e (nth (fn-params f) index))))))
(macro derive-partial
(syntax-rules ()
((_ result source index)
(fnderive result source (transform (lambda (f) (sx-partial f index)))))))LLMs need a language that:
- has opinions about how to write standard code
- has opinions about one way of formatting and codestyle
- has opinions about linting and integrated debugging
- has predictable strong types
- has opinions about integrated unit testing and a standard way to write them
- has an integrated toolchain
- has a strong stdlib and an upstreamed way to unify libraries
- (recommended) has a standard project layout _where_ to put its code (types, structs, helpers, utils, etc)
Go and Rust fit all these checkmarks except the last one. That's why those languages don't need kilometer long prompts to tell the LLM how to write code. Most of the prompting in those languages focuses around architecture and design, and not about style, tooling, or other artificially vague decisions.
Lisp is the most unopinionated language there is, therefore it is the worst in terms of lack of decisions encoded in its tooling.
And I'm not writing that as an opponent of the language, I've written scheme bindings for a couple of years in (academic) robotics.
The point that I am making here is that you _need_ an opinionated language for an LLM to make sense. Write linters and tools before code [1].
[1] https://cookie.engineer/weblog/articles/write-linters-and-to...
Partly, having to do my own pentesting and red team work instead of using someone else's work that has already been pentested.
Sorry, I'm not impressed. How did that /run/ to the top of HN? [pun intended]
"Vorschusslorbeeren"? A clique of voters?
Boring.
So long as your feedback loop isn't slow enough to be taking you out of flow, it's fast enough. Having it be a few seconds vs a few hundred milliseconds mostly doesn't matter for a human, and will matter even less for an LLM.
On macros and DSLs, yes they're cool and even useful sometimes, but most of the software industry is working quite happily without them. And LLMs aren't going to change that because they are best when there's a lot of relevant patterns in their training data. That ends up being a far more important factor in their effectiveness than whether the language itself is token-efficient. It's much easier for an LLM to reason through how to do XYZ in Python where it already knows all the semantics and syntax than it is for it to do it in your DSL it's never seen before. To be clear, it can probably do both but will make mistakes an order of magnitude more in the DSL, and that's what will matter most for the LLM iteration time.
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
But I find ideas like Carp very attractive.
Still common lisp is designed very good.
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.
Endless article generator.
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).
https://news.ycombinator.com/item?id=21232352 (Oct 2019)
https://news.ycombinator.com/item?id=4766191 (Nov 2012)
https://news.ycombinator.com/item?id=694700 (July 2009)
* in the older sense of "token", meaning that one measures a program in AST size rather than lines of code
---
Edit: ok, this is what I get for not reading the article:
> For LLMs, less code means fewer tokens, and tokens are what you pay for so you spend less on development
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.
There is also a phenomenon I've named "brevity collapse." Often, when shrinking a codebase, you find you need less glue. Additionally, because it is smaller, you can hold more of it in your head and see more opportunities for shrinkage. Surprising things happen when the bones of your language get more efficient---it's more like going from elephant to flea than elephant to grizzly bear. The smaller scale means there's less "overhead" code, which means you can go smaller still.
I agree with your point
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.
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.
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.
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.
It's probably the best language for AI coding though. By far, as far as I can tell.
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.
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.
I've seen a big improvement in LLMs writing macros since Opus 5.5 came out. What really helps I think is that I've written skill files with my own examples and instructions.
Same thing for image-based dev. without an agent.md file with good instructions on how to work with a live image it will do dumb things. this sort of workflow is jsut so far off the training distribution.
I think what changed recently isn't that LLMs got better at CL, they just got way better at taking my skill/agent.md files and reasoning through them.
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.
So, in practice, it might look like you hit any kind of runtime failure, and then the LLM writes some code to fix it, and the user's request completes successfully with no errors.
https://comp-348.github.io/lisp-debugging.html has an example of what it looks like. A toy example, to be sure, but the basics of a real example would still look the same. You're given a choice of several options, very reminiscent of the "Abort, Retry, Ignore?" choice that used to be oh-so-familiar in the days of DOS. Except this one is more useful, because it offers ways to specify how to resume. E.g., the toy project is halting on a `(print X)` call where the value of X is not defined. And the choices are:
0. Continue. (Retry using X).
In the toy example, this would fail, because nothing else has defined X. But in real code, the name might have been undefined because the data needed to define it hadn't arrived yet, from the database or the filesystem. In which case retrying the statement might work the second time.
1. Use-value. (Use specified value).
This one prompts you to enter a value for the undefined variable, and continues, but it does not modify the value of X in the program. The next time the program tries to use X, it will halt again with another "unbound variable" error.
2. Store-value. (Set specified value and use it).
This one, just like Use-value, will prompt you to enter a value to use... but then it will set X to that value and continue running the program. Next time the program tries to read the value of X, it will have one, and the program won't halt.
3. Abort. (Exit debugger, returning to top level).
This is what you would choose if there's no good way to fix the error, and you just have to quit the program and restart. Though note that choosing this option isn't going to exit the program you're debugging, just take you out of the debugger. You'll still need to kill-and-restart it some other way... or come back an hour later when the value is finally available, and then choose options 1 or 2.
Hopefully that gives you a taste for what the CL debugger is like to use in practice.
When it comes to back office business programming, there’s just a lot of code tasked with copying a litany of bits of data from one structure to another.
Whether it’s copying a web form into a database, or converting Their JSON to Your JSON, it’s a lot of detail that does not abstract well. It’s all shapes and sizes and formats, and it almost always has to be enumerated in excruciating detail and, typically, twice.
Sure, there’s logic and whatnot involved, but it, too, is specific to some subdomain of the larger system and it, too, does not abstract well. Not in the large context of the overall system.
Accounts Payable and Accounts Receivable, at 10,000 feet look almost identical. They’re almost literally the same thing with the sign flipped. But in practice, they don’t share code well. You end up with two similar systems, but not similar enough where sharing is actually worthwhile.
At best they can leverage a common API to the GL.
Turns out a lot of languages can manifest a decent level of abstraction. But even then, folks push back.
Consider the love/hate relationship with ORMs. Or the annotation driven markup in Java programs and the underlying “magic” that they enable. Like scribing mystic runes onto things.
Those are both very powerful, yet folks experience that and toss their hands in the air and throw out the baby with the bath water and jump into something “magic free” like Go.
Just because you can use something like CL to “make your own magic”, doesn’t mean it’s a good idea. Doesn’t mean it scales. Doesn’t mean it communicates well to others. AI or no.
It’s not the AIs world yet. We already know that if the AIs want a better language suited to AI efficiency, they’ll come up with their own. I’ve already seen crass examples of “code only an AI could love”. Completely impenetrable, at least to me. May as well have represented it as a color image and collection of RGB values. Opaque to me, but the AI could “read” it.
There is much more to programming and systems than token density, and AI is still getting cheaper by the day, so less reason to even pre-optimize for it anyway.
DSL presumes agreement on semantics, and that's often the most difficult part.
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.
While I am extremely taken with Lisps and the lisp way of doing DSLs, I would probably go with an OCaml to make a DSL for a company specific ERP. It seems a better way to go about the problem.
Lisp, on the other hand, I have found to be extremely good at domains which seem the same but which are tremendously different. For example, a workout app is a surprisingly complex domain. Different exercises have different storage models and functions, as do different training sessions and different programs. Rather than try to build a monoprogram, one training app to rule them all, I find lisp wonderful for making "microprograms".
This bears resemblance to Accounts Payable and Accounts Receivable but I don't think Lisp would be a good fit for those. Perhaps a Lean or a Rocq, something with proofs.
> We already know that if the AIs want a better language suited to AI efficiency, they’ll come up with their own.
My agents seem to really like Tree Calculus and have bullied me into working on a language which uses it.
Javascript/Python is the best because there's so much code out there that the LLMs can train on, and LLMs can write lots of tests to make sure everything is correct. There's nothing to compile, so the LLM can iterate quickly.
Rust is the best because the LLM gets great feedback from the compiler because of its strong type system, and it can deal with the borrow checker for you.
Go is the best because it's a simpler language with a decent type system, and the LLM can reason about that well, and will never forget to check an `err` return. The compiler is fast, so the LLM can iterate quickly.
I could write similar praise for C, C++, Java...
At this point I don't think any language is the best "because LLMs". I think there are quite a few languages that LLMs are probably not good at, but you have lots of choices if you want something they are good at.
I mean, it can still reason about it, but the code it (Claude and Gemini) frequently doesn't compile and it throws edits onto it until it does. When it then compiles this pretty much c# written in a functional HM-typed sexpr language that lacks classes.
AI has been great help in writing the compiler, though. I got stuck in codegen after having written a lexer, parser and type checker, and not only did it make a faster and better code generator than I ever could, it also made the type checker about 5x fater.
What I like most is how fast testing goes: it modifies test code on disk, asks clj-reload to reload all affected namespaces, then reruns the tests. It's also fun to see how it verifies its assumptions by evaluating short programs through the nREPL.
I asked it to organize the various subsystems inside my playground repo into Integrant systems and make it possible for me to say things like "restart the http subsystem".
It also understands shadow-cljs: I replicated the necessary parts of the shadow CLI tooling in Clojure; now I can compile, watch and serve any number of CLJS apps located in various namespaces from inside the same JVM. There is no need to touch the command line any more: I just instruct the agent to start a particular CLJS app and it's there.
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
Surely iPython (what powers Jupyter notebooks among other things) + maybe pdb could do it? And agents are definitely familiar with how those work.
https://github.com/cellux/pi-extensions/tree/master/extensio...
Note that this may not work for you standalone as it relies on my other agent-sandbox extension (which ensures all agent operations happen inside a sandbox container).
But point an LLM to its source code and it will extract the gist of it.
(That's an impossible count (3) of parentheses on the RHS—like a six-fingered hand).
I think others have pointed out that most modern scripting languages can halt at exceptions without unwinding the stack. Python & Node both support this with core tooling.
As for DSLs, they constrain the LLM which generally helps with code quality. However why implement your DSL in the unconstrained chaos of CL? You can write DSLs in Rust which gives you static typing, a borrow checker, and clippy.
- 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...
I don't think that's strictly true.
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 or if it has a tendrils calling lots of different functions/methods all over the place, then you'll have to give it much more code (context) than if you've got nice encapsulated modules that don't depend on other parts.
The design of your architecture (probably?) has a greater impact on token use in a large app than the language it's written in. Although, obviously, languages lend themselves to particular architectures so it's correlated.
This is why Lisp never catches on. Each programmer invents their own ad-hoc, undocumented, barely working language in the form of those macros. The same thing happens in other languages with macros (like C and assembler).
I say this as somebody that loves CL dearly. The difference between princ, prin1 and print; set, setf and setq; =, eq, eql, equal and equalp is more than most programmers can be bothered to memorize.
>[…]The same thing happens in other languages with macros (like C and assembler).
Uh, C definitely caught on.
Can lean generate small static binaries the same way Go/Rust/C/C++ can?
How practical is rewriting, say, grep in Lean?
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.
I don't understand how people have that stated as a fact. Coding was never the slow part. Neither pre-llm, nor now. How it needs to be done is software engineering. And that corresponds now to the "thinking" part of llms, so unless you are making the llm "think in lisp" its not useful. How would that even work. training data to be completely in lisp ?
> Lisp programs are often much more concise because macros let you abstract away recurring patterns and make them part of the language itself
functions ?
> So the bigger the program gets, the bigger the difference. In my own experience the apps I've built in Common Lisp end up about six to seven times shorter than the Python versions
By that logic writing code in this concept language made up completely of symbols would take you even further ( https://github.com/artpar/guage ) but in practice it doesnt because llms arent trained to that extent on this.
He claimed that Common Lisp was the best programming language for web apps, and that it gave him a massive advantage in creating his app.
What was his name again? Paul something? Oh yeah, Paul Graham.
I'd rather my language surface problems at compile time for all possible code paths rather than a particular codepath at runtime.
That said, nothing prevents an LLM from controlling gdb/lldb either.
Also this is actually not such a big win: resuming the program after making the change aka hot reload is often a very hard problem even in highly dynamic languages like erlang and common lisp. What if the schema changes etc. ?
> To my knowledge Common Lisp is the only mainstream language that does all of this.
You should also mention racket, chicken scheme, guile scheme, MIT scheme, erlang/elixir, even Python via the repl and so on ...
> This is what makes macros possible. A macro is a function that takes your code and returns new code in its place, that means you can add new constructs to the language itself.
Macros + untyped code means the code cannot scale beyond a few thousand lines easily. Only a few programmers may understand the program fully and it’s often in their head rather than documented. Types implicitly document the code and allow hundreds of programmers to work on it. Lack of typing hinders code refactors too.
> Common Lisp is an ANSI standard and it hasn't been updated since 1994. I like this feature.
I like stable languages but not ossified languages. The internet was in its primitive infancy in 1994. This means Common Lisp may not be as web friendly as, say, golang without external libraries. Moreover, there has been a lot of progress in programming languages since 1994. OCaml/Haskell/Rust/Python/Ruby etc. incorporate some of that.
> But I don't think that's a problem anymore. Most programs today depend on millions of lines of code from packages that keep getting compromised. You don’t want that in yours. Also, with an LLM you could just write the part you need yourself or port the whole library — and LLMs seem to be really good at porting code.
You claimed earlier in the article that since Common Lisp was very concise you needed to spend fewer tokens via LLMs. But now that libraries for common tasks are not available you need to spend extra money on tokens to generate that functionality from scratch ! There goes your token budget !
Which is better ? A from-scratch LLM implementation of something with security holes or a library downloaded from the internet ? If you can restrict your dependencies to stable and popular packages from npm/cargo/pip you will probably be better off.
Janet for orchestration, C for the frame loop.
Folks have found it useful to just point gippity at the page and ask questions
False. A partial ordering doesn’t guarantee a maximum element!
The main things you want for ERP are just to simplify database interactions as far as possible and to give you as many and as customizable options as possible for data visualization and curating information for a non techie user. I dont really get why LISP?
Until then, I subscribe to the view that strong types fit LLM coding well since LLMs are prone to make silly mistakes when they patch together code examples in dynamic languages.
[Disclosure, my new language https://bil-lang.org aims to add “strong typing” around parallel programming to help weed out deadlock conditions.]
I've heard fans of both statically typed and dynamically typed languages advocate for their language. The static type fans say that the rigorous compilation process gives the LLM a fast iteration loop with clear messages from the compiler on what invariants aren't being upheld. The dynamically typed languages advocates talk about fewer tokens, the popularity of the language in the training data, and so forth. Guess what, these are the exact same arguments these communities made for human developers.
Personally, I don't know the answer. The industry has swung back and forth on this over the decades. Before AI code-gen static languages were on the upswing for a variety of reasons, including runtime efficiency and much better ergonomics thanks to modern type inference engines. I suspect those reasons are still valid, and also that statically typed languages give LLMs a leg up because it is easier to reason about them locally thanks to declared types and information hiding.
If it were a good programming language people would be using it more at this point.
The de facto open source implementation, SBCL, has a solid compiler and garbage collector. It produces fast code.
From the parent's security standpoint I'm more sympathetic, there's been a lot fewer eyes on CL code, there's no central place to keep track of discovered security issues, and perhaps more vigilance is required against untrusted input compared to other languages. At the same time, every time I've exposed a CL-powered website I've noticed various attempts at e.g. wordpress endpoint discovery and I sleep soundly knowing a wordpress deployment is something I'll never have to worry about or take extra precautions against. Every time I hear about a supply chain attack I also am happy about the choice of CL. (Though in truth it's not to say that such attacks aren't possible, but for various reasons, one of them rather quite embarrassing to the overall ecosystem, pulling a big one off is going to be more difficult.)
And it's not editing files on the server, it's actually reaching into the running code and tweaking its values.
That, I think, is the difference here. In many languages, the debugger can pause on the exception and let you inspect the code. But in every other language I've used, once you edit the code to fix the bug, you can't resume from where the debugger paused. You have to recompile the code and resume from the top. In CL, you can resume from exactly the state you were in when the debugger paused, only this time with the correct data in place. (Or even with a code fix having been applied, live, to the code).
Now, if your entire server is taken down because one connection threw an exception, that's bad design. But pretty much no major language works that way. All of them allow you to set things up so that an exception handling connection A won't affect connection B. And if you've done that in Common Lisp, then connection A halting and waiting for the debugger won't affect connection B either.
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.
If that would be possible, there would be no function signatures.
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:
- economies of scale no longer work, and you end up doing a custom ERP for your business from scratch.
- your business changes might invalidate your model quickly. You sell through distributors, but open an online shop -- and suddenly your customer is not one of few dozen well-known businesses with a known address and tax number, but user2252 who bought something late at night last night. And you want to understand the needs and behaviors of both.
(It’s also essentially pointless when your unit of deployment is a disposable container and not a long running lisp system, but it at least makes development a bit nicer)
This is where the functional programming model really shines - there typically isn't a bunch of hidden state floating around to break hot-reloading
> Can lean generate small static binaries the same way Go/Rust/C/C++ can?
Lean compiles to C and the binaries aren't huge, though haven't benchmarked this part yet.
> How practical is rewriting, say, grep in Lean?
Very, you should probably try it.
Webpages, zettelkasten, todo, workout, diet tracker. It's a web framework! Creating an endpoint is just like making a function in emacs.
Since lisp is homoiconic the AST is just raw JSON. I save the AST in JSON stores in Postgres. But you can clone the AST down and then eval against a local copy of the REPl. So you get local eval for free.
Of course you have to rebuild git to manage a branching REPL in this way.
- for the economies of scale, you might develop your custom solution 20x faster now, but you're still in competition with the established provides with templates for most of the cases (who btw have the same LLM capability at their disposal)
- for the change in business -- you can ask an LLM which changes this induces, and it will give you most typical impacts. And then you're back at square deciding if it's better to roll your custom DSL and the custom system downstream, or just use off-the-shelf stuff that covers 95% of it from day one (well, maybe day two or three)