How is correct defined? Per the language spec? The architecture of the system it's meant to execute on? It's a very unclear target to try and aim at, as a definition, and strikes me as a rather academic approach to how things should work.

An interesting thought experiment here is to consider that in this instance correct code relies upon two or more other instruction handlers behaving correctly: the JVM and (at least) the host CPU. Thus, even correct code can be vulnerable to problems (see: Speculative execution vulnerabilities). If the goal of programming is to write correct code, what % of errors on that correct code execution is permissible?

The whole argument strikes me as an appeal to a platonic ideal rather than reality.

> How is correct defined?

My project managers always define it as "implements this vaguely worded set of contradictory requirements as well as this other set of undocumented contradictory requirements and is finished by tomorrow".

There is also the OS which can fail to uphold “the spec” it promises, causing bugs. But agree that perfect safety is meaningless.

The prime directive in programming is to read and understand the code the code and tools you are relying on (the hard part).

Everyone skips the hard part, and squabbles over whether it's okay or possible to redefine 'high quality' to include code written by people who never did the hard part.

Suffering by software's user's is tge inevitable result of this misclassification of the prime directive to be "write" oriented.

The prime directive in programming is to make money....