• Rikudou_Sage@lemmings.world
    link
    fedilink
    English
    arrow-up
    2
    ·
    1 year ago

    Why? IMO that’s perfectly valid. The various type coercions are sometimes crazy, but IMO the rule that non-empty string is coerced to true and empty string to false is very simple to follow. The snippet is not even a gotcha, I don’t see anything worth failing over. Putting “true” or “false” in a string doesn’t change that.

    • noli@programming.dev
      link
      fedilink
      arrow-up
      6
      ·
      edit-2
      1 year ago

      I am dumb. The more things I need to think about when reading code that is not the logic of the code, the worse it is. Any time I have to spend thinking about the peculiarities of the way the language handles something is time wasted.

      I’ll give a very simple example, think like you’re trying to find a bug. Assume we’re in a dynamic language that allows implicit conversion like this. We can write our code very “cleanly” as follows:

      if(!someVar) doSomething();

      -> ok, now we gotta check where someVar’s value is last set to know what type of data this is. Then I need to remember or look up how those specific types are coerced into a bool.

      When trying the same code in a statically typed language that doesn’t do implicit coercion that code will fail to run/compile so probably you’ll have something like this:

      if(someVar.length() == 0) doSomething();

      -> this time I can just look at the type of someVar to see it’s a string and it’s clear what the condition actually means.

      The second option is both easier to read and less bug prone even without the type system. It takes maybe 3 seconds longer to type, but if your productivity in coding is that limited by typing speed then I envy you