.NET's Sometimes Nonsensical Logic
-
You're not wrong. But you're not right either. Maths vs. Words :-D
-
Someone really should start a weekly blog of inane .NET logic when it comes to what it does or does not throw an exception for vs. just behaving according to some default arbitrary choice. Entry #1: On an empty collection, `.Any()`, with our without a condition, always returns `false`, as any sane person would expect. However, `.All(condition)`, on an empty collection, returns `true`. HUH? If I look at an empty room and ask "Are all the people in there aliens?" the answer I expect is apparently YES? If ever there were a situation where a method call is so nonsensical that there is no possible objectively right way to handle that which everyone would agree on (thus justifying an Exception), it's asking about `All` the items in an empty collection. It's tantamount to division by zero. And yet on a `null` collection, even though these are all extension methods and perfectly capable of treating `null` as empty, it throws .NET's all time favorite and #1 most useless exception, `NulLReferenceException`. Clearly the .NET developers' goal is to ruin as many of my days as possible.
Have you ever heard of first-order logic - the logic which has been used formally for about 200 years (and informally much longer; on the order of 2000 years) for all sound reasoning in mathematics? Where it is obviously correct that "there is no x where P(x) is false" is equivalent with "for all x, P(x) holds" - because otherwise, that calculus would explode in your face ... Have you ever heard about vacuous truth? If not, please take some time to learn about these things. That's neither a .Net nor a Microsoft thing - it's basic logic knowledge. H.M.
-
Someone really should start a weekly blog of inane .NET logic when it comes to what it does or does not throw an exception for vs. just behaving according to some default arbitrary choice. Entry #1: On an empty collection, `.Any()`, with our without a condition, always returns `false`, as any sane person would expect. However, `.All(condition)`, on an empty collection, returns `true`. HUH? If I look at an empty room and ask "Are all the people in there aliens?" the answer I expect is apparently YES? If ever there were a situation where a method call is so nonsensical that there is no possible objectively right way to handle that which everyone would agree on (thus justifying an Exception), it's asking about `All` the items in an empty collection. It's tantamount to division by zero. And yet on a `null` collection, even though these are all extension methods and perfectly capable of treating `null` as empty, it throws .NET's all time favorite and #1 most useless exception, `NulLReferenceException`. Clearly the .NET developers' goal is to ruin as many of my days as possible.
One more for MS is right here (what??? how is that possible.) Not really different from what others already wrote, but this is how I see it... For me, Any(x) is the same as All(!x) so this must be true: if list.Any(x) == false then list.All(!x) == true which is true with the current implementation. What you expect results in: list.Any(x) == false and list.All(!x) == false. ... it's correct under your assumption, but to me it's illogic logic :).
-
In your example, the sergeant is probably asking about the set of soldiers assigned to the platoon (regardless of status). In which case, the set isn't empty, and the answer is "no". However, if the sergeant was asking if all soldiers in your platoon who were capable of showing up were there, then the answer is "yes". Note: technically, the set still isn't empty, as you are presumably in your own platoon. However, the logic would still apply if the question was asked about another platoon where no one was left alive - everyone who was capable of showing up would be there...
The officer doing the asking is enquiring about the present state of his platoon, not what it might have been. He wants to know how many men he has left in that platoon, if any (he's a practical chap). The Sergeant isn't necessarily a member of the platoon in question. It's a valid question before possibly sending the platoon out on another patrol, one which requires a practical answer. A platoon now devoid of soldiers wouldn't perform well on patrol.
-
The officer doing the asking is enquiring about the present state of his platoon, not what it might have been. He wants to know how many men he has left in that platoon, if any (he's a practical chap). The Sergeant isn't necessarily a member of the platoon in question. It's a valid question before possibly sending the platoon out on another patrol, one which requires a practical answer. A platoon now devoid of soldiers wouldn't perform well on patrol.
Exactly! The officer needs to know how many men are available (a platoon of one wouldn't perform well either). He could have asked, "How many are available?" But he didn't (in this example). Presumably he can see there's no one there, so he effectively asked, "Is this everyone in the platoon?" The correct answer at that point is "Yes", at which point he knows what he has to work with (even if it's zero). To answer No at this point would imply that there are others who are not present, which isn't the case. If we were to write that in code, it would be Platoon.AreAllPresent(), and the result would be True as long as no members of the Platoon are absent (even if there are no members of the Platoon).
