Live data from Hacker News

I am a horse in the land of booleans

iloveponies.github.io

11–20 of 89 posts

Re: I am a horse in the land of booleans

#11
post #5
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 --…

Here's another prime python example. The response object in the requests library has a truthiness equivalent to request success. Can easily trip you to with `res and res.content`

https://github.com/psf/requests/blob/master/requests/models....

https://stackoverflow.com/questions/48347290/why-does-reques...

Re: I am a horse in the land of booleans

#12
post #5
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 --…

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 (and I disagree with the Python module on that)

Re: I am a horse in the land of booleans

#15
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…

>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?

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 zero, just check for that, not for whether it's "truthy".

Re: I am a horse in the land of booleans

#16
post #8
post #3

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

outside of the C and assembly languages

Re: I am a horse in the land of booleans

#17
post #3

I’m used to 0 and [] being falsy. Upsides and downsides to Clojure’s choice here?

Zero being a present value and truthy makes sense to me--same as Ruby.

[] being truthy is the same as Ruby, but somewhat of a gotcha as an empty vector [] does not have the same truthiness as an empty list '() aka nil.

Re: I am a horse in the land of booleans

#18
post #13

Clojure seems to have replaced the "p"[0] suffix in predicates with "?", the former being an old Lisp convention. Interesting choice, I'm mildly miffed they didn't go with the old convention. [0] http://www.ai.mit.edu/projects/iiip/doc/CommonLISP/HyperSpec...

Question mark is a Scheme tradition. Clojure is a new lisp, drawing inspiration from many sources.

One of Rich Hickey's goals, stated in many ways and in many of his presentations, was to design a modern lisp not bound by design decisions in old ones. That's why Clojure is not built on or directly based on any specific lisp.

He has made a big point about moving on from lisp-isms such as `car` and `cdr`, which are based on tradition and specific archaic hardware implementation, to modern and within-language-consistent things like `first` and `rest`, which are both self-descriptive and implemented for anything that conforms to the seq protocol, as opposed to `car` and `cdr`, which are tied to cons cells.

I do not recall anything specific that he's said about about the choice of a question mark vs a "p", but I can imagine a similar argument that a question mark is more self-descriptive than "p". "p" only makes sense if you know lisp traditions.

Edit: typo

Re: I am a horse in the land of booleans

#19
post #5

Earlier quoted context omitted.

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

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 (…

> Python's rule is simple, it's JS that came up with confusing rules.

I think Perl was there first: in addition to 0 and "" being falsy in Perl, "0" is also falsy. Then there is this nifty Perl value "0 but true": if you stick it into a condition, it will evaluate to true, but if you do math with it, it behaves like the number zero.

Re: I am a horse in the land of booleans

#20
post #13

Clojure seems to have replaced the "p"[0] suffix in predicates with "?", the former being an old Lisp convention. Interesting choice, I'm mildly miffed they didn't go with the old convention. [0] http://www.ai.mit.edu/projects/iiip/doc/CommonLISP/HyperSpec...

[deleted]
Post reply on HN