My best answer, from the mass of others discussed.
This convention comes from Assembly.
When you do a comparison, e.g. if a > b or if a = b
what actually happens ( at least in motorola 6502 ) is the processor will SUBTRACT the two values! then then result is easily branchable, because it is either zero, or something other than zero.
the branch instruction is made to work with zero being an optimized value because typically you want to branch when an array index reaches zero.
thus, branchng is optimized for zeros, and thus branching based on comparison has evolved to use zero to indicate true of false of a boolean operation like = or >.
Also because a bit by bit comparison of two numbers is basically the same thing as a bit by bit subtraction using the [Adder] http://en.wikipedia.org/wiki/Adder–subtractor in the ALU. so this way, you don't have extra instructions laying around. But if you use subtraction for boolean comparison you have to allow that the result of the integer subtraction being zero will mean that something is true or false. thus false is zero.
i guess the reason for keeping it this way is that because originally, there were good reasons for doing this besides ' we felt like it'. those good reasons i suspect are highly irrelevant now, but, OTOH deep down, i also suspect the same optimizations occur with booleans in modern languages
Wikipedia notes that:
Determining whether two values are equal requires the ALU to determine whether the result is zero. This can be accomplished by feeding each bit of the result into a NOR gate. The beauty of this is that a single multi-port NOR gate requires less hardware than an entire array of equivalent 2-port gates.
So, zero has a special meaning for CPUs and ALUs. That is why zero is false.
i suspect that ALU design has not trancended this fundamental design optimization, even in the newest processsors, and as such, people writing compilers in assembly or close to assembly languages are probably still faced with the 'dirtiness' of equating zero with false. And you should know about all this too. just because.
"A lot of programmers that you might interview these days are apt to consider recursion, pointers, and even data structures to be a silly implementation detail which has been abstracted away by today’s many happy programming languages. “When was the last time you had to write a sorting algorithm?” they snicker.
Still, I don’t really care. I want my ER doctor to understand anatomy, even if all she has to do is put the computerized defibrillator nodes on my chest and push the big red button, and I want programmers to know programming down to the CPU level, even if Ruby on Rails does read your mind and build a complete Web 2.0 social collaborative networking site for you with three clicks of the mouse."