4
hitko
2y

Sure, languages with automatic conversion to truthy and falsy values can be a pain in the ass, but in languages without that feature you need to use foo != true to see whether foo is either false or null. How fucking ugly is that?

Comments
  • 4
    I'd say the issue isn't in the languages, but in the fact that your boolean type can somehow be "null"

    Boolean values that can be in 3 states (true, false, null) are the most retarded concept ever since I've moved away from C++ to Java....

    implicitly truthy/falsy values are just a patchwork workaround for this dumb multi-state bullshit
  • 0
    @Hazarth The fuck you're talking about? bool* foo; in C++ is exactly the same thing as a nullable boolean in any other language. The only difference is that in C++ it's exposed as a raw pointer, while in memory-safe languages it's wrapped to prevent incorrect memory access.
  • 1
    @hitko Not the same, in C++ you need to be explicit to even end up with a pointer to a boolean. *bool != bool

    It's true that even in Java you have to be dumb enough to use Boolean instead of boolean with small b, but that's clearly a much smaller hoop to jump.

    and in even higher languages like JavaScript you're just fucked, everything is everything anyway
  • 0
    Isn't it ordinary/unremarkable for a value to be unset? User opted in, user opted out, user didn't do either of those things yet?
  • 2
    I think you misunderstood the whole problem.

    Like .... Completely.

    The problem isn't that an obvious boolean value is casted to either null | true | false, the problem is when an non obvious conversion takes place.

    E.g. in PHP / Python / JS an array evaluation to a boolean might make sense as in "not empty"...

    But as soon as we're going to objects or not so obvious conversions, this is becoming a very funny mine field.

    E.g. in PHP an integer - be it negative or positive - is always true. Yes, -1 equals to true. NAN evaluates to true in PHP... And then we have objects who allow a boolean conversion like SimpleXML, while in general a reference to an obj evaluates to true.

    The full mambo jambo looks than like this in PHP:

    https://php.net/manual/en/...

    ...

    I literally know no one. Really no one... Who hasn't in an longer career had one moment with ducktyping / loose typing languages where they were crying because seemingly nothing made sense... Till they found the casting / conversion and things became infuriatingly clear.

    Reason why PHP and Python both are pushing strict variables or at least verifiable typing hints... Cause it really makes no fun at all.

    Now away from duck -/ loosely typed languages: Java has had Optionals since JDK 8 and projects like Valhalla https://openjdk.org/projects/... exist to try and make null "more pleasant".

    JDK 21 is coming this year and Valhalla is getting very close.

    https://infoq.com/news/2023/...

    As a general overview.

    https://cr.openjdk.org/~dlsmith/...

    Heap changes for null restricted values.

    So... Every language adapts. Except JS. JS has typescript which inherited a lot of JS faults, mostly to keep compatibility, as typescript transpiles to JS and isn't an own language per se.
  • 0
    So yeah.

    I love blabla === true (JS / PHP) or Boolean.TRUE.equals(anBooleanObject) (Java) - the java code explicitly handles by the way null, as Boolean.TRUE is an predefined object.

    It makes things just plain obvious.

    Instead of running through an minefield butt naked.
  • 1
    I don‘t find it ugly.
  • 0
    I'm with LensFlare. Have no problem with values in different types being 'truthy' or 'falsey', find it very straightforward to program in PHP - with an occasional bit of care around unset and empty arrays. Using != is actually really useful, for example being able to pre-tick, or not pre-tick, check boxes as defaults ahead of the user making a decision.
  • 0
    Any time you have small inline logic that is hard to read/grok, you should usually pull it out into a function (is_truthy()).

    Then the logic becomes easy to understand, and you can leave comments explaining the nonsense in the definition.

    IMHO you should always strive to make the code readible. That should be the most important metric, because it results in the most time saving.
Add Comment