Is there any reason zero should still equal false in a new programming language? [duplicate]

Question

I understand that 0 is false because math established that a long time ago and C established it in the programming world, as talked about here. However, other than following established conventions, is there any reason a new programming language shouldn't make 0 equal to true? It seems like it would solve a lot of problems, such as in situations where 0 is a valid return value of a function (like when returning an index).

For example, assume I'm working with a grid where a user can select rows:

function getSelectedRowIndex()
{
    //return the index of the selected row - assume the first row is selected, returning 0
}

var selectedRowIndex = getSelectedRowIndex();  //returned 0

//the following will be evaluated as true, despite a valid row being selected
if (!selectedRowIndex)
{
    alert("Please select a row before continuing.");
}

I see this bug over and over again in multiple people's code. It's just much more convenient to evaluate a variable by itself. Making 0 equal to true would eliminate this potential bug. This is just one example, and I'm sure most people could think of others.

So we've established there is some value in making 0 equal to true, but what is the value in keeping it equal to false past sticking to what's always been done?

Answer 1

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 >.

PS

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.

SOOOOOOOOOOO

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:

Zero Flag

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.

http://en.wikibooks.org/wiki/Microprocessor_Design/ALU_Flags

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.

http://www.joelonsoftware.com/articles/ThePerilsofJavaSchools.html

"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."

http://www.joelonsoftware.com/articles/GuerrillaInterviewing3.html