Debate or argue
Test a program or demonstrate that it is correct? The second option, the more satisfactory route is to be preferred. Not just in IT …
Computer scientists have invented many methods to prevent their programs from having too many errors. A first consists, after writing a program, of testing it on a few hundred or thousands of cases. For example, a program looking for the exit of a labyrinth having been completed, it can be tested on a few hundred or thousands of different labyrinths. If the program does what is expected of it every time, it acquires certain inductive confidence in its correction. But as we cannot test all possible cases, nothing prevents a day from appearing an error anyway.
A second method consists of demonstrating that the proposed program is correct, that is to say in constructing a mathematical proof that, in any imaginable case, it will do what is expected of it. For example, after having written a program that seeks the exit from a labyrinth, it is a question of demonstrating that this program will always find an exit if there is one. Demonstrating the correction of a program is more difficult than testing it, but when you do, you are pretty much sure that no bug will appear when the program is in operation.
The notion of demonstration brings computer science closer to mathematics, but the notion of the test takes it away. In mathematics, if we want to convince ourselves that, for example, the result of the multiplication p × q of two numbers p and q are always identical to that of the multiplication q × p, the only possible method is the demonstration. Of course, nothing prevents us from testing a few cases such as 3 × 7 and 7 × 3, 12 × 25 and 25 × 12, etc. to familiarize yourself with the problem, or to formulate a conjecture, but these tests never contribute to a judgment of truth.
Unlike a demonstration, which involves only one person, the test of a program can be seen as a dialogue between two fictitious people: the author of the program, who claims that his program is correct, but without explaining why, and the tester, who objects to this assertion a situation where the program will eventually be defeated. If not, the objection is dismissed. And if all the objections of the tester are eliminated, the program is deemed correct. A demonstration, on the other hand, rules out in advance not only the objections of a hypothetical tester but all possible objections.
The test is therefore based on a strange reversal of the burden of proof: it is no longer the author of the program who must explain why it is correct, but it is his interlocutor who must find a situation in which the assertion of the programmer is defeated.
However, not being checked by your interlocutor does not mean that you are right; it can also mean that the other party has not found the right objection. This is why the fact that a program has been tested never excludes that an error may one day occur in a situation not explored by the tests. And this is why the mathematical method does not consist in taking any proposition for “true until proven otherwise”; in general, the scientific approach accepts inductive arguments only if it is not possible to advance deductive arguments.
This leads us to look suspiciously at the pre-eminence that our society attaches to dialogic methods, and in particular to adversarial debate, to the detriment of logical methods. As if we pretended to believe that putting aside the objections of his interlocutors was enough to be right.
Before an election, for example, instead of organizing a debate between the candidates, why would we not rather let them support their assertions with arguments, thus leaving them the burden of proof of what they assert?
