Quote:
Originally Posted by chezlaw
It's a huge but common mistake to think that a principle in general fails because it fails at the extremes.
The huge common mistake is the other way around. I am very certain of this, and I hope that I can convince you to agree with me because it is a relatively simple but quite important truth to get right.
If I say that it is true that "it is never right to lie", and then you tell me "what if you are hiding jews from the nazis, and the nazis knock on your door, and ask you if you are hiding any jews?"
I have two options.
1) Stick with my position that it is never right to lie, thus letting the jews be murdered.
2) Accept the evidence that has been presented to me and accept the fact that my original position, namely, that is is never right to lie, was incorrect.
The fact proposed, that "It is never right to lie" has been shown to be erroneous. I dont care if you change it to be <exception>, <outlier>, <etc>, I really dont give a damn, it doesn't change the fact that what was proposed above has been shown to be wrong, and the only way it was shown to be wrong was by an extreme case, and that was all that was needed. If you change it to be something else, we will look at it again, but we are not talking now about something else, we are talking now about what was proposed and nothing else. The process can be repeated many times, but it cannot be changed half way thru the process.
As you can see, the fact that it did not hold in an extreme case means that it does not hold in any case*. In programming, if you have a function that you say will never return null, but it in fact returns null in some situations, then you have broken your contract and your code needs to be changed. If your code makes it to production and you knew about this ahead of time... *** help you. It doesn't matter that your code "works in most situations" and if that is your excuse when asked -- if you appeal to the fact that in most situations your code works just fine -- youre done for.
It could be noted that in programming, when you give your code off to a tester and tell them that it works just fine, the first thing they do is go for the extreme case. The first thing they check isn't "well, what if the contents of the file are formatted mostly correctly but there's an extra 'e' at the end?" its "what if the file doesn't exist?" "what if the user puts "rm -rf /" in the file?" etc. And when they go for these extreme cases and those cases fail, they dont say "well, it works for most cases, so lets ship it" ... they send it back to you. When you make your changes and think that it is good, the process starts all over again. This is a practice that works, and it works very well. The practice of saying "the fact that it doesn't work in extreme cases doesn't mean its not good code" would not work anywhere.
* edit: by this I mean it was shown to be wrong. A broken clock is right at least once a day, but that doesn't mean you can use it to tell time. The fact that it can get things right sometimes is not a reflection of its working state. It actually might be wrong to say "it doesn't work in any case" because of course, the case where the broken clock is stuck on 12 and its noon is an example of a working case. What should probably be said is that because it doesn't work in the extreme case, we know that it has > 0 flaws, and cannot be fully true. If it is not fully and completely true, we cannot use it for deductive logic and deduce things from it, because it would be impossible to know if our deduced facts are true when the thing we are deducing from has been shown to be, in > 0 cases, untrue. And the whole value of the statement is for its deductive value. We dont care about knowing if it is never correct to lie because of some abstract value of knowing it -- we care about it because if it is true we can deduce from it what actions we should or should not make in our life.
Last edited by Ryanb9; 06-27-2020 at 10:18 AM.