5 ms·

I firmly think languages like Ruby and Clojure get it right, nil and false are falsy, everything else is true, end of story. This is one of my biggest pet-peev

• einhverfr 13y ago
  I like PostgreSQL's SQL dialect. You can't treat non-bools as bools, but you can create casts yourself if you want to. Therefore if I want to cast a varchar as bool, I could decide what I mean by it and build the logic to do this. It would be preferable to do this with a domain though instead of a base type so as to avoid compatibility issues down the road.
• simias 13y ago
  I think that's inherited from C which itself inherits it from various CPU architectures (although I guess nowadays many CPU architectures are tailored for machine code generated by C compilers...). I agree that for higher level languages capable of offering a true "nil" (and not a macro for 0 like NULL in C) it makes sense to make all other values "truthy". I'm not a python coder but it surprises me it doesn't force comparisons explicitly like Java. After all "explicit is better than implicit". That being said, what's the point of having nil and false? Seems a bit redundant to me.
  • leoc 13y ago
    > That being said, what's the point of having nil and false? Seems a bit redundant to me. D: Here's a good reason to begin with: https://en.wikipedia.org/wiki/Open_world_assumption https://en.wikipedia.org/wiki/Open_world_assumption (In case wiki doeesn't make it clear enough, the CWA is squeaking mad in any situation where you cannot, in fact, determine the truth value of every proposition. Just because SQL does it doesn't make it rational.)
  • ufo 13y ago
    C treats 0 as falsy so I would say that its more likely that Pythons behaviour is based on it - the Ruby and Clojure way has more to do with Scheme > That being said, what's the point of having nil and false? Seems a bit redundant to me. In some languages, like Common Lisp, nil and false are the same thing. However, it can be useful to separate the "this is a false value" from "this value does not exist", specially in a dynamically typed language. For example, in Lua you get a "nil" if you access a table field that does not exist and you delete a table field if you store null to it. Before they added a separate boolean type, it was really annoying to work with boolean arrays because storing nil in the array would make it full of holes and would confuse most library functions.
    • sireat 13y ago
      I do not remember C(at least C89) having false at all, so I do not see that Python would base its behaviour on C.
      • ufo 13y ago
        Both C and Python treat the number 0 as falsy if you use it in an if statement. On the other hand, Ruby and Clojure treat 0 as truthy if you pass it in an if statement if(0){ //Ruby and Clojure go here }else{ //C and Python go here }
• AndrewDucker 13y ago
  I firmly think that C# has it right - only booleans are true or false, everything else has to be explicitly compared.
  • ToastyMallows 13y ago
    I agree with this as well. I would rather call a function on an object that returns true/false rather than just use the objects existence as a truth value. In the end I think it makes for more readable code.
  • kabdib 13y ago
    This has saved me some bugs, quite a few times. And the fix is always obvious, and makes sense. Too many languages try to "help" you with features that, in the longer run, turn out to be painful in subtle ways.
• draegtun 13y ago
  Rebol also does this with only none and false (and any its relatives like no & off) being falsy… >> to-logic false == false >> to-logic none == false >> to-logic off == false >> to-logic true == true >> to-logic 0 == true >> to-logic "" == true >> to-logic [] == true Like you I think this is the better way.
• leoc 13y ago
  IMO truthifying and falsifying non-truth-values at all is a Bad Idea: ugly and wrong in principle and mother to a hundred million if-statement bugs in practise. If you really can't stand making explicit comparisons to nil or whatever then employ some kind of syntactic sugaring as necessary.