Comment by tialaramex

wiseowise 2 days ago

Why wouldn’t “false” be true? It’s a non-empty string.

Reply View 26 replies

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.

Reply View | 17 replies
- 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.
  https://262.ecma-international.org/13.0/#sec-toboolean
  
  Reply View | 10 replies
  
  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.
  
  Reply View | 4 replies
  
  const_cast 2 days 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.
  
  Reply View | 0 replies
  
  thfuran 2 days ago
  
  But it shouldn’t be
  
  Reply View | 3 replies
- netsharc 2 days ago
  
  Should "falsch", "faux" and "ЛОЖЬ" be understood as false too?
  
  Reply View | 2 replies
  
  tialaramex 2 days ago
  
  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.
  
  Reply View | 1 reply
  
  wiseowise 2 days ago
  
  What a conventional wisdom for 30 year old language that is based on whatever state of the art was at the time.
  They should’ve just deprecated it right away, invent Time Machine, move to the future, grab Rust and make it the scripting language. Duh.
  
  Reply View | 0 replies
- echoangle 2 days ago
  
  You don‘t think being able to check the truthiness of strings is a useful thing?
  
  Reply View | 2 replies
  
  jameshart 2 days ago
  
  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]
  Or
  x.length && x
  And that’s how you end up with a zero showing up on a webpage instead of a list of to-do items when the list is empty.
  
  Reply View | 0 replies
  
  tialaramex 2 days ago
  
  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.
  
  Reply View | 0 replies
ascar 2 days ago

yea that's an odd example to pick. expecting type conversion to add meaning to strings is a programmer problem not a language problem. really comes down to developers not thinking about types and their meaning anymore.
there are plenty of javascript examples that are actually weird though, especiall when javascript DOES apply meaning to strings, e.g. when attempting implicit integer parsing.

Reply View | 2 replies
- 010101010101 2 days ago
  
  It’s the _existence_ of an implicit conversion from string to boolean that the parent is pointing out as a problem, not how it’s implemented. But that’s Jãvascript bb
  
  Reply View | 1 reply
  
  echoangle 2 days ago
  
  Maybe I’m missing the example but can you not check the truthiness of strings in basically any high level language? At least python does it the same way and it’s very useful.
  
  Reply View | 0 replies
camblomquist 2 days ago

edit: I'm mostly wrong here.
Because "0" is false. In a logical world, a non-empty string being truthy is fine even if the value is "false". Javascript isn't logical.

Reply View | 4 replies
- wiseowise 2 days ago
  
``` > if ("0") console.log("true");
true ```
Excuse me?
> In a logical world, a non-empty string being truthy is fine even if the value is "false". Javascript isn't logical.
You must hate our illogical world built on C, because it has the same behavior.

Reply View | 3 replies

jameshart 2 days ago

Appealing to C - the land of undefined behavior - as a paragon of logic seems like a strange authority to reach for.

Reply View | 1 reply

wiseowise 2 days ago

The point is that this is a well-defined (not pun intended) behavior that exists within C, C++, Python, Ruby and probably a handful more popular languages. This set pretty much constitutes like 70%(?) of mainstream languages. Yet only JS gets shit thrown its way in this thread.

Reply View | 0 replies

camblomquist 2 days ago

I did a `"0" == false` which returned true. I may need another cup of coffee before making claims.

Reply View | 0 replies

bapak 2 days ago

Are you crazy? Which language does? I can only think of markup languages that do.

Should "0" also === 0? How about "{}" === {}? When does it stop?

Reply View 0 replies

nailer 2 days ago

What do you mean? false isn’t true in JavaScript.

Reply View 6 replies

Filligree 2 days ago

“false”, not false. So there’s odd type coercion, but the problem is that it can happen without you asking for it.
Python does the same thing. I don’t like it there either, but at least it’s more consistent about it.

Reply View | 4 replies
- [removed] 2 days ago
  
  [deleted]
  
  Reply View | 0 replies
- nailer 2 days ago
  
  Yes strings aren’t false unless they’re empty. Good thing.
  
  Reply View | 2 replies
  
  macintux 2 days ago
  
  Or, judging by other comments, “0”.
  
  Reply View | 0 replies
  
  [removed] 2 days ago
  
  [deleted]
  
  Reply View | 0 replies
astura 2 days ago

The string with the value of "false" evaluates to true.
In other words
If ("false") { /* You will be here */ }

Reply View | 0 replies