21–30 of 89 posts
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...
I’m used to 0 and [] being falsy. Upsides and downsides to Clojure’s choice here?
Generally the more special values, that are treated as false, you have in a language - the more complex and confusing your programs become. Just my opinion.
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?
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’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…
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?
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...
I’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 use if (x = 5) * (y = 7) then goto 10 Good to know when you're 11 years old t…
Earlier quoted context omitted.
>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…
def f_to_c(deg_f=None):
if deg_f:
return (deg_f - 32) * 5 / 9
else:
raise TypeError('Invalid value passed in')
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):
return (deg_f - 32) * 5 / 9
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 (…
* 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 don't find these shortcuts to be worthwhile. The best approach is that boolean is a separate type, true is true, false is false, and any attempt to use any other type as the predicate of a control flow statement is a (preferably compile-time) error. Writing `if x != 0` is not a large burden.