Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

  • Hacker News
  • Given that the most important feature for agent performance is the popularity of the language, ie, the amount of training data, (https://danluu.com/pl-tokens/), why would you cause problems for yourself by using Lisp rather than Python/Javascript if you care mainly about results fast, or C/C++/Rust if you care about performance too?
  • This is not just false but egregiously wrong. The regular syntax of Lisp is a tremendous asset when it comes to LLMs being able to work directly in the image. If I had to score languages by how well they work with current LLMs, Common Lisp and Emacs Lisp would be at the very top.
  • > the most important feature for agent performance is the popularity of the language

    This is explicitly called out as only weakly supported in that blog post:

      - You should use a popular language
        - There's weak support for this statement
  • LLMs have been solid at writing Common Lisp since Sonnet 3.5 and have been near flawless since the Opus 4.5 release.

    The niche language thing is really not a problem at all any more. If you're working in some esolang it doesn't take more than a 1-2k token primer in the context to get great results, and lisp is popular enough to not even need that.

    The benefit of having the agent directly in the image like with Autolith here is that it can directly inspect all defined symbols and explore and orient itself automatically. Really doesn't need much guidance to get great results.

  • Well, I made Autolith in Common Lisp because I like Lisp and I think it's by far the best and most practical language for self-modifiable live image agents.

    I have been trying Scheme and CL with LLMs for the last three years or so, and in recent months, I have finally decided that they are good enough.

    My idea is that well, it's good enough that I can now produce more training data just by using Autolith with the most basic claude/gpt subs, haha

  • The obvious reason is that Lisp is perfectly suited for writing self modifying programs in a way pretty much no other language is. And as others pointed out, the evidence that agents work better with other languages is pretty thin. I've been using Claude, GLM, and DeepSeek with Clojure for around a year now, and they certainly do just fine in my experience.

    In fact, I've had much easier time maintaining LLM assisted programs in Scheme and Clojure than other languages I've tried using because functional style naturally leads to low coupling. And that makes controlling context far easier than the rats nest of shared state that you have in imperative languages.

  • stupid question: why are so many people obsessed with LISP?
  • It's the most flexible language there is, while also fairly performant and having great features for extensibility and debugging
  • very cool, thanks for making this!
  • Thanks for liking it!
  • How do differentiate with cursor ?
  • Hi, I am the author of Autolith. What do you mean by that? I'd love to give you a good answer, haha
  • Well I'll be damned if that isn't one of the best sites I've ever seen, with a great ethos. And in Lisp! Inspiring stuff. Godspeed, Lucius :)
    by bbor
  • Thank you, I am glad you like it, haha! I was inspired by Xerox PARC stuff, mostly Interlisp! :)
  • Ever since coding agents came out, It felt a little like we were implementing the self improving lisp programs of old.

    This idea almost gets us there.

    Could the next step be to make it the program itself?

  • Well, I've had success loading Lisp programs into Autolith and letting it poke at them from the inside, haha!
  • Amusingly, I started building something very similar in Jolt today :) https://github.com/yogthos/samizdat/
  • Hi, I'm the author of Autolith!

    Never heard about Jolt, and I love Chez Scheme, it was my first Lisp!

    Would you like to come to our Zulip at https://zulip.lambda-symbolics.com? We can exchange ideas for our harnesses

  • This webpage is beautiful.
  • Thank you!
  • This is an interesting idea. I was thinking about something similar in Smalltalk or Erlang the other day. Mostly building on the actor/object+mailbox concept.

    I didn’t actually do anything with that idea yet but may look at the idea in Elixir this weekend.

  • Hi!

    I was thinking about Smalltalk as well before I made Autolith. I ended up going with Common Lisp because I know Lisp much better (last time I used smalltalk was like, whew, 2014 or so) and because it has better platform support and ecosystem (at least in my experience).

    I think Elixir could be great, I knew a guy who was trying to do an agent in Elixir, but sadly didn't get far.

    Keep me posted if you get anywhere! And if you'd like to try Autolith, I am happy to help with issues/questions on our Zulip, haha

  • I'm having a bit of trouble reading this over understanding the case where I would rather the agent update itself, vs having the agent write out tools and then call those tools.

    I rarely find myself thinking "ah I need the agent interface to change". And the vague generality of how agents work play into making it fairly easy to "just" have it rely on some external tooling to do anything special.

    Maybe this is just a counterargument to the lisp philosophy as a whole but... well... I use Emacs for example and am fine with a model of "an agent can look at my Emacs config" rather than "my agent _is running my Emacs session_".

    by rtpg
  • (disclaimer: I made Autolith)

    Well, having the agent write out tools and call those tools is something I consider to be under self-modification also.

    But there are other things, when it's useful:

    - You want the agent to update without restarting a session and e.g. killing child LISP REPLs and long-running sub-agents

    - There is a bug in the harness that bothers you (Autolith records papercuts and can generally solve them via self-modification)

    - You want to temporarily or permanently hook into literally any part of the agent lifecycle

    - You are of a ricing persuassion and want to change how the agent looks (very surface level, but I have seen people do it)

    - Related to the hooking point, you want to integrate Autolith with something else or make it emit something. We cannot predict all the knobs where you might do this, or how selectively you might do it, but self-modification lets you do it

    - You want to add support for yourself for non-standard or proprietary/secret providers

    That's off the top of my head. The secondary benefit is that this is great at developing the agent itself as a project. It can try/triage the changes it's working on, try its own tests, probe at things, and so on. This is why by far, the changes submitted to Autolith developed by Autolith are by far the highest quality out of all clanker-submitted changes.

  • Hello guys, I am the author of Autolith (github.com/luciusmagn), I am pretty new to Hacker News. I will respond to your posts as soon as I can :)
  • This is really interesting. I have felt for the past couple years that the moldability of Common Lisp lends agents the appropriate affordances to “do the right thing” via experimentations.

    I see there is a section on RLMs; have you ran Autolith via agentic benchmarks? I would love to see comparisons with Prime Agent.