Writing Lisp is AI resistant and I'm sad • Hacker News Board

Re: Writing Lisp is AI resistant and I'm sad

#61

Post by truncate » Sun, Apr 05, 2026, 6:53 AM UTC

pneumic wrote: post #40

prescriptivist wrote: post #25

Earlier quoted context omitted.

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…

Came to post exactly this, except it’s got me using emacs again. I led myself into some mild psychosis where I attempted to mimic the Acme editor’s windowing system, but I recovered

Yeah, and all the little quirks here and there I had with emacs or things that I wish I had in workflow, I can just fix/have it without worrying about spending too much time (except sometimes maybe). The full Emacs potential I felt I wasn't using, I'm doing it and now I finally get it why Emacs is so awesome.

E.g. I work on a huge monorepo at this new company, and Emacs TRAMP was super slow to work with. With help of Claude, I figured out what packages are making it worse, added some optimizations (Magit, Project Find File), hot-loaded caching to some heavyweight operations (e.g. listing all files in project) without making any changes to packages itself, and while listing files I added keybindings to my mini buffer map to quickly just add filters for subproject I'm on. Could have probably done all this earlier as well, but it was definitely going to take much longer as I was never deep into elisp ecosystem.

Re: Writing Lisp is AI resistant and I'm sad

#62

Post by rcarmo » Sun, Apr 05, 2026, 7:10 AM UTC

This must be specific to Common Lisp. I’ve had no significant issues with Fennel and Chez Scheme, although to be fair it was on existing projects and they are not languages I would start a project with today.

Re: Writing Lisp is AI resistant and I'm sad

#63

Post by nottorp » Sun, Apr 05, 2026, 8:03 AM UTC

> With AI, code is cheap, but only if you use a language for which AI has a lot of training data.

Yep. Language and libraries too.

Re: Writing Lisp is AI resistant and I'm sad

#64

Post by ksaj » Sun, Apr 05, 2026, 8:21 AM UTC

surround wrote: post #12

TacticalCoder wrote: post #2

> I wonder what adaptations will be necessary to make AIs work better on Lisp. Some are going to nitpick that Clojure isn't as lispy as, say, Common Lisp but I did experiment with Claude Code CLI and my paid Anthropic subscription (Sonnet 4.6 mostly) and Clojure. It is okay'ish. I got it to write a topological sort and pure (no side effect) functions taking in and returning non-totally-trivial data structures (maps i…

I think you're right. Try asking GPT-5 this: > Are the parentheses in ((((()))))) balanced? There was a thread about this the other day [1]. It's the same issue as "count the r's in strawberry." Tokenization makes it hard to count characters. If you put that string into OpenAI's tokenizer, [2] this is how they are grouped: Token 1: (((( Token 2: ())) Token 3: ))) Which of course isn't at all how our minds would group…

This is mostly because people wrongly assume that LLMs can count things. Just because it looks like it can, doesn't mean it is.

Try to get your favourite LLM to read the time from a clock face. It'll fail ridiculously most of the time, and come up with all kinds of wonky reasons for the failures.

It can code things that it's seen the logic for before. That's not the same as counting. That's outputing what it's previously seen as proper code (and even then it often fails. Probably 'cos there's a lot of crap code out there)

Re: Writing Lisp is AI resistant and I'm sad

#65

Post by pjmlp » Sun, Apr 05, 2026, 8:38 AM UTC

miki123211 wrote: post #60

danpalmer wrote: post #26

This rings true for me. LLMs in my experience are great at Go, a little less good at Java, and much less good at GCL (internal config language). This is definitely partly training data, but if you give an LLM a simple language to use on the fly it can usually do ok. I think the real problem is complexity. Go and Java require very little mental modelling of the problem, everything is written down on the page really qu…

I bet it would do much better at hcl (or Starlark, maybe even yaml, something that it has seen plenty of examples of in the wild). This is a weird moment in time where proprietary technology can hurt more than it can help, even if it's superior to what's available in public in principle.

Depends if the AI masters also own said proprietary technology.

Re: Writing Lisp is AI resistant and I'm sad

#66

Post by mark_l_watson » Sun, Apr 05, 2026, 9:23 AM UTC

zrkrlc wrote: post #27

huahaiy wrote: post #24

I have been using AI to write Clojure code this past half year. The frontline LLM has no problem with writing idiomatic Clojure code. Both Codex and Claude Code fix their missing closing parentheses quickly. So I won't say "Writing Lisp is AI resistant". In fact, Clojure is a great fit with AI coding agent: it is token efficient, and the existing Clojure code used for training are mostly high quality code, as Clojure…

Ha, and I’ve been using Datalevin for my vibe-coded apps! Thank you so much for such a wonderful piece of software.

Hey, thanks for mentioning Datalevin (https://github.com/datalevin/datalevin) - I hadn’t seen that before.

Re: Writing Lisp is AI resistant and I'm sad

#67

Post by mark_l_watson » Sun, Apr 05, 2026, 9:29 AM UTC

funkaster wrote: post #35

I 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…

Thanks for the Scheme setup examples. I have created very simple skills markdown files for Common Lisp and Hylang/hy (Clojure-like lisp on top of Python). I need to spend more effort on my skills files though.

Re: Writing Lisp is AI resistant and I'm sad

#68

Post by jmalicki » Sun, Apr 05, 2026, 9:38 AM UTC

js8 wrote: post #53

Personally, 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…

> We should be using LLMs to translate from (fuzzy) human specifications to formal specifications (potentially resolving contradictions)

Agreed! This is why having LLMs write assembly or binary, as people suggest, is IMO moving in the wrong direction.

> then solving the resulting logic problem with a proper reasoning algorithm. That would also guarantee correctness.

Yes! I.e. write in a high-level programming language, and have a compiler, the reasoning algorithm, output binary code.

It seems like we're already doing this!

Re: Writing Lisp is AI resistant and I'm sad

#69

Post by mark_l_watson » Sun, Apr 05, 2026, 9:40 AM UTC

faangguyindia wrote: post #11

I had AI write Haskell for me and it did that beautifully. I am not sure why would LISP be any sudden.

Same experience. I like Haskell a lot but I am not great at Haskell programming. LLM based coding agents are useful for helping with runtime errors, library versions, etc. (and as other people here have said, for tedious stuff like cleaning up Emacs customizations, etc.)

Re: Writing Lisp is AI resistant and I'm sad

#70

Post by mark_l_watson » Sun, Apr 05, 2026, 9:44 AM UTC

Jach wrote: post #49

themafia wrote: post #43

> 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…

I agree with you, but a Python REPL in Emacs (using the ancient Python Emacs support) is very nice: initially load code from a buffer, then just reload functions as you edit them. I find it to be a nice dev experience: quick and easy edit/run cycles.