7 ms·
By the way, in JavaScript: > let a = "0e462097431906509019562988736854"; // = md5("240610708") > let b = "0e830400451993494058024219903391"; // = md5("QNKC
by JW_00000 4y ago
By the way, in JavaScript:
> let a = "0e462097431906509019562988736854"; // = md5("240610708")
> let b = "0e830400451993494058024219903391"; // = md5("QNKCDZO")
> let c = 0;
> a == c
true
> b == c
true
but
> a == b
false
(Of course, also solved by using ===)
- deleted 4y ago[deleted]
- pdpi 4y agoOh that is nasty. For anybody who cares: `a == c` coerces `a` into a number . `a` is a hexadecimal string that happens to have only one non-numeric 'digit', and that digit happens to be an 'e'. This triggers parsing as scientific notation. For both `a` and `b`, the only digit in the significand is 0, so the result is 0.
- hn_throwaway_99 4y agoI think it's a lot less nasty than the Python version. At least the JS version only gives you a weird answer if you're comparing a number to a string, while Python will automatically do a weird type conversion even if you're just comparing two "number looking strings" to begin with. Edit: I'm an idiot, thanks for the responses for correcting me, was thinking PHP but had Python on the brain I guess. Original bad edit: I was downvoted pretty hard, but I think I was just unclear. In Python, doing md5("foo") == md5("bar") returns true because Python converts both strings to numbers first because they have an e in them. That is, in my opinion, Python is doing an unnecessary conversion there that JS doesn't do in that case. See https://stackoverflow.com/questions/12598407/why-does-php-convert-a-string-with-the-letter-e-into-a-number https://stackoverflow.com/questions/12598407/why-does-php-co...
- cochne 4y agoPython doesn’t do any automatic type conversion for strings
- hn_throwaway_99 4y agoThat's false, and that's the point I was trying to make, albeit unclearly - see https://stackoverflow.com/questions/12598407/why-does-php-convert-a-string-with-the-letter-e-into-a-number https://stackoverflow.com/questions/12598407/why-does-php-co...
- andreareina 4y agoThat's about PHP
- blep_ 4y ago... no? Python's == never does implicit type conversions unless one of the types overrides it to do so (neither str nor int does)
- mjw1007 4y agoI think you keep writing "Python" when you intended to write "PHP".
- hn_throwaway_99 4y agoLol, thanks, I'm an idiot, it was the brain fart that kept going.
- matisseverduyn 4y agoRoughly 7 years ago, I started using strict equality comparisons (===) in PHP and JS to avoid issues like this, and doing so has had zero negative impact on my code and obviously a MUCH higher upside. Is there any reason for using sameness (==) merely beyond convenience?
- hombre_fatal 4y agoI can't even remember the last time I worked in a Javascript project where you could find "==" in the codebase. It even got phased out as a convenient "null or undefined" check. Between it being an ancient footgun and the ubiquity of linters, making fun of "==" code ends up just making fun of beginners.
- isleyaardvark 4y agoThank goodness for nullish coalescing.
- eyelidlessness 4y agoI still use it for null/undefined checks, because it’s almost always what’s intended/expected. I was surprised to find out recently that this is even a remotely controversial take. I do try to use the newer language features like nullish-coalescing and optional chaining to make the check less necessary, but sometimes it makes more sense (clearer code, less unnecessary code execution) to check for null/undefined and return early.
- hombre_fatal 4y agoEven with a linter that can approve of that one use case, the problem with == these days is that it catches everyone off guard, and every developer who sees the code has to do the same "did they mean to use this or-- oh, it's for a null|undefined check" every single time. Just because of that I've created an `isNil = (x) => x is undefined or null` function and banished == from my code. == can lead to what we've jokingly called tollbooth code: code that can make every reader stop and pay a mental toll while they confirm that the writer did intend to write the code that way.
- layer8 4y agoIt’s always fun to have an equality operator that isn’t transitive.
- enlyth 4y agoEvery single JS/TS codebase I have ever worked on, == was disallowed by the linter. There is zero reason to use == instead of ===, so while this is a cool quirk, it's hardly a 'gotcha, look how bad javascript is'.
- aflag 4y agoThat's more sensible though. It's just trying to interpret the invention when comparing different types. The fact that == breaks even when the types are the same is much more surprising
- pdpi 4y agoWhen does == break when the types are the same? Can't think of any case.
- matt_kantor 4y agoI'd imagine they are referring to the post we are commenting on (whose context is PHP).
- pdpi 4y agoAh right, forgot the stack overflow post is about PHP.
- deleted 4y ago[deleted]
- jerf 4y agoThis is not a criticism of Javascript; this is history. There has been a lot of work done on Javascript over the decades. But historically, it is a language that was put together in a week in an emergency, last-ditch effort to keep Java from being the language instead. That's literally a week, not a rhetorically-exaggerated week. For a one-week language, it's pretty darned good! But it was still a one-week language. The behavior of the == operator is one of the places where that really shows. I'm sure Brendan Eich would have cleaned that up with more time, but there wasn't any. And the behavior of the == operator is just one of those things that simply can not be fixed for backwards compatibility reasons. That's why an additional one had to be added later that works more sensibly. There's a few other old corners of JS that have survived into the modern era. See also the excitement of hasOwnProperty and all that involves. This was a huge mess for a long time. The work on cleaning it up, against the requirements of backwards compatibility and the uphill battle of having so much of it deployed out in the world, has been exemplary. But there is still some things that just can't have much done about them, == being one of them.
- azangru 4y agoWell, we are still in the "play silly games" territory, aren't we? What should comparing a string to a number equal anyway?
- flir 4y agoIt should throw FileNotFound.
- wizzwizz4 4y agoFor those who missed the reference: https://thedailywtf.com/articles/What_Is_Truth_0x3f_ https://thedailywtf.com/articles/What_Is_Truth_0x3f_
- michaelt 4y agoI'm not sure about comparing strings to numbers. But I know I appreciate it when I can query my database with: SELECT * FROM orders WHERE delivery_day between '2023-04-10' and '2023-04-12' Instead of using SELECT * FROM orders WHERE delivery_day between PARSE_DATE('%Y-%m-%d', '2023-04-10') and PARSE_DATE('%Y-%m-%d', '2023-04-12') So I can see why language designers put in some implicit conversions.
- jmalicki 4y agoThe difference is that it won't turn "abcjhd" into "1970-01-01", but rather issue an error.
- jerf 4y agoI'll cop to having cooled a lot on dynamic languages in general over the past 10 years, but broadly speaking I think it's reasonable to say the decades of experience of the various dynamic languages leans in favor of == being strict in terms of the types of the operands and making it either "false" or an exception. The convenience of comparing a string "124" to the number 124 is outweighed by the near-continuous stream of bugs generated by the languages that will happily yield "true" for that. If I were writing a new dynamic language I'd look to emulate Python's == more than Perl or Javascript here. In general == should not coerce types automatically. Automatic type coercion, even in dynamic languages, is the worst aspect of dynamic typing.