> If someone came to you and said "good news: I memorized the code of all the open source projects in this space, and can regurgitate it on command", you would be smart to ban them from working on code at your company.

If you find a human that did that send them my way, I'll hire them.

> Its existence means Smart People have concluded that there are notions of abstraction that can't be adequately captured in regular Haskell,

...yet.

...although list fusion often saves you if the thunks were going to be forced eventually anyway.

You don't see that `p(doom)` in the wild very often as it's a lot more characters than just typing "1".

This was a result of Zoom's acquisition of the band House of Pain.

Thought it was Kris Kross.

When in reality it was Van Halen.

Attention is all you need. :)

You're an LLM, Harry!

Out of curiosity, does this post help it stick any? https://philipnilsson.github.io/Badness10k/posts/2017-05-07-...

I think a lot of people encounter this difficulty when they first get into functional programming, but over time it inverts, where you end up building all these small self contained pure functions that are easy to re-use and recombine and it's only the exoskeleton of the program that suffers from this stuff, so you end up spending a little more time on stuff like effect systems or whatever get it to a state where you can do things like use logging wherever you want without rewriting all your code. Once you cross the chasm the impedance mismatch reverses and you're stuck with the bad feeling in all other code.

The work described appears as if it would handle a complex set of multiple tools just fine, but you do train the controller on a specific tool set, so you would presumably need to train (or at least something like "fine tune") a controller for each toolset you wanted to use.

for sure, there's a way here where I think we ought to be able to learn multiple tool calls and prompts together with real world data. investigating that next.

> notable because many other common agent definitions have the tools as required, not optional.

This feels weird to me. I would think of an agent with no tools as the trivial case of a "null agent" or "empty agent".

It would be like saying you can't have a list with no elements because that's not a list at all... but an empty list is actually quite useful in many contexts. Which is why almost all implementations in all languages allow empty lists and add something distinct like a NonEmptyList to handle that specific case.

A lot of the agent/agentic definitions I see floating around are variants on "an LLM running tools in a loop".

Can't do that without tools!