Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JavaScript: The Curious Case of null >= 0

blog.campvanilla.com

Post reply on HN
Print view View original

91–100 of 152 posts

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

#91

Post by lomnakkus »

laichzeit0 wrote: post #65
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?

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

Indeed it does, and it's horribly error-prone because people don't actually understand it :/. It can also lead to quite convoluted query logic because you're giving up the "law of the excluded middle"[1] (amongst other things).

For my money, the only sane thing to do with e.g. "null >= 0" is to throw an exception. (Even better would be just rejecting it at compile time, but JS obviously doesn't have that luxury.)

[1] https://en.wikipedia.org/wiki/Null_(SQL)#Law_of_the_excluded...

EDIT: Ninja edit: I do understand that NaN has 'reasons', but ideally it'd really want NaN == x to trap rather than just doing 'the weird thing'.

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

#92

Post by ng12 »

lisper wrote: post #90
ng12 wrote: post #86

Earlier quoted context omitted.

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.") }

I'm trying to compare two completely arbitrary variables: the point is there's a dozen different ways where that comparison could involve type coercion. The "third boolean" value is useless unless you completely redesign the language.

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

#93

Post by marcosdumay »

mistercow wrote: post #42
nine_k wrote: post #26

Earlier quoted context omitted.

Aggressive coercion in an attempt to execute clearly faulty code is exactly the problem.

The most common mistake I see when people talk about JS quirks is to assume that this kind of feature is always about fault tolerance rather than convenience. For example, many languages treat conditions as "if nonzero". From a certain perspective, you could argue that if (i--) { is "clearly faulty code". From another perspective, you would say it's a shorthand whose meaning is obvious to anyone familiar with the rul…

Honestly, I like implicit coercion of empty stuff into false. Yes, I do agree it makes the code more legible.

That said, objectively it doesn't gain that much. It may be that the cost of having any kind of implicit coercion is bigger than such gain. Implicit numeric coercion is another topic to think about, it is also hard to be sure if it is a net gain.

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

#94

Post by trollied »

lomnakkus wrote: post #91
laichzeit0 wrote: post #65

Earlier quoted context omitted.

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

Indeed it does, and it's horribly error-prone because people don't actually understand it :/. It can also lead to quite convoluted query logic because you're giving up the "law of the excluded middle"[1] (amongst other things). For my money, the only sane thing to do with e.g. "null >= 0" is to throw an exception. (Even better would be just rejecting it at compile time, but JS obviously doesn't have that luxury.) [1]…

Humans not taking the time to understand SQL properly is their own fault though. Three value logic works perfectly well in the right hands.

JavaScript is horrid :(

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

#96

Post by marcosdumay »

zzalpha wrote: post #6
gruez wrote: post #4

Earlier quoted context omitted.

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

I really wish the industry settled on terms for this stuff but alas... The difference is python is strict about its types and doesn't do automatic coercion. So at least you get type errors at runtime and not magic implicit behaviour. That said, even Perl did this better (less magic and surprises)... JavaScript is like a language intentionally designed to surprise the developer. Half the time I feel like it's a practi…

Using "strict" vs. "non-strict" and "static" vs. "dynamic" will increase a lot the odds of people understanding.

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

#97

Post by ratboy666 »

schindlabua wrote: post #52
microcolonel wrote: post #39

Earlier quoted context omitted.

> 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, I'd trade that for a += record.bool ? 1 : 0; if I can have less awkward type coercions in return in a heartbeat.

Come on! Tongue in cheek

  a += !!record.bool;
There now. Happier?

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

#98

Post by lisper »

ng12 wrote: post #92
lisper wrote: post #90

Earlier quoted context omitted.

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.") }

I'm trying to compare two completely arbitrary variables: the point is there's a dozen different ways where that comparison could involve type coercion. The "third boolean" value is useless unless you completely redesign the language.

> I'm trying to compare two completely arbitrary variables

But WHY are you trying to compare them? The fact that one of these variables is a field called LENGTH is highly suggestive of some particular semantics that you intend these variables to have.

> there's a dozen different ways where that comparison could involve type coercion

That's right, which is the reason I can't answer your question as you posed it.

I predict that if you try to fill in the details what you will find is that you will be unable to do so in any way that does not reveal the presence of something badly wrong in your design.

> The "third boolean" value is useless unless you completely redesign the language.

You have to add an OTHERWISE clause to the IF statement and change the semantics of some operators. That's not a "complete redesign."

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

#99

Post by nitrogen »

lisper wrote: post #98
ng12 wrote: post #92

Earlier quoted context omitted.

I'm trying to compare two completely arbitrary variables: the point is there's a dozen different ways where that comparison could involve type coercion. The "third boolean" value is useless unless you completely redesign the language.

> I'm trying to compare two completely arbitrary variables But WHY are you trying to compare them? The fact that one of these variables is a field called LENGTH is highly suggestive of some particular semantics that you intend these variables to have. > there's a dozen different ways where that comparison could involve type coercion That's right, which is the reason I can't answer your question as you posed it. I pre…

It sounds like OTHERWISE is vaguely analogous to a catch on Java's ClassCastException (assuming it would be thrown for any nonsensical comparison). Traditonal if/else maps IF to true and ELSE to false|undefined; OTHERWISE simply extracts the undefined case to a separate clause.

Interesting way of expressing the result of an ill-defined operation. Or am I off base?

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

#100

Post by colllectorof »

alangpierce wrote: post #10

Not to defend JavaScript too much, but I think the three examples seem reasonable when viewed in the right way, and I think it's hard for JavaScript to do much better with its existing design philosophy (dynamic typing and coercion rather than runtime errors to deal with type mismatches). >= and > are numerical operations, so both sides are interpreted as a number, and null is 0 when treated as a number. That means `…

>I think the three examples seem reasonable when viewed in the right way

These kinds of statements is why I think webdev is completely and thoroughly fucked. When obviously bad software or language design is widely accepted on the basis of convoluted technicalities you know that thing will not get better, only worse.

>This type of issue isn't unique to JavaScript. In Java, if you have boxed Integers

Boxed types in Java were a clusterfuck of their own. They shouldn't be used as justification of bad design in other languages. A cautionary tale, more like.

Post reply on HN