4 ms·

Yeah, exit codes aren't what I'm talking about here. In Hoon/Nock, `if(0)` literally gets interpreted as True. That's insane.

tromp 5y ago
In lambda calculus, true and false are conventionally represented as functions lambda x. lambda y. x and lambda x. lambda y. y so that "if b then x else y" is represented by "b x y". When identifying booleans with bits, it seems natural to write this as "bit x_0 x_1" rather than "bit x_1 x_0" where the arguments seem to be in the wrong order. This is one possible justification for identifying true with 0 and false with 1.
knownjorbist 5y ago
It's not insane, just dissimilar to what you're used to.
- praptak 5y ago
  Dissimilarity for no good reason is, well, maybe not insanity but plain old dumb. Unless we're talking fashion not software projects, hence the "vanity" classification.
- creata 5y ago
  Okay, it's not insane, it just breaks from a convention followed by practically every programming language (and every logic / engineering / computing course) where integers can be interpreted as booleans. And that might be okay if there's a good reason, but the reasons given are pretty awful: https://news.ycombinator.com/item?id=11852434 https://news.ycombinator.com/item?id=11852434
  - nitrogen 5y ago
    Ruby is one popular example of a language with a truthy zero. This is to allow the use of truthiness to detect the presence of a value (as long as the value isn't false), even if the value is zero. Say I wanted to allow an environment variable to override a value in my code. I could do something like this: a = ENV['A']&.to_i || 1 and then run the program with A=0 to set a to 0.
    - jstanley 5y ago
      Perl has this too. The string "0 but true" is truthy, but is 0 as a numeric value. (Any string starting with 0 that doesn't evaluate to a different number also works - but "0 but true" is specifically exempt from causing warnings). DBI uses "0E0" instead, which I guess more reliably evaluates to 0 outside Perl, and still doesn't cause warnings.
    - int_19h 5y ago
      That approach is not unreasonable per se. But 1 being false is much harder to rationalize.
pasquinelli 5y ago
i don't really see why. if anything is insane, it's interpreting a number as true or false. but if you're doing that anyway, then you pick a number for false, or you pick a number for true. 0 is a natural number to pick for whichever truth value, because it's the base case of the natural numbers. it's unconventional, but no more insane than 0 = false, which, again, _is_ insane, but conventional. i'm not bothered either way
- drdeca 5y ago
  Using 0 as false and 1 as true has the benefit that + (mod 2) becomes xor and * becomes and. (or, if instead of mod 2, you use min(1,a + b) to keep things in the set, then + becomes or ) To use 0 as true and 1 as false, you don't get nice things like this. It's not nice. Well.. I guess * becomes or. But, + (mod 2) becomes, uh, xnor , and (min(1,a+b)) becomes, and... ok well I guess that's not as bad as I thought. Still a bad decision imo though.

tromp 5y ago

In lambda calculus, true and false are conventionally represented as functions lambda x. lambda y. x and lambda x. lambda y. y so that "if b then x else y" is represented by "b x y". When identifying booleans with bits, it seems natural to write this as "bit x_0 x_1" rather than "bit x_1 x_0" where the arguments seem to be in the wrong order. This is one possible justification for identifying true with 0 and false with 1.

knownjorbist 5y ago

It's not insane, just dissimilar to what you're used to.

praptak 5y ago
Dissimilarity for no good reason is, well, maybe not insanity but plain old dumb. Unless we're talking fashion not software projects, hence the "vanity" classification.
creata 5y ago
Okay, it's not insane, it just breaks from a convention followed by practically every programming language (and every logic / engineering / computing course) where integers can be interpreted as booleans. And that might be okay if there's a good reason, but the reasons given are pretty awful: https://news.ycombinator.com/item?id=11852434 https://news.ycombinator.com/item?id=11852434
- nitrogen 5y ago
  Ruby is one popular example of a language with a truthy zero. This is to allow the use of truthiness to detect the presence of a value (as long as the value isn't false), even if the value is zero. Say I wanted to allow an environment variable to override a value in my code. I could do something like this: a = ENV['A']&.to_i || 1 and then run the program with A=0 to set a to 0.
  - jstanley 5y ago
    Perl has this too. The string "0 but true" is truthy, but is 0 as a numeric value. (Any string starting with 0 that doesn't evaluate to a different number also works - but "0 but true" is specifically exempt from causing warnings). DBI uses "0E0" instead, which I guess more reliably evaluates to 0 outside Perl, and still doesn't cause warnings.
  - int_19h 5y ago
    That approach is not unreasonable per se. But 1 being false is much harder to rationalize.

pasquinelli 5y ago

i don't really see why. if anything is insane, it's interpreting a number as true or false. but if you're doing that anyway, then you pick a number for false, or you pick a number for true. 0 is a natural number to pick for whichever truth value, because it's the base case of the natural numbers. it's unconventional, but no more insane than 0 = false, which, again, _is_ insane, but conventional. i'm not bothered either way

drdeca 5y ago
Using 0 as false and 1 as true has the benefit that + (mod 2) becomes xor and * becomes and. (or, if instead of mod 2, you use min(1,a + b) to keep things in the set, then + becomes or ) To use 0 as true and 1 as false, you don't get nice things like this. It's not nice. Well.. I guess * becomes or. But, + (mod 2) becomes, uh, xnor , and (min(1,a+b)) becomes, and... ok well I guess that's not as bad as I thought. Still a bad decision imo though.