5 ms·

Functional programming accelerates agentic feature development

59 points by cyrusradfar 6mo ago

pmarreck 6mo ago
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.
lispisok 6mo ago
This article is just describing Clojure. The SUPER principals are describing the native natural way of writing Clojure, no category theory needed.
- cyrusradfar 6mo ago
  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?
- deleted 6mo ago
  [deleted]
- laitopezz 6mo ago
  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.
4b11b4 6mo ago
close
Tadeuvich 6mo ago
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?
- nextos 6mo ago
  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 6mo ago
    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?
    - nextos 6mo ago
      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.
    - mvellandi 6mo ago
      You can write functional-style code in many languages, as I have in JS and occasionally Python to great benefit.
      - 6mo ago
wavemode 6mo ago
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 promoting functional programming, but the implication that all non-FP code is hard to test and/or uses global state is naive.
- hurril 6mo ago
  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.
- DeathArrow 6mo ago
  The author doesn't promote functional programming in the strictest sense, he just suggests to use functions that do not have side effects. He argues against changing state. You can even do it in .NET using dependency injection (which is a kind of an OOP) concept: just supply dependencies as constructor parameters and do not change state in the service/handler. You can follow the same concepts with ease using Go and no one will argue Go is a functional programming language. So, the idea is not to do straight functional programming but to apply some lessons from the functional programming. And I find the article to be very logic and even if I did not apply the same rules as the author, I empirically observed that coding agents shine where they don't have to argue much about state, the more state there is to keep track of, change and reason about, the harder it is for both humans and coding agents to do changes without breaking things. And since I like the author's ideas I am willing to spend some tokens and put them to the test. The only things I would add on top of this is modularization, either by using Vertical Slice Architecture or by designing a modular monolith where each module is isolated and has its own contract. Because, the less source code an agent has to reason about, the better are the results. So my next greenfield experimental project will feature: compound engineering, TDD, SUPER and SPIRALS (as in the article) and modularization.
ZitchDog 6mo ago
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.
- brap 6mo ago
  How do you enforce the use of validation library with eslint?
  - ZitchDog 6mo ago
    Can't fully enforce that one, but I require only my specific HTTP router / SQL library to be used, and disallow the import of express / pg libraries via eslint. I also disable the use of JSON.parse via eslint. Combined with strong language in the CLAUDE.md, I haven't seen it get around my guard rails.
yangshi07 6mo ago
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.
brap 6mo ago
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).
- codethief 6mo ago
  Agreed. "Prefer pure functions, push side effects to the boundary (functional core, imperative)" is at the top of my CLAUDE.md these days.
meidad_g 6mo ago
[flagged]
midnight_eclair 6mo ago
even if i would generally agree with the principles, no amount of markdown prompting is going to increase my confidence in agent's output and so i keep asking this question: > what do you use for normative language to describe component boundary, function and cross-component interactions? something i can feed into a deterministic system that will run a generative suite of tests (quickcheck/hypothesis/clojure.spec) that will either give me the confidence or give the agent the feedback.
- cyrusradfar 6mo ago
  OP / Author here, I started closer to where you are but ended up realizing I've led a few eng teams and was never satisfied with code quality. What I COULD be satisfied by was moving our metrics in the right direction. Testing coverage, use cases covered by E2E / integration tests, P99/backend efficiency metrics, cost of infrastructure and obviously user growth along with positive feedback from Users. That said, I don't "vibe" because it creates great code I love reading, but I can monitor and move the same metrics I would if I was managing a team. I also use code tours a bit, and one of my first tools I needed and built (intraview.ai) was to support this need to get deep in the code the Agents were claiming was ready to ship.

59 points by cyrusradfar 6mo ago

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.

lispisok 6mo ago

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

cyrusradfar 6mo ago
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?
deleted 6mo ago
[deleted]
laitopezz 6mo ago
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.

4b11b4 6mo ago

Tadeuvich 6mo ago

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?

nextos 6mo ago
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 6mo ago
  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?
  - nextos 6mo ago
    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.
  - mvellandi 6mo ago
    You can write functional-style code in many languages, as I have in JS and occasionally Python to great benefit.
    - 6mo ago

wavemode 6mo ago

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 promoting functional programming, but the implication that all non-FP code is hard to test and/or uses global state is naive.

hurril 6mo ago
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.
DeathArrow 6mo ago
The author doesn't promote functional programming in the strictest sense, he just suggests to use functions that do not have side effects. He argues against changing state. You can even do it in .NET using dependency injection (which is a kind of an OOP) concept: just supply dependencies as constructor parameters and do not change state in the service/handler. You can follow the same concepts with ease using Go and no one will argue Go is a functional programming language. So, the idea is not to do straight functional programming but to apply some lessons from the functional programming. And I find the article to be very logic and even if I did not apply the same rules as the author, I empirically observed that coding agents shine where they don't have to argue much about state, the more state there is to keep track of, change and reason about, the harder it is for both humans and coding agents to do changes without breaking things. And since I like the author's ideas I am willing to spend some tokens and put them to the test. The only things I would add on top of this is modularization, either by using Vertical Slice Architecture or by designing a modular monolith where each module is isolated and has its own contract. Because, the less source code an agent has to reason about, the better are the results. So my next greenfield experimental project will feature: compound engineering, TDD, SUPER and SPIRALS (as in the article) and modularization.

ZitchDog 6mo ago

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.

brap 6mo ago
How do you enforce the use of validation library with eslint?
- ZitchDog 6mo ago
  Can't fully enforce that one, but I require only my specific HTTP router / SQL library to be used, and disallow the import of express / pg libraries via eslint. I also disable the use of JSON.parse via eslint. Combined with strong language in the CLAUDE.md, I haven't seen it get around my guard rails.

yangshi07 6mo ago

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.

brap 6mo ago

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

codethief 6mo ago
Agreed. "Prefer pure functions, push side effects to the boundary (functional core, imperative)" is at the top of my CLAUDE.md these days.

meidad_g 6mo ago

[flagged]

midnight_eclair 6mo ago

even if i would generally agree with the principles, no amount of markdown prompting is going to increase my confidence in agent's output and so i keep asking this question: > what do you use for normative language to describe component boundary, function and cross-component interactions? something i can feed into a deterministic system that will run a generative suite of tests (quickcheck/hypothesis/clojure.spec) that will either give me the confidence or give the agent the feedback.

cyrusradfar 6mo ago
OP / Author here, I started closer to where you are but ended up realizing I've led a few eng teams and was never satisfied with code quality. What I COULD be satisfied by was moving our metrics in the right direction. Testing coverage, use cases covered by E2E / integration tests, P99/backend efficiency metrics, cost of infrastructure and obviously user growth along with positive feedback from Users. That said, I don't "vibe" because it creates great code I love reading, but I can monitor and move the same metrics I would if I was managing a team. I also use code tours a bit, and one of my first tools I needed and built (intraview.ai) was to support this need to get deep in the code the Agents were claiming was ready to ship.