JavaScript: The Curious Case of null >= 0 • Hacker News Board

Re: JavaScript: The Curious Case of null >= 0

#81

Post by zebraflask » Sat, Sep 09, 2017, 5:23 PM UTC

lisper wrote: post #55

fenomas wrote: post #54

Earlier quoted context omitted.

Are you seriously suggesting that, widgety though JS's implicit type conversions might be, if its booleans had three values then things would be better?

Yes. Why would you doubt it? (i.e. why would you doubt that I'm seriously suggesting it, not why would you doubt that what I am suggesting has merit) (Oh, and BTW, before you completely dismiss the idea that my suggestion might have merit, you might want to look me up. I didn't just fall off the turnip truck.)

I am intrigued by your ideas and would like to subscribe to your newsletter.

Jokes aside, a 3 value Boolean conditional could have some useful applications.

Re: JavaScript: The Curious Case of null >= 0

#82

Post by TheRealPomax » Sat, Sep 09, 2017, 5:37 PM UTC

userbinator wrote: post #38

Dynamic languages with implicit type conversions are designed to make the easy cases easy (think of JS operating on webpage input, where everything is initially a string; would it have the influence and popularity it does today, if lots of explicit conversions had to be written?), but as a side-effect, the hard cases can become perplexing. I have no doubt those steps specified in the standard had plenty of thought pu…

you mean in this blog, or in the spec? (for the spec having the actual step spelled out is pretty much all you need when you're a spec implementation engineer. The flow chart is basically just eye candy for readers)

Re: JavaScript: The Curious Case of null >= 0

#83

Post by TheRealPomax » Sat, Sep 09, 2017, 5:43 PM UTC

gruez wrote: post #4

infogulch wrote: post #3

Dynamic typing is a nightmare.

Done right (like in python), it's not so bad.

the problem is there is no "right" until you define what right means, which is where the spec comes in. These results are "right", if unexpected, and the true issue here is of course not so much the mathematical results between the three tests, but the fact that JS gives you the freedom to compare anything to anything, irrespective of whether that comparison makes sense at all. Python allows this in a few places, too, with equally bizarre results (see another comment that highlights a few of them).

While tempting to do so, thinking of >= as implying "> or ==" is simply not true in any language that performs type coercion to get around type incompatibility issues.

Re: JavaScript: The Curious Case of null >= 0

#84

Post by Tarean » Sat, Sep 09, 2017, 5:50 PM UTC

microcolonel wrote: post #39

deburo wrote: post #36

Earlier quoted context omitted.

But the code using twisted features is hard to maintain afterward. You will have to put comments around them just to be sure the next guy (it might even be the author himself) doesn't waste its time understanding what the hell the code is doing.

> But the code using twisted features is hard to maintain afterward. let a = 0; for (const record of records) a += record.bool; What's so bad about this? (aside from mutable accumulator, but that can be restricted to one scope). The pattern is basically directly lifted from C, where there's thankfully no such thing as a boolean type. If anything, the solution is to fold Boolean and null into Number to begin with. > Y…

To be fair,

    let a = 0;
    for (const record of records) {
        if (record.bool){
          a += 1;
        }
    }

or

    ls.filter(x => x).length;

aren't that much harder to read. The second one probably doesn't do deforestation and would end up stupidly slow, though.

Re: JavaScript: The Curious Case of null >= 0

#85

Post by JoelJacobson » Sat, Sep 09, 2017, 5:56 PM UTC

fenomas wrote: post #71

laichzeit0 wrote: post #65

Earlier quoted context omitted.

Why not? SQL has three valued logic. It's not a novel idea.

I'm aware that SQL has "bit" values that can be 1/0/null, but that's not exactly three valued logic. Does it really have conditional checks that can have three possible outcomes, or something similar?

Yes, a boolean value can be checked for the three possible values, TRUE, FALSE or NULL.

Re: JavaScript: The Curious Case of null >= 0

#86

Post by ng12 » Sat, Sep 09, 2017, 5:59 PM UTC

lisper wrote: post #74

fenomas wrote: post #70

Earlier quoted context omitted.

> I didn't just fall off the turnip truck Don't get me wrong - I don't know who you are but your username is in my mental bucket of "people worth paying attention to" just from past comments. I ask because the idea of a three-valued boolean seems rather more "magical" than whatever sins JS already commits by defining comparisons such that (a<=b || b<=a) can be false, and so on. I mean, isn't it a contradiction in ter…

It doesn't matter what you call it. What matters is that you somehow distinguish between situations that are clearly true or false and situations that are not clearly one or the other. The exact mechanism by which you do this doesn't really matter (and what you call it really doesn't matter). What matters is that you don't discard the potentially valuable information that you just tried to do an operation that doesn'…

Can you provide an example of when this would be useful? For example:

   if (foo.bar.length >= baz.buz) {
      ...
   } otherwise {
      // what am I supposed to do here?
   }

How do I disambiguate if the "broken" type coercion was actually what I wanted? How do I tell what circumstances conspired to make this statement not-clearly-true?

Re: JavaScript: The Curious Case of null >= 0

#87

Post by moefh » Sat, Sep 09, 2017, 6:02 PM UTC

jmfayard wrote: post #78

fenomas wrote: post #54

Earlier quoted context omitted.

Are you seriously suggesting that, widgety though JS's implicit type conversions might be, if its booleans had three values then things would be better?

Booleans having only three values would be an improvement for JavaScript where they actually have four : true, false, null and undefined

This is nonsense. If typeof(x) is 'boolean', then x is either true or false.

Now, if you don't know the type of x and try to use it as boolean without being careful, it might look like it has four values. That comes partly from being dynamically typed and partly from performing coercion instead of throwing errors. So one might argue that Javascript encourages people to write code that's not careful, or that it's very clumsy to write careful code in Javascript, but saying booleans have four values is just nonsense.

Re: JavaScript: The Curious Case of null >= 0

#88

Post by eloff » Sat, Sep 09, 2017, 6:09 PM UTC

lisper wrote: post #44

justinpombrio wrote: post #35

Earlier quoted context omitted.

Let me agree with you but then turn that on its head. You've argued that having `null >= 0` is the best that JS could do while having a coercion-based semantics. And I agree: this confusing behavior may be the best you can possibly do with a coercion-based semantics. And it's not just this example, either. JavaScript is filled with gotchas, and a lot of them have to do with automatic coercion. For example, did you kn…

> having `null >= 0` is the best that JS could do while having a coercion-based semantics. And I agree Well, I disagree. You have to add a third condition for this to be the best you can do, and that is that the boolean type has to be two-valued. But that is not a given. Just as numerical types can include infinities and NaNs, a boolean type could include a third value that is neither true nor false. The IF statement…

That's not a backward-compatible change. Branches that now take either the then or the else branch will take no branch instead. Obviously, that would change the meaning of many programs in ways the author didn't intend by not executing the code in those branches.

Re: JavaScript: The Curious Case of null >= 0

#89

Post by lisper » Sat, Sep 09, 2017, 6:18 PM UTC

eloff wrote: post #88

lisper wrote: post #44

Earlier quoted context omitted.

> having `null >= 0` is the best that JS could do while having a coercion-based semantics. And I agree Well, I disagree. You have to add a third condition for this to be the best you can do, and that is that the boolean type has to be two-valued. But that is not a given. Just as numerical types can include infinities and NaNs, a boolean type could include a third value that is neither true nor false. The IF statement…

That's not a backward-compatible change. Branches that now take either the then or the else branch will take no branch instead. Obviously, that would change the meaning of many programs in ways the author didn't intend by not executing the code in those branches.

Yeah, I should have said it was syntactically backwards compatible. It's obviously not semantically backwards compatible.

Re: JavaScript: The Curious Case of null >= 0

#90

Post by lisper » Sat, Sep 09, 2017, 6:18 PM UTC

ng12 wrote: post #86

lisper wrote: post #74

Earlier quoted context omitted.

It doesn't matter what you call it. What matters is that you somehow distinguish between situations that are clearly true or false and situations that are not clearly one or the other. The exact mechanism by which you do this doesn't really matter (and what you call it really doesn't matter). What matters is that you don't discard the potentially valuable information that you just tried to do an operation that doesn'…

Can you provide an example of when this would be useful? For example: if (foo.bar.length >= baz.buz) { ... } otherwise { // what am I supposed to do here? } How do I disambiguate if the "broken" type coercion was actually what I wanted? How do I tell what circumstances conspired to make this statement not-clearly-true?

You'll have to provide some more details. Why would you want this broken type coercion? What are you actually trying to do here?

But in the absence of this information, my first guess would be:

   if (foo.bar.length >= baz.buz) {
      ...
   } otherwise {
      alert("Something unexpected happened.  Either foo.bar.length or baz.buz is not a number.")
   }