edit: as to the "annoying" that's just Yarvin being cheeky. I really don't think it is too serious.
If we have a situation in which there are many numeric codes, exactly one of which means "success", it's probably best if that one is assigned zero.
https://news.ycombinator.com/item?id=11819810 item #3 (and subsequent discussion)
So why are they punning integers and booleans in the first place?
If a language doesn't have a Boolean type, and some other type serves for indicating truth/falsehood, then that is a representational technique distinct from punning.
A language with no Boolean type can be statically typed. It just means that the conditional operators work with some non-Boolean, like integer, yet according to well-understood rules. For instance if we have some "if expr foo bar" such that either foo or bar is evaluated based on whether or not expr is zero. This would be statically well-typed if expr has integer type and foo and bar have the same type.
Of course, we can't do pattern-matching whereby a value is classified as Boolean or integer in separate cases. (Unless we use the language's type construction ability to define a Boolean type which wraps integer, or whatever).
Yes, I know.
> (Of course, this situation quite good).
I think that's debatable. Javascript, for example, does something similar but it takes all empty containers as false, along with zero and a few other things. (Not that I am necessarily holding up Javascript as an example of good language design. My point here is just that there is not a consensus on how (or whether -- c.f. Scheme) to conflate booleans with other types.)
The salient differences between CL's boolean conflation and Hoon's are:
1. CL's conflation design is justifiable in terms of how it simplifies coding recursion over a list, which is the single most important Lisp coding idiom.
2. Hoon tries to justify using zero as true by saying that non-zero integers can carry information about the nature of a failure. (At least I've heard some people try to justify it in this way. I'm not sure if Curtis does not not.) But now you are no longer conflating integers with booleans, you are conflating integers with multiple enum types, one for every possible set of failure types. Flouting convention is one thing. Flouting convention in order to enable conflation of integers and enums undermines Hoon's claim of being strongly statically typed (at least in any interesting way).
The Javascript design means that we cannot test for the absence of an integer in this manner, because a negative result could mean that a zero is present.
It could be handy from time to time. I propose a NAUGHT function for Lisp which returns true for empty sequences, empty hashes, zero (integer, real or complex) and any other nothing you can think of.
Yes, if this language were to exist in a complete vacuum, where no other languages are existing, and nobody learnt anything else before, then sure, 0 as true and 1 as false would be fine I guess. Still not more or less intuitive, but one could agree on using it. But in a world where every other programming language uses 0 as false (or some equivalent) and where the chance that someone would use "nock" as his one and only programming language is very much 0%, this feels like utter bullshit.
Also, the versioning scheme based on Kelvin temperature? Seriously?
And then look at the Hoon syntax. No keywords, just ASCII symbols. Just look at it.
This better be some very elaborate hoax...
Does the opposite approach make sense though? Generally, something being "true" means a program can happily move along. Something being "false" generally requires more introspection on why exactly it's false, i.e. error handling, exception handling, with the resulting changes in execution flow.
But to use it everywhere flies against the origin of it, which is current flowing vs not.
FALSE == TRUE & FALSE ==> 0 & 1 == 0 ==> TRUE