upvote
If you give your agent a `bash` or `python -c` tool, it starts a separate process that produces some output and then exits. After that, only the output and the exit code are available.

In contrast, `eval` runs the code in the same execution context as the agent loop. When `eval` finishes, that execution context still exists. For example, any functions defined during an `eval` call remain available for later use.

reply
That’s a distinction in search of a reason though.

Being able to run code in the same unix process or a new one doesn’t really matter all that much in the context of self modifying code. But even if we cared about that, this isn’t a LISP specific feature. All dynamic languages support eval.

And having the agent cache the tool for reuse is a really trivial problem to solve. Though I do agree that LISP makes this much easier than in many other languages.

This is certainly a cool tech demo. But the claims of its novelty are overstated

reply
That's technically true but practically an agent can just save the script file/rerun it/write a tool that lets it call a reply with memory etc.This aspect is a bit more elegant when it's in the execution context, but the core of "you don't need to predefine tools, the agent can dynamically write its own code" is not exactly new - that's pretty much the basis of why Claude code and codex and all the other agent harnesses are so much more effective than old ways if working with llms - they can just write giant incomprehensible bash scripts on the fly to accomplish random things without having pre-defined tools, write state to files, etc
reply
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.
reply
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.
reply
> 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 :)

reply
Most of the code in agents is to handle unhappy paths and human friendly interfaces. I’m sure you could trim most languages core loop too if you discarded all the stuff that actually make agents peasant to use.
reply
Please do show the equivalent of those ~8 lines in the other languages you think of so we can explicitly compare :) I gave it a try in the other languages I know, the Clojure one I have still ends up the smallest and fastest to comprehend.
reply
But that’s not just 8 lines. If I were to try and run those 8 lines on their own then the compiler would fail because half of those functions are undefined. Even the article itself doesn’t claim the agent is only 8 lines long.

And once you start including the boilerplate code you end up with something that’s a lot more equivalent to the other languages you tried.

I love functional languages, and LISP specifically too. But the point of that article wasn’t even to say “LISP is better at code golfing than other languages”. so this doubling down on the SLOC that you’re doing isn’t even a relevant tangent.

reply
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 bash was equivalently powerful to the lisp agent, but made persistence trivial from the easy file system interop.

reply
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.

reply
By my eye it's not that different, it's riffing in it from a Lisp perspective.

It's pretty amazing to write your own agent BTW. I've got a zero-dependency all-in-one-file agent harness I wrote myself. I use it all the time now because I can get it from anywhere and I can know EXACTLY what it'll do (as much as you can with any model), what it's been told vs not. Using it as a harness for models I'm hosting myself makes me feel like some kind of LLM homesteader: it's a set of tools I'll always have that will only change as much as I want it to change.

reply
this is as if python was written in python, and you added support for llm in python so that it can write it's own code
reply