I am a horse in the land of booleans
iloveponies.github.io
I am a horse in the land of booleans
1–10 of 89 posts
Re: I am a horse in the land of booleans
#2[deleted]
Re: I am a horse in the land of booleans
#3I’m used to 0 and [] being falsy. Upsides and downsides to Clojure’s choice here?
Re: I am a horse in the land of booleans
#4I’m used to 0 and [] being falsy. Upsides and downsides to Clojure’s choice here?
0 and [] are real and meaningful values that have different meanings than nil/null (in what I assume you're referring to as Python) or (in JavaScript) undefined. They should be treated as such.
(That JS coerces the empty string to false is also bad.)
Re: I am a horse in the land of booleans
#5I’m used to 0 and [] being falsy. Upsides and downsides to Clojure’s choice here?
The trouble is that `if(value)` or `value && ..` ends up getting used as an idiomatic shorthand for "if value is present" even in languages (such as javascript and python) where 0 is falsey. Because most of the time it works, so people do it. And then inevitably get bugs when the value happens to be 0.
This can get increasingly hard to reason about the more datatypes you add which interpret 0-ish values as falsey -- as there's always the temptation to do, for 'consistency' with integer truthiness, e.g. https://lwn.net/Articles/590299/ about the python behaviour of dates being falsey in the first second after midnight.
If `null` and `false` are the only falsey values (ala clojure, ruby, elixir etc), that's a rule that's really easy to internalise and reason about, so you never have to worry about things like whether your data type might be falsey in the first second after midnight (and also `if(values)` is actually a correct idiom).
Re: I am a horse in the land of booleans
#6I’m used to 0 and [] being falsy. Upsides and downsides to Clojure’s choice here?
I'm also used to 0 being false. A possible upside to this is that you can use multiplication and addition as boolean AND and OR, which might not seem that useful, but I remember that BASIC on a ti99/4a had neither AND nor OR, but boolean expressions evaluated to 0 or 1, so you could use this trick.
Instead of
if x = 5 and y = 7 then goto 10
if (x = 5) * (y = 7) then goto 10
Re: I am a horse in the land of booleans
#7I’m used to 0 and [] being falsy. Upsides and downsides to Clojure’s choice here?
0 and [] are real and meaningful values that have different meanings than nil/null (in what I assume you're referring to as Python) or (in JavaScript) undefined. They should be treated as such. (That JS coerces the empty string to false is also bad.)
There is both null and undefined in JavaScript. Additionally, an empty array coerces to true because it's an object and objects are always truthy.
Personally I'd prefer that not even null/undefined coerced to false, or could otherwise be used in a boolean comparison, as for me they still signify different meanings and even in type-safe languages can lead to subtle bugs. I really dislike coercion having principally worked with JavaScript/TypeScript.
Re: I am a horse in the land of booleans
#8I’m used to 0 and [] being falsy. Upsides and downsides to Clojure’s choice here?
0 being falsy makes no sense outside of the C family of programming languages. But there 0 is overloaded both as a number and pointer (it's a bit more complicated though, as the value of the null pointer doesn't need to be zero but assigning 0 to a pointer will assign the null pointer).
In languages with more elaborate type systems, you usually have the pointer and number representation separated.
0 has no special meaning in regards to boolean logic but it has the special meaning of the identity/zero element in an additive group. Likewise, it makes sense to have "[1] + [] => [1]" in your programming language.
But making zero elements evaluate to falsy is problematic. "" would be falsy as well then.
Re: I am a horse in the land of booleans
#9I’m used to 0 and [] being falsy. Upsides and downsides to Clojure’s choice here?
I'm not sure 0 being falsy is ever a good idea, it's just an assembly-ism that became a C-ism and spread from there. Zero is not a "special enough" value in the ring of integers. In general, these days I prefer as few implicit coercions as possible.
In many Lisps, nil is the empty list literal, but interestingly not in Clojure, where it just maps to JVM null, and vectors are the most commonly used data type anyway. However, it is idiomatic for APIs to accept (but not return!) nil as if it were an empty sequence or collection, unlike in most non-Lisp languages.
Re: I am a horse in the land of booleans
#10I’m used to 0 and [] being falsy. Upsides and downsides to Clojure’s choice here?
0 being falsy makes no sense outside of the C family of programming languages. But there 0 is overloaded both as a number and pointer (it's a bit more complicated though, as the value of the null pointer doesn't need to be zero but assigning 0 to a pointer will assign the null pointer). In languages with more elaborate type systems, you usually have the pointer and number representation separated. 0 has no special me…
>But making zero elements evaluate to falsy is problematic. "" would be falsy as well then.
In Python 0, [], and "" are all falsy. In my experience it's only been useful - why do you consider it problematic?