4 ms·

The problem is that there are two very different contexts: users and developers. If a developer is testing their new program by having it interface with your pr

The problem is that there are two very different contexts: users and developers. If a developer is testing their new program by having it interface with your program, you want to be strict in what you accept; this enables them to make their program strict in what it emits, and helps bugs surface early. But if an end-user is hooking your program up to some other program, then you want to be generous in what you'll accept, so that it'll work. Compilers solve this by having an intermediate levels of strictness: warnings, which a developer who's providing input to the compiler is expected to fix, but which an end-user doesn't have to. This captures the benefits of both strict and lax input checking. It helps to make similar distinctions in other contexts, whether that's having an explicit notion of "warnings", or just putting messages in log-file output. It also helps if a format has a well-known extra-strict checker around, which developers can test their programs' output on.

zAy0LfpBZLC8mAC 9y ago
> But if an end-user is hooking your program up to some other program, then you want to be generous in what you'll accept, so that it'll work. No, you absolutely don't. The only reason why you would possibly need that in the first place is because software tends to be far too forgiving. Where software enforces procotol/format compliance, a normal end user essentially does not ever get to see any deviating input because generating software is written to the standard right from the start, and the few cases where that fails, the actual bug gets fixed. Also, you actually can't. When the standard does not specify the meaning of some input, then there is no meaning. Whatever meaning you invent for it is just that: Your invention. The next software likely will interpret things differently. You do not actually have a standardized format when multiple implementations speak the same syntax, they also need to have the same semantics. Just doing something in response to broken input does not produce interoperability, but just undefined behaviour.

zAy0LfpBZLC8mAC 9y ago

> But if an end-user is hooking your program up to some other program, then you want to be generous in what you'll accept, so that it'll work. No, you absolutely don't. The only reason why you would possibly need that in the first place is because software tends to be far too forgiving. Where software enforces procotol/format compliance, a normal end user essentially does not ever get to see any deviating input because generating software is written to the standard right from the start, and the few cases where that fails, the actual bug gets fixed. Also, you actually can't. When the standard does not specify the meaning of some input, then there is no meaning. Whatever meaning you invent for it is just that: Your invention. The next software likely will interpret things differently. You do not actually have a standardized format when multiple implementations speak the same syntax, they also need to have the same semantics. Just doing something in response to broken input does not produce interoperability, but just undefined behaviour.