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

101–110 of 152 posts

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

#101

Post by lisper »

nitrogen wrote: post #99
lisper wrote: post #98

Earlier quoted context omitted.

> 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?

No, you're exactly right. If you think about it, both of these things are (almost) exactly equivalent. In both cases you are separating out a third control branch. The only difference is the syntax you use to specify what happens on that third branch, and whether or not that branch is taken immediately when the non-true-non-false value is generated. It is exactly the difference between (say)dividing by zero throwing an exception or returning an infinity or a NaN.

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

#102

Post by lomnakkus »

trollied wrote: post #94
lomnakkus wrote: post #91

Earlier quoted context omitted.

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: "their own fault". In one sense, yes, that's true, but this type of reasoning irks me, because you're kind of assuming that the language design is inconsequential -- when it clearly isn't. I could also (somewhat absurdly) also argue that Malbolge[1] is a perfectly reasonable language. After all, if you fully understand Malbolge, it shouldn't be that difficult to write correct programs in it, right?

This is obviously a bit of an Argumentum ad Absurdum, but I think it makes the point pretty well? There are concrete, important differences between languages regarding error-proneness, etc. The reality is that humans are lazy, fallible, etc. and we will make random mistakes, so if we can prevent mistakes (or at least catch them early), then that may be a worthwhile trade-off. Especially for such a trivial case. When was the last time you actually needed "null >= 0" to be true, for example? :)

[1] https://en.wikipedia.org/wiki/Malbolge (pleasantly surprised to see that it has a Wiki entry)

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

#103

Post by rictic »

If you're wondering why JavaScript does this, it's because early versions of the language did not have exceptions. So every operation defined at the time has to return some value for every possible input, even when those inputs don't make any sense.

It's likely that the only way we could get rid of this behavior would be through some `use strict`-like opt-in semantics.

TypeScript helps a lot too: https://www.typescriptlang.org/play/#src=0%20%3E%3D%20null%3...

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

#104

Post by kccqzy »

ratboy666 wrote: post #97
schindlabua wrote: post #52

Earlier quoted context omitted.

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?

This misses the point. !! stills returns a Boolean.

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

#105

Post by curun1r »

eropple wrote: post #69
lisper wrote: post #55

Earlier quoted context omitted.

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

FWIW, for the downvoters: you really should look 'lisper up. I'm not sure I agree with him but the incredulity shown here is unwise.

The down votes are likely for trying to invoke an ad hominem argument. No matter someone's credentials, it's still a logical fallacy and something to be avoided. If he is an authority on the subject, it should show through in his comments. I'm sure he's a very smart and knowledgable person. But there are a lot of smart and knowledgable people here and by invoking his credentials, he's presuming that the people he's talking to are less knowledgable, intelligent or entitled to their opinions. It's insulting and he's earned his downs.

Full disclosure: I downed his 'look me up' post and upped his more substantive posts.

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

#106

Post by kccqzy »

namelost wrote: post #14
infogulch wrote: post #3

Dynamic typing is a nightmare.

It's not so much dynamic typing, but a lack of typing. Dynamic typing means that type checks are made at runtime. e.g. in Ruby: irb> nil >= 0 NoMethodError: undefined method `>=' for nil:NilClass and Python 3: >>> None >= 0 TypeError: '>=' not supported between instances of 'NoneType' and 'int' Obviously JS (and Python 2!) get this wrong, but to be fair JS was designed in the 90s.

Plenty of languages designed before the 90s got this right. It's not like typing is a recent development.

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

#107

Post by eropple »

curun1r wrote: post #105
eropple wrote: post #69

Earlier quoted context omitted.

FWIW, for the downvoters: you really should look 'lisper up. I'm not sure I agree with him but the incredulity shown here is unwise.

The down votes are likely for trying to invoke an ad hominem argument. No matter someone's credentials, it's still a logical fallacy and something to be avoided. If he is an authority on the subject, it should show through in his comments. I'm sure he's a very smart and knowledgable person. But there are a lot of smart and knowledgable people here and by invoking his credentials, he's presuming that the people he's t…

Except 'lisper wasn't making an argument. He was responding to a case of somebody being socially jerkish in a way that was pretty gentle, even for HN's coddling standards. That's important, because downvotes don't fix jerks--only pointing out the behavior does.

Coming in hot with "oh but fallacies, hmm hmm, heaven forfend" when what's being suggested is "maybe don't be a jerk?" is not a great look, don't you think?

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

#108

Post by landryraccoon »

alangpierce wrote: post #67
567arlo wrote: post #57

This being a result of JavaScript's weapons grade weak-typing, I've always wondered of what benefit weak typing actually brings, once dynamic typing is assumed, over strong typing as in python/Ruby. Or at least strong er typing. Reasonable coercion from 11434 -> "11434" is one thing, but why not throw an exception when anything more ambiguous is encountered? It would seem even for an absolute newcomer to programming,…

> I've always wondered of what benefit weak typing actually brings It makes your code crash less, and I would argue that in many cases that's desirable. I think it's a bit sad that the default behavior for computers is often to completely give up on the sight of any error. If you're running code in development or need to worry about data integrity, it makes sense to fail quickly and loudly, but if the analytics syste…

> It makes your code crash less

Wait, can you back this up? What makes you think strongly typed languages crash more than weakly typed languages? What's a scenario where a strongly typed language will crash at runtime, but a weakly typed language won't?

I can see an argument that an interpreter of a weakly typed language will let you run a program with dangerous type conversions without complaining, while a strongly typed language won't even let you execute it - but are you counting that as a crash?

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

#109

Post by [deleted] »

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…

[deleted]

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

#110

Post by catnaroek »

nitrogen wrote: post #99
lisper wrote: post #98

Earlier quoted context omitted.

> 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?

Exceptions are very much well-defined results. They just aren't the result you were originally expecting. But the meaning of a program is defined in terms of the language's own semantics, not what the programmer expects.
Post reply on HN