Wildly speculating here, but if you buy that human brains have innate / evolved syntactic knowledge, and that this knowledge projects itself as the common syntactic forms across the bulk of human languages, then it’s no surprise that LLMs don’t have particularly deep grooves for s-expressions, regardless of the programming language distribution of the training set.
There is an interesting on-going research https://dnhkng.github.io/posts/sapir-whorf/ that shows LLMs think in a language-agnostic way. (It will probably get posted to HN after it is finished.)
Writing Lisp is AI resistant and I'm sad
91–100 of 104 posts
Re: Writing Lisp is AI resistant and I'm sad
#92I don’t find many issues with Clojure. The main problem is that it sometimes gets the paren balance wrong when it’s proposing an edit. Sometimes it will spin for a bit on that. A harness can help there, I’ve heard, but thus far I’ve just done a quick hand edit each time. I think this has something to do with how Lisps are typically written with all the closing parens on the last line, as opposed to on separate lines…
Re: Writing Lisp is AI resistant and I'm sad
#93Personally, I think we're using LLMs wrong for programming. Computer programs are solutions to a given constraint logic problem (the specs). We should be using LLMs to translate from (fuzzy) human specifications to formal specifications (potentially resolving contradictions), and then solving the resulting logic problem with a proper reasoning algorithm. That would also guarantee correctness. LLMs are a "worse is bet…
Perhaps you meant to say "coding", not "programming". AI is immensely helpful for programming. Coding is just the last, and in a proper programming session sometimes even unnecessary step - there are times when an adequate investigation requires deleting code rather than writing new one, or writing pages of documentation without a single code change.
You have to be a detective and know what threads to pull to rope in the relevant data, digging inductively and deductively - soaring high to get the "big picture" of things and diving into the depths of a single code line change.
I've been developing software for decades now (not claiming to be great, but at least I think I've built certain intuition and knack for it), and I always struggled with the "story telling" aspect of it - you need to compose a story about every bug, every feature request - in your head, your notes, your diagrams. A story with actors, with plot lines, with beginning, middle, and end. With a villain, a hero, and stakes. But software doesn't work that way. It's fundamentally an exploratory, iterative, often chaotic process. You're not telling what happened - you're constructing a plausible fiction that satisfies the format. The tension I felt for decades is that I am a systems thinker being asked to repeatedly perform as a narrator, and that is hard.
Modern AI is already capable of digging up me the details for my narrative - I gave it access to everything - Slack, Jira, GitHub, Splunk, k8s, Prometheus, Grafana, Miro, etc. - and now I can ask it to explain a single line of code - including historical context, every conversation, every debate, every ADR, diagram, bug and stack trace - it's complete bananas.
It doesn't mean I don't have to work anymore, if anything, I have to work more now, because now I can - the reasons become irrelevant (see Steve Jobs' janitor vs. CEO quote). I didn't earn a leadership role - AI has granted it? Forced me into it? Honestly, I don't know anymore. I have mixed feelings about all of it. It is exciting and scary at the same time. Things that I dreamed about are coming true in a way that I couldn't even imagine and I don't know how to feel about all that.
Re: Writing Lisp is AI resistant and I'm sad
#94> There are reasons other than a lack of training data that makes lisp particularly AI resistant. It's though to steal what doesn't exist. > but AI can write hundreds of lines in one go so that it just makes sense for the AI to use a language that doesn't use the REPL. It is orders of magnitude easier and cheaper to write in high-internet-volume languages like Go and Python Python doesn't have a REPL?
> Python doesn't have a REPL? Not really in the Lisp sense. If you consider how people typically develop and modify Python code (edit file -> run from beginning -> observe effects -> start over) and how people typically develop Lisp code (rarely do "start over" and "run from beginning" happen) it becomes obvious. Most Python development resembles Go or C++, you just get to skip the explicit "compile" step and go stra…
How does traditional human use the REPL impact AIs ability to use one language over the other?
> Most Python development resembles Go or C++
How do you know this? Or what source are you using to arrive at this conclusion?
Again, super curious, if outright copyright theft _isn't_ the answer, why can't AI write lisp, then?
Re: Writing Lisp is AI resistant and I'm sad
#95Claude has really helped me improve my Emacs config (elisp) substantially, and sometimes even fix issues I've found in packages. My emacs setup is best it has ever been. Can't say it just works and produces the best solution and sometimes it would f** up with closing parens or even make things up (e.g. it suggest load-theme-hook which doesn't exist). But overall, changing things in Emacs and learning elisp is definit…
I used Emacs for about a decade and then switched to VS Code about eight years ago. I was curious about the state of Claude Code integration with Emacs, so I installed it to try out a couple of the Claude packages. My old .emacs.d that I toiled many hours to build is somewhere on some old hard drive, so I decided to just use Claude code to configure Emacs from scratch with a set of sane defaults. I proceeded to spend…
Re: Writing Lisp is AI resistant and I'm sad
#96Personally, I think we're using LLMs wrong for programming. Computer programs are solutions to a given constraint logic problem (the specs). We should be using LLMs to translate from (fuzzy) human specifications to formal specifications (potentially resolving contradictions), and then solving the resulting logic problem with a proper reasoning algorithm. That would also guarantee correctness. LLMs are a "worse is bet…
> using LLMs wrong for programming Perhaps you meant to say "coding", not "programming". AI is immensely helpful for programming. Coding is just the last, and in a proper programming session sometimes even unnecessary step - there are times when an adequate investigation requires deleting code rather than writing new one, or writing pages of documentation without a single code change. You have to be a detective and k…
Re: Writing Lisp is AI resistant and I'm sad
#97I have found it to be the complete opposite tbh. Not lisp but I've been generating Scheme with claude for about 5 months and it's a pleasure. What I did was to make sure CLAUDE.md had clear examples and also I added a skill that leverages ast-grep for ast-safe replacement (the biggest pain is that some times claude will mess up the parens, but even lately it came up with its own python scripts to count the parens and…
Re: Writing Lisp is AI resistant and I'm sad
#98Earlier quoted context omitted.
> Python doesn't have a REPL? Not really in the Lisp sense. If you consider how people typically develop and modify Python code (edit file -> run from beginning -> observe effects -> start over) and how people typically develop Lisp code (rarely do "start over" and "run from beginning" happen) it becomes obvious. Most Python development resembles Go or C++, you just get to skip the explicit "compile" step and go stra…
> Not really in the Lisp sense. How does traditional human use the REPL impact AIs ability to use one language over the other? > Most Python development resembles Go or C++ How do you know this? Or what source are you using to arrive at this conclusion? Again, super curious, if outright copyright theft _isn't_ the answer, why can't AI write lisp, then?
Contrary to the blog author I don't really believe this.
> How does traditional human use the REPL impact AIs ability to use one language over the other?
I don't think it does very much other than it's not the normal workflow for people vibe coding. Lisp doesn't require you to develop with an interactive mindset, but it enables it and it's very enjoyable if nothing else. Vibe coding workflow is prompt -> plan / code generation / edits -> maybe create and run some tests or run program from start -> repeat (sometimes the AI is in a loop until it hits some threshold, or has subagents, or is off on its own for long periods, and other complications). The layer of interactivity is with the AI tool, not with the program itself. You can use this workflow with Lisp just fine. Sometimes an MCP tool might offer some amount of interactivity to the AI at least, e.g. I've never tried to use an AI to do Blender work but I imagine there's an MCP that lets it do stuff in the running instance without having to constantly relaunch Blender. Blender has a Python API so the AI with no eyes might even be decent at some things nevertheless.
Others than the blog author report using something like https://github.com/cl-ai-project/cl-mcp that lets the AI develop more bottom-up style with the REPL, perhaps even configurable to use a shared REPL with the human, where programs evolve bit by bit without restarting. I trust their report that it works though I don't really have a desire to try it. If an AI barfs a bunch of changes across several Lisp files and I want to try them out without restarting, I can just reload the system (which reloads the necessary files) on my own separately. I also don't think representation in the training data is that important at least to frontier models because they express ever more general intelligence which lets them do more with less. This is further suggested by them being decently good at things like TLA+ and Lean proofs, which don't exactly have a lot of data either.
> How do you know this?
I've at times been a Java developer, a C++ developer, a Python developer, a PHP developer, a Lisp developer, and others. I read about and observe how people develop their programs and how commercial tooling advertises itself. Hot reloading tooling technically exists in a lot of places and gets you some of the way towards what Lisp provides out of the box but it's not used by the majority and usually comes with a lot of asterisks for where it will fail. I'd say one of the biggest differences with a lot of Python code vs. other langs is the prevalence of jupyter notebooks, but that's more similar to literate programming styles than Lisp styles, and unlike Lisp or literate programming (though I'm sure there's at least one exception) jupyter notebooks are typically used for tiny few-hundred-lines stuff at most, not large projects.
As an example of what's out of the box in Lisp, compile is a function you can call at runtime, not a separate tool, inspect is another function you can call at runtime that lets you view and modify data, and the mouthful update-instance-for-redefined-class method is part of the standard, so you have optional custom control over class redefinitions modifying existing objects rather than just "invalidating" them and/or forcing them to keep using older copies of methods forever, or filling new fields with default values (though this is usually a fine default), or like default Java debug mode in eclipse/intellij saying "woops, we can't reload this change, you have to restart!". I like to advertise JRebel because it doesn't have as many limitations and goes very far indeed by working with the whole Java ecosystem. e.g. XML files that under normal development are used to configure and initialize objects at program start time, changes to which require a restart, are monitored by JRebel and when changed trigger reinitialization without having to restart anything. That's the Lisp way, though in Lisp you'd have to setup your own XML file watchers for something like that. (Djula is a Django-inspired example for web template files, it does reloading by just checking file modification times. One could use something fancier on Linux like inotifywait. Though some Lisp developers just write their HTML with s-expressions and so changes to a page are just recompiling a function like normal development rather than saving a separate mostly-html template file. Lisp gives you many options of how you prefer to develop and deploy changes to a website. I like to ship a binary.)
Re: Writing Lisp is AI resistant and I'm sad
#99I don’t find many issues with Clojure. The main problem is that it sometimes gets the paren balance wrong when it’s proposing an edit. Sometimes it will spin for a bit on that. A harness can help there, I’ve heard, but thus far I’ve just done a quick hand edit each time. I think this has something to do with how Lisps are typically written with all the closing parens on the last line, as opposed to on separate lines…
If you use clojure-mcp/clojure-mcp-light that problem goes away, and that gives it the ability to run a repl and work from it directly. It’s night and day.
Re: Writing Lisp is AI resistant and I'm sad
#100Earlier quoted context omitted.
But for lisp, a more complex solution is needed. It's easy for a human lisp programmer to keep track of which closing parentheses corresponds to which opening parentheses because the editor highlights parentheses pairs as they are typed. How can we give an LLM that kind of feedback as it generates code?
That's a different question than the one you asked. Are you saying LLMs are generating invalid LISP due to paren mismatching?