Comment by tialaramex 2 days ago
For the same reason dogs aren't the square root of two and justice isn't golf? 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.
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.
> 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.
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.
Not at all, "false" shouldn't be false either, the appropriate thing to do when the programmer writes nonsense is to reject what they wrote entirely.
A little bit of truthiness seems like a good idea at first. You decide to treat empty strings and undefined as falsy and it feels good, so you go ahead and start treating zero as falsy too.
And then all of a sudden code that is expecting to get an array or undefined gets handed a zero or an empty string because someone called it with
x && [x]
x.length && x
What does "useful" mean here? Useful the way it'd be useful if butter knives could also cut trees down more easily or if hats were also televisions - ie more uses = more useful?
Programming languages aren't for the machine, they're for humans, and humans make mistakes so we need to design the language with that in mind. "Truthiness" is a footgun, it increases the chance you'll write something you did not mean without even realising.
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