Comment by wiseowise 2 days ago
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.
> 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.
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.
Certainly "this is how C does it" might be the worst possible rationale for anything in this space. And I like C, got paid a whole lot of money to write C over many years.
But hilariously it's not even true, you see C believes the empty string is also true, it's a string, only the absence of a string would be false in C - whereas Javascript is quite sure the empty string, just like an undefined or null value, is false.
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.
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.