[marcus_holmes]

> there is no general specification for correct translation from English to Code.

that's an interesting point. Could there be?

COBOL was originally an attempt to do this, but it ended up being more Code than English.

I think this is the area we need to get better at if we're to trust LLMs like we trust compilers.

I'm aware that there's a meme around "we have a method of completely specifying what a computer system should do, it's the code for that system". But again, there are levels of abstraction here. I don't think our current high-level languages are the highest possible level of abstraction.

[whaleidk]

No, there can’t be. Code keywords are tied to concrete mathematical concepts. Human languages are not. and even if you tried, the more languages you add to the LLM’s pool, misinterpretation chances increase exponentially. You can’t just choose English to be the programming language either, because then you would be asking every non-English speaking developer in the world to first learn the entirety of the English language which is way harder than just learning a programming language. Why are programmers so scared of code and math??

[lock1]

No, there isn't.

I guess you could pick a subset of a particular natural language such that it removes ambiguity. At that point, you're basically reinventing something like COBOL or Python.

Ambiguity in natural languages is a feature, not a bug. While it's better not to be an unintentional pun or joke instruction that might get interpreted as "launch the missile" by computer.

However, each project error tolerance is different. Arguably, for an average task within the umbrella of "software engineer", even current LLMs seem good enough for most purposes. It's a kind of similar transition to automatic memory managed language, trading control for "DX".