Live data from Hacker News

Writing Lisp is AI resistant and I'm sad

blog.djhaskin.com

51–60 of 104 posts

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

#51
post #14

Amusingly, some of the earliest AI research was using Lisp which beget AI winter. Now we’ve come full circle with LLMs that struggles to write valid Lisp. Almost poetic.

I have a feeling we'll care less about untyped languages going forward as LLMs prototype faster than we do, and fast prototyping was a big reason why we cared about untyped languages.

Pedantic but Lisp is not "untyped". (Neither are JS or Python.) All data has a type you can query with the type-of function. The typing is strong, you'll get a type-error if you try to add an integer to a string. Types can be declared, and some implementations (like SBCL) can and do use that information to generate better assembly and provide some compilation-time type checks. (Those checks don't go all the way like a statically typed language would, but Lisp being a programmable programming language, you can go all the way to Haskell-style types if you want: https://coalton-lang.github.io/)

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

#52

[dead]

Try asking an LLM a question like "H o w T o P r o g r a m I n R u s t ?" - each letter, separated by spaces, will be its own token, and the model will understand just fine. The issue is that computational cost scales quadratically with the number of tokens, so processing "h e l l o" is much more expensive than "hello". "hello" has meaning, "h" has no meaning by itself. The model has to waste a lot of computation forming words from the letters.

Our brains also process text entire words at a time, not letter-by-letter. The difference is that our brains are much more flexible than a tokenizer, and we can easily switch to letter-by-letter reading when needed, such as when we encounter an unfamiliar word.

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

#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 better" kind of solution.

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

#55
"Expressive languages" like Lisp are for weak human minds.

Now is the time to switch to a popular language and let the machines wrangle it for you. With more training data available, you'll be far more productive in JavaScript than you ever were in Lisp.

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

#56

Earlier quoted context omitted.

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…

Don’t ask the LLM to do that directly: ask it to write a program to answer the question, then have it run the program. It works much better that way.

If the LLM is intelligent, why can’t it figure out on its own that it needs to write a program?

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

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

But we don't hear of famous AI written in lisp. It's like below the notice-radar.

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

#60

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.

Post reply on HN