[gobdovan]

Grandparent is onto something. You can't define correctness without a spec. And since most business-oriented software, which most of us work with, isn't made against a comprehensive spec, you can argue that anything falling outside it is either a bug or a feature. 'If your disk backup software corrupts backups' has behind it a clean definition that's (pretty) unambiguous and you don't care about, since it's already outsourced to some cloud solution. But 'User finds it easy to buy more stuff' does not.

Also, mandatory Sussman reference [0], where he talks about correctness not being that important and gives Google as example, that just needs to be close enough and not disastrously incorrect + interesting stuff around engineers confusing brittleness with correctness.

[0] https://www.youtube.com/watch?v=HB5TrK7A4pI

[coldtea]

>Grandparent is onto something. You can't define correctness without a spec.

Sure you can. Correctness doesn't mean "follows a spec", it means "It does what the developer intended it to do without problems".

I mean that casually and within reason, it's not supposed to be a formal statement checkable by proof checker. z

I don't need a spec to know that e.g. my email client has a bug if it crashes when I try to make something bold. The presense of the "Bold" formatting button means it should support it, spec or no spec.

[gobdovan]

I did not mention 'formal statement checkable by proof checker' anywhere. Correctness requires some criterion external to the implementation. Write it down and it's a spec. If you do not write it down and the behaviour is not one of the already-standard failure classes like crashing, corrupting data, losing work, then there is no principled way to classify it as a bug rather than an intended feature or tradeoff.