Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I am a horse in the land of booleans

iloveponies.github.io

Post reply on HN
Print view View original

31–40 of 89 posts

Re: I am a horse in the land of booleans

#31

Post by mikeash »

kazinator wrote: post #16
bhaak wrote: post #8

Earlier quoted context omitted.

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…

outside of the C and assembly languages

Do assembly languages even have a concept of truthy/falsy? The ones I'm familiar with always require an explicit predicate, such as "jump if zero" or "jump if not zero."

Re: I am a horse in the land of booleans

#32

Post by Sharlin »

celticmusic wrote: post #25
Sharlin wrote: post #9

Earlier quoted context omitted.

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. H…

0 is the value integral types get default initialized too, it's the equivalent of default initializing a boolean to false.

But the fact that some types have a reasonable default value doesn’t make the values intrinsically equivalent to Boolean false. Plus, implicit default initialization is itself not necessarily a desirable feature. Especially not the kind that just default initializes to an all-zeroes bit pattern.

Re: I am a horse in the land of booleans

#33

Post by jancsika »

SEMW wrote: post #5
asplake wrote: post #3

I’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 an idiomatic shorthand

Suppose a fantasy language has an ergonomic syntax to check existence. It returns a boolean. Additionally, implicit conversions to boolean for objects in the language is randomized for each runtime.

Isn't such a weirdo language still preferable to implicit conversions, even when compared to a language where "null" and "false" are the only falsey values? Because even in those languages the new user must internalize the simple rule and learn from context how it works and why it can be used with impunity. Whereas with my weirdo language the syntax explicitly conveys to all classes of user what is happening in the code.

Furthermore, I'd bet that even in your preferred languages there are less readable idioms that ninjas can leverage in the implicit conversions. In my weirdo language the randomized conversions would thwart the ninjas and keep the entire class of users free from their unreadable tyranny.

Re: I am a horse in the land of booleans

#34

Post by c3534l »

Sharlin wrote: post #9
asplake wrote: post #3

I’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. H…

It's not just an assemblyism, the near equivalence between 0 and false, and 1 and true is the thing that Boole wrote about for which Boolean values are named. I would argue that it's a math thing, not an assembly thing.

Re: I am a horse in the land of booleans

#35

Post by raverbashing »

mikeash wrote: post #30
raverbashing wrote: post #12

Earlier quoted context omitted.

I disagree with this rationale (not with your specific explanation, with the rationale) You can make your types be interpreted as True/False (in Python at lest) as you want. The issue here is that a date should never be "false". > that's a rule that's really easy to internalise and reason about Python's rule is simple, it's JS that came up with confusing rules. The issue here are types that are inconsistently false (…

"The following values are considered false: * None * False * zero of any numeric type, for example, 0, 0L, 0.0, 0j. * any empty sequence, for example, '', (), []. * any empty mapping, for example, {}. * instances of user-defined classes, if the class defines a __nonzero__() or __len__() method, when that method returns the integer zero or bool value False." This really does not strike me as being simple. I personally…

> I personally don't find these shortcuts to be worthwhile

They are, because they are the difference between driving with the parking brake on or not. Other languages don't have this so that's why people might not see the value in it first.

> Writing `if x != 0` is not a large burden

If you're comparing what can only be an int value, then it's not a burden.

When your variable can assume multiple values, explicitly comparing it with multiple possibilities is a burden:

Examples:

- Your variable is optional and/or is a sequence that might be empty

- You're using .get() in a dictionary

One of the signs someone is unfamiliar with Python is doing multiple comparisons when only `if x:` would suffice

Re: I am a horse in the land of booleans

#36

Post by mikeash »

raverbashing wrote: post #35
mikeash wrote: post #30

Earlier quoted context omitted.

"The following values are considered false: * None * False * zero of any numeric type, for example, 0, 0L, 0.0, 0j. * any empty sequence, for example, '', (), []. * any empty mapping, for example, {}. * instances of user-defined classes, if the class defines a __nonzero__() or __len__() method, when that method returns the integer zero or bool value False." This really does not strike me as being simple. I personally…

> I personally don't find these shortcuts to be worthwhile They are, because they are the difference between driving with the parking brake on or not. Other languages don't have this so that's why people might not see the value in it first. > Writing `if x != 0` is not a large burden If you're comparing what can only be an int value, then it's not a burden. When your variable can assume multiple values, explicitly co…

I've worked in a lot of different languages, from ones that work the way I prefer all the way to Python-style languages where anything is a predicate and there are a bunch of semi-arbitrary rules about what qualifies as "false." This isn't a lack of familiarity talking.

Regarding your examples, having an optional sequence is probably not the correct move anyway. Is there actually a semantic difference between no sequence and an empty sequence? If not, the variable should be non-optional. If so, then glossing over those differences by writing `if x` to implicitly check both conditions is unclear. Not sure what you're referring to with get() in a dictionary.

I understand that good Python style is considered to be one where you take advantage of the language's notion of truthiness, but I disagree with its whole approach.

Re: I am a horse in the land of booleans

#37

Post by taeric »

bb88 wrote: post #29
jarfil wrote: post #15

Earlier quoted context omitted.

The problem lies in what question does it answer: * Does it exist (true) or not (false)? * Does it have a defined value (true) or not (false)? * Is it non-zero (true) or not non-zero (false)? * Does it have non-zero length (true) or not non-zero length (false)? I think using zero as a magic number is less consistent than not using any magic numbers at all. If you want to check the length, or whether something equals…

So here's an example where it matters in python: def f_to_c(deg_f=None): if deg_f: return (deg_f - 32) * 5 / 9 else: raise TypeError('Invalid value passed in') The problem is that it works for all numbers, except 0, because 0 is falsy, and will return a TypeError exception. There are lots of different solutions to this issue, but I wouldn't write the pedantic if statements. I would just do this: def f_to_c(deg_f): re…

Yeah, I don't get it. Your solution is better in near every way. The if statement should be doing a type check, not a value check. And it is redundant since the math will do it.

Right?

Re: I am a horse in the land of booleans

#38

Post by Sharlin »

c3534l wrote: post #34
Sharlin wrote: post #9

Earlier quoted context omitted.

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. H…

It's not just an assemblyism, the near equivalence between 0 and false, and 1 and true is the thing that Boole wrote about for which Boolean values are named. I would argue that it's a math thing, not an assembly thing.

That’s true enough, but in programming languages it’s usually zero=false and any non-zero=true, at least in argument position. That’s more difficult to justify mathematically.

Re: I am a horse in the land of booleans

#39

Post by kazinator »

mikeash wrote: post #31
kazinator wrote: post #16

Earlier quoted context omitted.

outside of the C and assembly languages

Do assembly languages even have a concept of truthy/falsy? The ones I'm familiar with always require an explicit predicate, such as "jump if zero" or "jump if not zero."

But zero could be an integer, or a pointer (such as an empty linked list).

Re: I am a horse in the land of booleans

#40

Post by fhars »

raverbashing wrote: post #35
mikeash wrote: post #30

Earlier quoted context omitted.

"The following values are considered false: * None * False * zero of any numeric type, for example, 0, 0L, 0.0, 0j. * any empty sequence, for example, '', (), []. * any empty mapping, for example, {}. * instances of user-defined classes, if the class defines a __nonzero__() or __len__() method, when that method returns the integer zero or bool value False." This really does not strike me as being simple. I personally…

> I personally don't find these shortcuts to be worthwhile They are, because they are the difference between driving with the parking brake on or not. Other languages don't have this so that's why people might not see the value in it first. > Writing `if x != 0` is not a large burden If you're comparing what can only be an int value, then it's not a burden. When your variable can assume multiple values, explicitly co…

To me it looks more like the difference between driving with a working brake or without.
Post reply on HN