Discussion

AI agents keep failing. The fix is 40 years old.

pmarreck: so does insisting on TDD.I've known these things from the beginning.Any extra restriction that still produces functional code ends up being great for LLMs to curb them deterministically.

4b11b4: close

lispisok: This article is just describing Clojure. The SUPER principals are describing the native natural way of writing Clojure, no category theory needed.

cyrusradfar: OP here: thanks for chiming in.I've explored Clojure after talking to Metabase about how it had benefited them. That said, it was years ago so I can't claim it influenced this work.The framework was designed to be a language agnostic way of sharing best practices to bias agent behavior towards a more scalable end. I initially used it when I was working with a team to do some massive refactoring/clean up across the codebase. We didn't come to an acronym but similar principles and it was "testable" and easy to push back on PRs that weren't aligned with the principles.That said, it may be interesting to see if I could replace all that context and just say -- "code it like you would with Clojure"Have you tried that?

Tadeuvich: Functional programming also helped get ride of bugs before, and still people used other paradigms. Why would we change now? How to know that functional programming is indeed better for vibe coding?

mncharity: One strategy I've seen mentioned for quality code gen, is to ask for an implementation in some other language X, so X's culture serves as a rich style guide, and X's tooling serves to clarify design. And only after ask for a spirit-preserving translation into the target language. Rather than struggling to reshape the target culture with markdown. So "This article is just [] Clojure" might then suggest an implementation approach for TFA.

nextos: It should be better for the reasons explained in the article. Pure functions require no context to understand. If they are typed, it's even simpler. LLMs perform badly on code that has lots of state and complex semantics. Those are hard to track.In fact, synthesis of pure Haskell powered by SAT/SMT (e.g. Hoogle, Djinn, and MagicHaskeller) was already of some utility prior to the advent of LLMs. Furthermore, pure functions are also easy to test given that type signatures can be used for property-based test generation.I think once all these components (LLMs, SAT/SMT, and lightweight formal methods) get combined, some interesting ways to build new software with a human-in-the-loop might emerge, yielding higher quality artifacts and/or enhancing productivity.

td2: Wouldnt a fair counter argument be, that llms have been trained on way less fu ctional code though?Like they are trained on a LOT of js code -> good at js Way less functional code -> worse performance?

wavemode: The article presents a function making use of global variables, declares it bad, and then proposes that the solution is functional programming.There's nothing wrong with functional programming, but the implication that all non-FP code is hard to test and uses global state is naive.

nextos: That's a very fair point. There are some publications showing lower performance for languages with less training data. I imagine it also applies to different paradigms. Most training code will be imperative and of lower quality.

ZitchDog: I've been having good luck with fairly autonomous LLM coding with the following rules: * TypeScript everywhere with extreme enforcement of the type system. * No "as" casts, no "any" declarations, all code must understand the shape of its data * All boundaries validated using a typed validation library. Many use zod, I prefer tjs. I also have strictly typed pg and express wrappers. * No files longer than 300 lines * All of these rules are enforced by an eslint configuration that runs in a pre commit hook. Global state and classes could also be removed via eslint rules, that would be interesting, though I haven't found it to be an issue in practice once the types are strictly enforced.

laitopezz: My impression too. Most of what is in this post I've discovered almost entirely through clojure and I'm not even a clojure dev, just try to explore it in my free time. I did cmd + f in browser and searched for clojure pretty soon in to reading this.

cyrusradfar: OP Here:it’s not discussed in this post but in another right after I discuss the modeling I was doing on tech debt and finding the game to improve agent outcomes was reducing context.functional programming accomplishes that. I can’t claim it’s the only way, but it’s one that’s well understood in the community

mvellandi: You can write functional-style code in many languages, as I have in JS and occasionally Python to great benefit.

majormajor: What makes is special about "agentic development" vs reducing context requirements, reducing cognitive burden, etc for human development too? "A human developer builds a mental model of a codebase over months"—yeah, that makes onboarding to a codebase very time consuming, expensive, and error-prone.So why is "better for agents" distinct from "better for humans"?

brap: I really like the “functional core, imperative shell” approach, I try to use it whenever I can. I wish more non-FP languages had a way to mark a function as pure (and have this statically enforced).

yangshi07: So glad to see someone working on making fucking coding better — making LLMs write good code, not just vibe and wow, and not just pretend the code is magic.

bitexploder: Agents can simply be told to write code in a functional style. They won’t complain. Think of it like a constraint system or proofs system. The agent can better reason about the code and side effects. Etc. Agents are very good at following and validating constraints and hill climbing. This makes sense to me. Humans benefit too, but it is hard to get a bunch of humans to follow the style and maintain it over time.

brap: How do you enforce the use of validation library with eslint?

hurril: It really isn't. Having worked for several decades on "both sides", this really is my experience. The functional side is better typed and has fewer side effects of this kind. It is more normal, as in more common, to have code work correctly as soon as it compiles. This is my lived experience having worked with Java, Scala, F# and Rust since 1999.