[Lammy]

"The final nail in the coffin is that – opposite to the real world – in Urbit, 0 is a truthy value, and 1 is falsy. This is the most pretentious, harmful, arrogant, and vain design decision I have seen in years. It underscores that Urbit is not a serious effort but a vanity project."

UNIX Style Considered Harmful https://pubs.opengroup.org/onlinepubs/9699919799/functions/e...

[thewakalix]

Today I learned that both C and shell are "not serious efforts but vanity projects". The more you know...

[riverlong]

Where in C is 0 truthy (or 1 falsy)?

[jstanley]

strcmp,memcmp,etc. return 0 for equality, maybe you'd count that? But it's not really indicating "true", more "no difference".

main() returns 0 for success, but I expect that is owed more to Unix.

A lot of (e.g. Linux) system calls return 0 for success and an error value on error, but again that's more down to Unix than C.

[riverlong]

I wouldn't count strcmp, etc. It returns < 0 if str1 is shorter and > 0 if str1 is longer. Returning 0 means there is 0 difference. That's not a True/False.

"0" is not a "truthy" exit code for a system call, it rather denotes the absence of an error.

In my view, a value X being "truthy" means that `bool(X)` evaluates to TRUE, or `if(X)` gets executed.

[vegetablepotpie]

I think it’s where many functions return 0 when they are successful.

[leeoniya]

maybe cause there's only one way to succeed and many ways to error. 0 success and 1..N are error codes.

what is a reasonable alternative?

(this isnt the same as 0 false and 1 true)

[toomim]

Ok, but:

     success vs. fail

is different than:

     true vs. false

They're both binary, but only one is boolean.

[voxic11]

https://pubs.opengroup.org/onlinepubs/009695399/basedefs/std...

[saagarjha]

I think those go in the opposite direction.

[foobiekr]

Well, unix, as in exit codes.

[riverlong]

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]

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]

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

[creata]

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

[praptak]

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.

[pasquinelli]

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]

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.