This article is just describing Clojure. The SUPER principals are describing the native natural way of writing Clojure, no category theory needed.
Functional programming accelerates agentic feature development
11–20 of 34 posts
Re: Functional programming accelerates agentic feature development
#12Earlier quoted context omitted.
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 fun…
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?
Re: Functional programming accelerates agentic feature development
#13There'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.
Re: Functional programming accelerates agentic feature development
#14This article is just describing Clojure. The SUPER principals are describing the native natural way of writing Clojure, no category theory needed.
Re: Functional programming accelerates agentic feature development
#15 * 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.Re: Functional programming accelerates agentic feature development
#16Earlier quoted context omitted.
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 fun…
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?
Re: Functional programming accelerates agentic feature development
#17Functional 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?
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
Re: Functional programming accelerates agentic feature development
#18Functional 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?
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
So why is "better for agents" distinct from "better for humans"?