Thanks for clarifying. I think “we could try what OP proposes, if it sucks it’s probably not that expensive to LLM-rewrite in cleaner” is a reasonable argument.
Personally I’m just less certain than you are I feel. If I had to bet on it I would assume that the things you listed are objectively useful, not just for humans. But I’m not actually any sort of sure of it, and if a bunch good new studies came out tomorrow showing that LLMs do extremely good without linters or immutability or something I would not be surprised either.
Same with clean, good, cheap LLM-rewrites. Sounds reasonable enough but we haven’t seen much of it yet and I’d not be surprised if there were cases in which it absolutely failed.
So personally I’d rather give the whole thing a bit of time for data to come in to validate whether our intuitions are actually correct, or just reasonable but ultimately false guesses.
Guess at the pace this thing is moving I’m SOL however.
making certain classes of bugs evaporates a lot of “bad code” space. Some things like nulls are obvious net-losses given the birth of nullrefs; others like immutability might be hard to grasp if not used, but there’s so many bugs that arise from state not being what you expect it to be. Didn’t assign, copy by value vs reference, etc etc; birthing a class of bugs.
For types/lints etc: the more ways you can desribe your constraints for program behaviour, the more different sources of invariants can overlap, leading to feedback, where collisions appear. Same as naming, although that’s more heuristic than programmatic.
For the most, main issues for adoption has been onboarding, tooling support etc. Well, now it’s easier to build tools, an onboarding is a skill download. Another issue would be that models have less training data. This might be the case, but that’s mostly a problem for very niche languages, rust is sufficient and it can also write nix-derivations, which is famous for bad docs :)
note that I’m obviously biased by Haskell elitism. Rust avoids a bunch of memory bugs and has more reliable performance, which makes it way feasable in my experience.
Thanks for clarifying. I think “we could try what OP proposes, if it sucks it’s probably not that expensive to LLM-rewrite in cleaner” is a reasonable argument.
Personally I’m just less certain than you are I feel. If I had to bet on it I would assume that the things you listed are objectively useful, not just for humans. But I’m not actually any sort of sure of it, and if a bunch good new studies came out tomorrow showing that LLMs do extremely good without linters or immutability or something I would not be surprised either.
Same with clean, good, cheap LLM-rewrites. Sounds reasonable enough but we haven’t seen much of it yet and I’d not be surprised if there were cases in which it absolutely failed.
So personally I’d rather give the whole thing a bit of time for data to come in to validate whether our intuitions are actually correct, or just reasonable but ultimately false guesses.
Guess at the pace this thing is moving I’m SOL however.
making certain classes of bugs evaporates a lot of “bad code” space. Some things like nulls are obvious net-losses given the birth of nullrefs; others like immutability might be hard to grasp if not used, but there’s so many bugs that arise from state not being what you expect it to be. Didn’t assign, copy by value vs reference, etc etc; birthing a class of bugs.
For types/lints etc: the more ways you can desribe your constraints for program behaviour, the more different sources of invariants can overlap, leading to feedback, where collisions appear. Same as naming, although that’s more heuristic than programmatic.
For the most, main issues for adoption has been onboarding, tooling support etc. Well, now it’s easier to build tools, an onboarding is a skill download. Another issue would be that models have less training data. This might be the case, but that’s mostly a problem for very niche languages, rust is sufficient and it can also write nix-derivations, which is famous for bad docs :)
note that I’m obviously biased by Haskell elitism. Rust avoids a bunch of memory bugs and has more reliable performance, which makes it way feasable in my experience.