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

61–70 of 152 posts

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

#61

Post by jmull »

I think a lot of you are drawing overly broad conclusions from this, according to your predispositions.

A good language feature should be intuitive, given a basic understanding of the feature, and this falls within that.

A JavaScript programmer considering what the relative order of null and 0 is (and therefore how an inequality operator between them would behave) would intuitively conclude, "I don't know, 0 and null don't have a natural relative order. I probably shouldn't be doing that or else I need to go to the spec."

Anyway, you can hardly judge a language feature as bad because it alllows you to do things that don't make sense (in an edge cases, no less)... then what language features in any language be good?

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

#62

Post by matt2000 »

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.

I agree with everything you said, except for the part where you said JavaScript was "designed".

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

#63

Post by yorwba »

wavefunction wrote: post #45
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…

>> there are number and string values x, y, and z, such that x Again though are numerical operators as poster pointed out so comparing a number to a string using these operators is... 'nonsensical' if that's perhaps the right term. Consider checking if object foo > 1. What would that mean?

That's the point. JavaScript lets you do nonsensical operations that are easily detectable as nonsensical, but instead of throwing an exception, it goes out of its way to prevent you from noticing that anything is off.

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

#64

Post by mirkules »

bga wrote: post #5

Did he seriously claim at the end that that made sense "mathematically"?

I propose we call Javascript a "quantum mechanical programming language" because the value of a variable can never be determined if it is compared to another by observing it directly.

I can just hear it now: "It helps to think of variable conversions in comparisons as a 'cloud' of value probabilities instead of a discrete value"

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

#65

Post by laichzeit0 »

fenomas wrote: post #54
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…

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.

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

#66

Post by zzalpha »

mikebenfield wrote: post #59
alangpierce wrote: post #21

Earlier quoted context omitted.

> I really wish the industry settled on terms for this stuff I've pretty consistently heard "strong typing" to mean that the language avoids coercing between types, and "static typing" to mean that types are known at compile time. So JS and Python are both dynamic typed, but Python is (more) strongly typed and JS is (more) weakly typed. https://stackoverflow.com/questions/2690544/what-is-the-diff...

Yes, I've always understood this to be the correct terminology, but unfortunately in informal discussion among non-academically inclined software people, people use the terms wrong more often than they use them right. You get lots of people saying C is strongly typed (it certainly is not) and something like Scheme is weakly typed (it certainly is not).

If you're really want a fun time, try having a conversation about "duck typing" some time... it was around the time that term became a thing that I realized no one seems to agree on what all these terms mean.

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

#67

Post by alangpierce »

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 system or the "like" counter or some other non-critical feature crashes for a real user, it's a much better UX to degrade that feature rather than taking down the whole page.

I think the "avoid crashing at all costs" mindset was especially sensible when the web was viewed more as a collection of documents, with JS existing to give light optional enhancements rather than drive the core functionality. Imagine opening a Word doc or a PDF and having it crash because the author made a mistake. These days, I would certainly prefer that JS be more strict by default, especially in development.

I think the right way to handle the situation these days should be to define boundaries where a crash in one part of the code is contained to its boundary, e.g. React error boundaries ( https://facebook.github.io/react/blog/2017/07/26/error-handl... ). I also think it's useful to have a variant of "assert" that just logs a warning and continues in production, since in many cases that's the desirable behavior.

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

#68

Post by kbp »

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,…

Python 2 has some strange behaviour of its own with regards to comparing objects of different types, for example:

    >>> None >> '0' > 0
    True
Granted, this follows a much simpler rule than Javascript's comparison operators, and both throw TypeError in Python 3.

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

#69

Post by eropple »

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

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.

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

#70

Post by fenomas »

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 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 terms to begin with, to call such a beast a boolean?

Post reply on HN