3 ms·

You've completely disregarded type system rules of the language, and continue doubling down on your ignorance with ridiculous examples. > They're not the same

You've completely disregarded type system rules of the language, and continue doubling down on your ignorance with ridiculous examples. > They're not the same kind of thing at all, if you insist that we should be able to compare them then they're not equal, and since programmers are human and make mistakes probably comparing them is itself a mistake. It is literally encoded in the spec. https://262.ecma-international.org/13.0/#sec-toboolean https://262.ecma-international.org/13.0/#sec-toboolean

thfuran 1y ago
But it shouldn’t be
- recursive 1y ago
  So what should be the value of `"false" == true`?
  - bmicraft 1y ago
    undefined or TypeError would be suitable.
    - recursive 1y ago
      So shall we require checking for matching type of first? It doesn't seem like an improvement to me.
      - thfuran 1y ago
        Should a list ever equal seven? Should a float equal a socket? Some comparisons just don't make sense.
        recursive 1y ago
        > Should a list ever equal seven? Should a float equal a socket? No. > Some comparisons just don't make sense. The comparison makes enough sense to me to determine the result.
        bmicraft 1y ago
        Even if the result makes some kind of sense, 99% of the time it will be an error in programming and therefore not be useful or safe to continue.
da_chicken 1y ago
This reasoning is essentially circular. You're saying that the design makes sense because there's a definition, and the definition is what makes it make sense. There is value in having defined behaviors, but those behaviors can't be immune from criticism. That's letting the tail wag the dog. The purpose of a program is not to execute the rules of the programming language. It's to perform a real and useful task. If those real and useful tasks are complicated because synthetic and arbitrary behaviors of the language exist, then the language is wrong. The tool exists to do work. The work does not exist to provide academic examples for the language. And, yes, it's possible for it to be impossible to determine a reasonable behavior, but that still doesn't mean we can't have reasonable behavior whenever possible.
- wiseowise 1y ago
  > The purpose of a program is not to execute the rules of the programming language. It's to perform a real and useful task. If those real and useful tasks are complicated because synthetic and arbitrary behaviors of the language exist, then the language is wrong. The tool exists to do work. The work does not exist to provide academic examples for the language. The tasks are not complicated because of this, it literally is default behavior in mainstream languages. And no, they’re neither synthetic, nor arbitrary limitations. The rule is based on types, not on whatever one specific value might mean. And if they were to define “exceptions”, where do you draw the line? “F41S3” is this? False? No? What if I’m a l33t h4x0r? What about 0xF4153? Looks false enough to me.
  - da_chicken 1y ago
    Again, you are explaining the specifications to defend why the specifications are what they are. That's circular reasoning. Describing the behavior doesn't defend it, and invoking convention doesn't work because different languages have different conventions (which is how we got here). You know what you do when you can't handle an exceptional case? You throw an exception! Emitting errors is not undesirable behavior! It just means the computer says, "I don't know what to do so I better stop." You're never going to design all possible exceptions away, and that's not a flaw. The question you should be asking is: why does it ever make sense to silently compare a character string to anything other than a character string? Semanticly, it's nonsense to compare different types. The only way you can do it is when the other type has a canonical string representation, neverminding issues of culture or language. This is why, for example, C# has String.IsNullOrWhitespace() and String.IsNullOrEmpty(). It's partly to cover common combinations, but also to idiomatically determine if a meaningful value is present, which is what `StringVal == True` and `if (StringVal)` are trying to express and failing at.
const_cast 1y ago
He's not disregarding the type system rules - everyone knows that JS has a "coerce everything" attitude to types. He's saying it's stupid, and I agree. That was a mistake.

thfuran 1y ago

But it shouldn’t be

recursive 1y ago
So what should be the value of `"false" == true`?
- bmicraft 1y ago
  undefined or TypeError would be suitable.
  - recursive 1y ago
    So shall we require checking for matching type of first? It doesn't seem like an improvement to me.
    - thfuran 1y ago
      Should a list ever equal seven? Should a float equal a socket? Some comparisons just don't make sense.
      - recursive 1y ago
        > Should a list ever equal seven? Should a float equal a socket? No. > Some comparisons just don't make sense. The comparison makes enough sense to me to determine the result.
        bmicraft 1y ago
        Even if the result makes some kind of sense, 99% of the time it will be an error in programming and therefore not be useful or safe to continue.

da_chicken 1y ago

This reasoning is essentially circular. You're saying that the design makes sense because there's a definition, and the definition is what makes it make sense. There is value in having defined behaviors, but those behaviors can't be immune from criticism. That's letting the tail wag the dog. The purpose of a program is not to execute the rules of the programming language. It's to perform a real and useful task. If those real and useful tasks are complicated because synthetic and arbitrary behaviors of the language exist, then the language is wrong. The tool exists to do work. The work does not exist to provide academic examples for the language. And, yes, it's possible for it to be impossible to determine a reasonable behavior, but that still doesn't mean we can't have reasonable behavior whenever possible.

wiseowise 1y ago
> The purpose of a program is not to execute the rules of the programming language. It's to perform a real and useful task. If those real and useful tasks are complicated because synthetic and arbitrary behaviors of the language exist, then the language is wrong. The tool exists to do work. The work does not exist to provide academic examples for the language. The tasks are not complicated because of this, it literally is default behavior in mainstream languages. And no, they’re neither synthetic, nor arbitrary limitations. The rule is based on types, not on whatever one specific value might mean. And if they were to define “exceptions”, where do you draw the line? “F41S3” is this? False? No? What if I’m a l33t h4x0r? What about 0xF4153? Looks false enough to me.
- da_chicken 1y ago
  Again, you are explaining the specifications to defend why the specifications are what they are. That's circular reasoning. Describing the behavior doesn't defend it, and invoking convention doesn't work because different languages have different conventions (which is how we got here). You know what you do when you can't handle an exceptional case? You throw an exception! Emitting errors is not undesirable behavior! It just means the computer says, "I don't know what to do so I better stop." You're never going to design all possible exceptions away, and that's not a flaw. The question you should be asking is: why does it ever make sense to silently compare a character string to anything other than a character string? Semanticly, it's nonsense to compare different types. The only way you can do it is when the other type has a canonical string representation, neverminding issues of culture or language. This is why, for example, C# has String.IsNullOrWhitespace() and String.IsNullOrEmpty(). It's partly to cover common combinations, but also to idiomatically determine if a meaningful value is present, which is what `StringVal == True` and `if (StringVal)` are trying to express and failing at.

const_cast 1y ago

He's not disregarding the type system rules - everyone knows that JS has a "coerce everything" attitude to types. He's saying it's stupid, and I agree. That was a mistake.