pull down to refresh
Wild speculation here, since I've never coded in a functional programming language before.
But I wonder if lambda calculus can be used to procedurally simplify AI generated code in a functional language.
Again, wild speculation. I am only just starting to dip my toes into these ideas.
A purely functional language would allow you to avoid certain classes of bugs, many resulting from imperative languages allowing you to do things that are hard to read, so should help some. But relative to a human programmer, I'd guess they'd still fail to produce human quality code in terms of readability.
Readability, unlike correctness, is less of a medium of expression problem than it is an empathy and mind of origin problem.
In general it is better to constrain the LLM into what you need BEFORE you let it do things, because bot runs are expensive. So you'd want to build that into your prompt somehow.
How would I describe this to a bot in a prompt?
PS: I saw something fun (but postvalidation, so it is still no bueno) this morning that may help with PR pre-review automation: an anti-slop linter. For example it has the nice rule no-known-value-widening, that would destroy you if you were to do:
function isUser(value: unknown): value is User {
return UserSchema.safeParse(value).success;
}
declare const user: User;
isUser(user);Which funnily, I ran into in my review of a library - about which I was complaining to k00b last week - where someone had a Fable-tagged commit refactoring their 50k line repo from javascript into typescript where all the types were any unless they were clearly a string or Buffer *cough*. I swear they must have one-shotted that entire refactor: /model fable-5.5-max Yo Claude convert my shit to typescript, tag a major version and push to GH. And then the CD pipeline will push your lib to npm after which 2 million dependents will use it. Especially because you push a vuln fix right after that.
I can't beat that kind of retardation. All I can do is jump out of a 15th floor window.
Agree. LLM code - for complicated features or fixes - often becomes hard to review, and with that it means that unless you fix it, it becomes hard to maintain. So it's either you yolo and narrate your way to riches, or you're in a world of pain.
It somehow doesn't go through the
simplifyphase enough on its own and instead seems to implement the prompt it got in all it's complexity (explicit or hallucinated.) That's what (most) humans do: break down the problem into something you can grasp easily and then code it. If I do this with an LLM it breaks it down then hallucibloats each phase anyway and it still messes up.I was checking this morning if I could have Claude rewrite a bloated plugin to reduce features by just deleting what I don't need, and with that reduce complexity, in code but also at runtime. It gave me 40 options to remove, eliminating about 140k lines of code, and 6 features to keep... but then it walked back on its own analysis and said "not a good idea because this code works and is unit-tested, and we'd have to remove 350+ test cases".