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.
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?
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.
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.
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.
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).
11 comments
[ 2.8 ms ] story [ 36.2 ms ] thread> 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.
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.
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.