Comment by da_chicken

Comment by da_chicken 2 days 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 2 days 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.

Reply View 3 replies

da_chicken 2 days 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.

Reply View | 2 replies
- wiseowise a day ago
  
  > 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?
  Because this is how C does it.
  
  Reply View | 1 reply
  
  tialaramex a day ago
  
  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.
  
  Reply View | 0 replies