JavaScript we need to talk 😂😂

It's because null is treated differently by == than to other relational operators. It only coerces null to undefined while other relational operators coerce toPrimative type hinting number so null becomes zero

Essentially they're changing type the where they can. For a greater than comparison for example you always want both flags to be numbers. For == you may wish to check if something is undefined so it won't translate to zero, it'll only change type to number if it's a bool, str or number

@Shardj why such irregular behaviour thiugh? Who the hell thought it would be a good design idea to change the way "null" is interpreted depending on context/operator?

@endor it is logical, if you're doing a greater than comparison for example you want both flags to be typed to numbers. It would otherwise error trying to do that with null

How would you know if something that doesn't exist is less than or greater than a number?

Why do you do a mathematical comparison on something that's not supposed to be a number?

You can't make random ridiculous type comparisons which no programmer would sensibly do irl, using a dynamic typed language, and then complain about the language behaving as it's expected to.

Learn about type coercion. This is not an issue.

@Shardj sorry, but I'm with @inaba on this one. If I wanted 0 I would use 0, not null.
Not only this makes the behaviour of 'null' inconsistent across different operators, but it also potentially introduces subtle yet problematic bugs in the code.

If I'm making a comparison and I (accidentally) throw a non-number into the mix I expect my program to crash, or throw an error of some kind - not try to automatically convert stuff based on an arbitrary set of rules.
Sure you can learn those rules and figure out ways to work with/around them, but it would make much more sense if you didn't *need* to.

(Note: by 'arbitrary' rules I don't necessarily mean random/stupid - it just means that there is no particular reason why that set of rules should be preferred over a different one; eg the reason why 'null' sometime converts to '0' rather than '1' or '7264' or 'NaN' is purely a choice made by whoever designed the language)

@inaba you answered your own question, why would you do a mathematical comparison on something that isn't supposed to be a number? You wouldn't normally, which is why you'll never have problems with this unless you're writing shit code. But there are also functions which may return a numeric or if they fail they'll return undefined. In which case typing it to a number can be benificial. Really they should return false though, so we go back to this only being a problem if you write shit code. But JavaScript enables you to write shitty buggy code if you like as do many languages

@Shardj

> why would you do a mathematical comparison on something that isn't supposed to be a number? You wouldn't normally, which is why you'll never have problems with this unless you're writing shit code.

No, this is where all the horror stories about rewriting tons of hacky legacy code begin.

It should be the other way around: if you're trying to write shit code, the interpreter should stop you and return an error, and NOT try to do type conversions just to keep the program running!

> But there are also functions which may return a numeric or if they fail they'll return undefined. In which case typing it to a number can be benificial.

No! The whole point of returning undefined should be to smack you in the face with an error, to show you that something went wrong. Once again, if you automagically convert that undefined to 0 you're just sweeping under the rug a bug in the code. Good luck debugging an error like that.

> Really they should return false though, so we go back to this only being a problem if you write shit code.

The rules should be there to help you write better code, not to give you ways to circumvent them. If a rule makes implicit assumptions about what it *thinks* I'm trying to do rather than slaping me in the face when I try to do something stupid, I consider it a bad rule.

@hugh-mungus This. These are issues that, if you write good code, you’ll almost never encounter because you’re smart enough to avoid them.

It’s the same with the Automatic Semicolon Insertion debacle. Sure, ASI might put a semicolon in the wrong place, but 1. I can count those cases on the fingers of one hand and 2. Those cases will not appear lest you seek them out - AKA write code like an utter cretin.

@endor this isn't a statically typed language so no it shouldn't do that. If you have type constraints you need to check then you should check them. You can argue that this makes statically typed languages better if you like, and I'd agree to be honest. But for JavaScript bring what it is, it's behaviour perfectly fits into what I'd expect from the language

Don't forget this was appropriately posted under the joke/meme tag. 😭😭😭 ;)

@fredisinbed damn 😂😂

Idk w t f is going on

But its too much fun!! 😝

And BTW it is my first Rant on devRant 🐱

@Santosh62

Summary:
People who don't know what dynamic typing is are bitching about the language doing what it's supposed to do. People who actually know and use dynamic typed languages are correcting them.

Welcome to devrant.

@hashedram

Yep dude,

Thanks 😌😁

Oh this shit again!'

Welcome to devrant dude, plz learn js before

@Jakuho

Dude I'm new to devRant, not JS😂😂😌

@Santosh62 jquery doesn't count :v

@inaba 😂😂

Why? jQuery doesn't comes under JavaScript??

@Santosh62 There are a lot of developers who says they've got experience in Javascript, but in reality all they really know is jquery

@inaba 😂😂

I know vanilla too n infact i use vanilla more than jQuery 😌