If you structure your prompt around small, stateless functions with explicit inputs/output, answers may look cleaner, but that advantage is not at the language level. You can do the same in TypeScript et al and get the same results.
I don’t doubt that anecdotally you’ve had favorable results. However, I’m not aware of any research that backs up this claim. Or forget research - I’m not aware of any simple examples / prompts that would show it in a reproducible way across different LLMs.
> I’m not aware of any research that backs up this claim
These things are literally days old. Claude 4, which is arguably the first truly useful LLM code assistant, released in May. Scientific research proceeds at a glacial pace. I'm just speaking from anecdotal experience. It may be a perceptual illusion, or it may be a real thing. Just my data point.
One could deduce that restrictive languages would naturally result in fewer runtime bugs produced by LLM's since they do the exact same thing for people. For example, Elm is literally designed to produce NO runtime errors, so coding Elm in an LLM (which I haven't done) would ostensibly result in almost all errors being caught upfront.
This is not to say that other types of logic errors, redundancy, etc. wouldn't slip through without human intervention.
I don’t doubt that anecdotally you’ve had favorable results. However, I’m not aware of any research that backs up this claim. Or forget research - I’m not aware of any simple examples / prompts that would show it in a reproducible way across different LLMs.
Corpus size tends to dominate performance.