This question already has an answer here:

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?

marked as duplicate by Karl Bielefeldt, gnat, Michael Durrant, Glenn Nelson, user40980 Oct 5 '13 at 4:12

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • from my answer "... 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. ..." – Andyz Smith Oct 5 '13 at 4:19
  • If you want function getSelectedRowIndex to return a boolean value, that's fine. You shouldn't care what the underlying representation happens to be. If you expect to get back, say, an integer where some magic value has truthiness, then you are in for a lot of disappointment. I'd like to take this opportunity to nominate 0x2a as The Answer. (IIRC, VB was one of the languages that just checked the LSB. You had to normalize any value that might have come from the outside world to ensure that it didn't muck up. Sigh.) – HABO Oct 5 '13 at 13:19
  • 2
    This is NOT a duplicate. I was actually referencing that question in the beginning of my question! (I've added a link to it to clarify that). That question is essentially why was 0 made to be false. My question is, is there still value in keeping it false or is there now more value in today's programming environment to switch it to true, as the title states. If necessary, I will edit it further, but I think the distinction is pretty clear, but regardless, please remove the duplicate status (and the negative vote if that was the reason why). – dallin Oct 6 '13 at 3:39
  • @dallin Yeah, I agree.. Not sure why it was closed. One suggestion is to edit the title to something like, "Why do new languages still treat 0 as false?" instead of using "modern programming language". – Izkata Oct 6 '13 at 3:58
  • One question: If 0 became truthy, what would false be? Are you thinking about languages like Python, that actually have True and False, or like C which just use 1 and 0 in the background? – Izkata Oct 6 '13 at 4:04

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:

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.


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


  • It goes deeper than assembly - digital logic (i.e. hardware) uses 0 and 1 for false and true - usually 0 is a low voltage (close to 0V) and 1 is a high voltage (close to Vcc, or whatever the supply voltage is). Logic design uses truth tables, Karnaugh maps and various other tools and even low level languages such as VHDL, all of which use the basic convention that 0 = false and 1 = true. – Paul R Oct 5 '13 at 6:33
  • @PaulR although true, this does not in any way address the question of why this conventione exists or whether it is still appropriate today. especially in the circumstances you describe, it is quite easy to invert the logic and have it make just as much sense. I suggest that the ALU is the first basic unit where the conceptual conversion between a boolean value and an integer value is introduced with a specific reason why a ZERO is false, because of the ALU CPU subtraction/comparison fungibility. – Andyz Smith Oct 5 '13 at 7:10
  • I disagree - in the early days of computing there was a much closer link between the programming model and the underlying hardware (there was virtually no distinction between the two originally). With such a long heritage, and its continued use today in logic design, and furthermore the fact that there is no obvious reason to change a convention that has always worked perfectly well, it is easy to see why we still use this convention today, at all conceptual levels. – Paul R Oct 5 '13 at 8:43
  • @PaulR but i'm sayng there's an actual, tangible, design. optimization based reason for the convention. – Andyz Smith Oct 5 '13 at 14:05
  • Well I'd say that there are a lot of reasons, some more significant than others, but it all boils down to common sense and efficiency. That was true when Boolean logic was first invented, when the first digital logic was implemented with relays and valves (tubes), and it's still true today, even though we've abstracted ourselves a long way from the underlying hardware. – Paul R Oct 5 '13 at 15:26

Not the answer you're looking for? Browse other questions tagged or ask your own question.