Live data from Hacker News

An agent in 100 lines of Lisp

thebeach.dev

21–30 of 84 posts

Re: An agent in 100 lines of Lisp

#21
post #5
post #2

Maybe this is a reductive comment, but how does this differ from just letting your agent bash tool a `python -c` command (or anything of that class)? I'm not really getting where this is a "wow" moment? It is always nice to appreciate how much power you get out of (Model + the absolute bare minimum of control flow). There is just so much baked into the models now that given an inch they will take a mile.

You're not wrong. I did a similar agent in lisp back with Sonnet 3.5 and had a wow moment, but the wow was mostly for seeing an agent working effectively at all at that point in time. The part that killed it for me was losing everything if the lisp crashed (sonnet 3.5 was prone to doing that) and solving persistence had too many edge cases and confused the model. Later realized that writing the agent as 20 lines of b…

you can use LFE (Lisp flavored erlang) = lisp on BEAM runtime.

you get a snippet from LLM, compile it to module, and hot-load it into the running node. the module lives in the node's code table, so it persists and every other agent can call it. not just the one that wrote it.

the agents themselves are seaprate supervised processes, so if one crashes - e.g. because the snippet was crap, it doesn't take down whole system.

of course you can do that in just elixir too, the lisp is just cosmetics really.

Re: An agent in 100 lines of Lisp

#22

I like Lisp, I’ve used Common Lisp with a passion, but this doesn’t seem like a valid argument for Lisp. Homoiconicity, as I understand, is that the code is structured data that is easy to programmatically modify, hence allowing Lisp macros. While some might disagree, I see Rust macros as the closest thing that demonstrates homoiconicity in mainstream Algol-based languages, as Rust macros modify the loosely structure…

> I see Rust macros as the closest thing that demonstrates homoiconicity in mainstream Algol-based languages

I don't know if you consider Elixir mainstream, but IMO their macro system is much closer to lisp's ideal.

Elixir is basically Lisp, but with better syntax, a modern ecosystem, and running on the Beam. Unlike languages like Rust, Elixir's conditionals and function definitions are just calls in the AST, even though the syntax looks mainstream and not like paren soup.

Re: An agent in 100 lines of Lisp

#24

Nice, but this is the equivalent of always running with `--dangerously-skip-permissions` with all the security implications of that.

Pi does this by default. Since the frontier lab agents are vibe coded you really should sandbox any agent you run period.

Re: An agent in 100 lines of Lisp

#25

I like Lisp, I’ve used Common Lisp with a passion, but this doesn’t seem like a valid argument for Lisp. Homoiconicity, as I understand, is that the code is structured data that is easy to programmatically modify, hence allowing Lisp macros. While some might disagree, I see Rust macros as the closest thing that demonstrates homoiconicity in mainstream Algol-based languages, as Rust macros modify the loosely structure…

> I see Rust macros as the closest thing that demonstrates homoiconicity in mainstream Algol-based languages I don't know if you consider Elixir mainstream, but IMO their macro system is much closer to lisp's ideal. Elixir is basically Lisp, but with better syntax, a modern ecosystem, and running on the Beam. Unlike languages like Rust, Elixir's conditionals and function definitions are just calls in the AST, even th…

> Elixir is basically Lisp, but with better syntax

Which so helpfully removes many of the benefits of lisps :P I don't understand this argument at all, if it's not s-expressions nor quacks like a lisp, in what way is it lisp at all? Making it algol/C-like already makes it like the rest of the 99% of the languages, without any of the easy benefits of the neat and simple syntax of lisps.

Re: An agent in 100 lines of Lisp

#26

Nice, but this is the equivalent of always running with `--dangerously-skip-permissions` with all the security implications of that.

Which realistically, is the only way to be productive with agents. If you aren't running them inside of something that limits their scope/impact/potential damage, you're already doing it wrong.

Most of those "permission"-systems are built on the idea that an LLM can decide what to ask for approval to run or not anyways, which obviously don't work out great in practice. Might as well give them blanket permission to do whatever, then put them in an isolated environment.

Re: An agent in 100 lines of Lisp

#27
This is a thing of beauty, no matter what the general feeling in the comments seems to be against LISP. And yeah, you can do it in JS/TS/Python/etc., but somehow it doesn’t feel as elegant.

Re: An agent in 100 lines of Lisp

#29
post #3

Earlier quoted context omitted.

The blog is about writing an agent when you dont already have an agent, but only a plain LLM. It stitches the minimal pieces together. Agents dont need lots of supporting infra, so it is good to keep the code concise. Not a wow moment for sure, though some people think that agents and harnesses are complicated.

Right but given that the agent only outputs text, and agents are perfectly happy writing python, the supposed benefit of Lisp is completely irrelevant here.

> the supposed benefit of Lisp is completely irrelevant here

Yeah, it's a small example (it's in the title, "100 lines") so obviously doesn't highlight the best benefits once you reach larger codebase size.

Still think ~8 lines for the core loop is probably more elegant, readable and concise than you can achieve in other algol/C-like languages, but happy to be shown that I'm wrong :)

Re: An agent in 100 lines of Lisp

#30
This is beautiful, I can't deny that. But the claim that Claude Code is a fixed set of tools is quite wrong. Claude Code regularly generates new code to carry out tasks, and you can choose to promote those tasks to skills, workflows, etc.
Post reply on HN