4 ms·

Well, we are still in the "play silly games" territory, aren't we? What should comparing a string to a number equal anyway?

flir 4y ago
It should throw FileNotFound.
- wizzwizz4 4y ago
  For those who missed the reference: https://thedailywtf.com/articles/What_Is_Truth_0x3f_ https://thedailywtf.com/articles/What_Is_Truth_0x3f_
michaelt 4y ago
I'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 ago
  The difference is that it won't turn "abcjhd" into "1970-01-01", but rather issue an error.
jerf 4y ago
I'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.
msla 4y ago
What should 0x40 == 64 equal? Ought hexadecimal integer and decimal integer be the same type? As long as conversion between representations is well-defined and not hugely surprising, what does it matter?
- tialaramex 4y ago
  > As long as conversion between representations is well-defined and not hugely surprising, what does it matter? Surely the MD5 example demonstrates exactly how this ends up being a problem. On the surface "1e5" == 100000 seems like a reasonable conversion between representations and unsurprising, but by silently converting things and then comparing the result we get this astonishing result. Conversions need to be made explicit. This is an opportunity for programmers to consider whether they actually wanted a conversion (the MD5 programmer did not) and for API designers to offer multiple distinct conversions when appropriate. "1e5" == 100000 is only one reasonable interpretation. Maybe it's a lowercase hexadecimal value. If you make the programmer explicitly convert they can choose.
  - giantrobot 4y ago
    > On the surface "1e5" == 100000 Coercing an explicit string e.g. "1e5" to a numeric is boneheaded. It's fine to support different numeric formats like exponent or hex format. Weak typing and type coercion is a major footgun in a language.
    - msla 4y ago
      > Weak typing and type coercion is a major footgun in a language. Type coercion is an expression of strong typing, and it's inevitable if you want a language that's usable. For example, "array of int of length 5" is a type, and "array of int of length 6" is a different type. Do you want to write a separate sort function for each of those types?
      - tialaramex 4y ago
        I don't want to write a separate sort function, the computer can and should do all that work for me automatically. Because Default is tricky to genericise, there literally are 32 distinct implementations provided for Rust's [T; 1] through [T; 32] of Default::default() https://doc.rust-lang.org/src/core/array/mod.rs.html#467 https://doc.rust-lang.org/src/core/array/mod.rs.html#467
Someone 4y ago
> What should comparing a string to a number equal anyway? I think there are two valid options: false and signaling an error (by any means such as returning null, throwing, etc). JavaScript chooses the third (for some strings)
tialaramex 4y ago
The program is semantically incorrect, the compiler or interpreter should complain that you are attempting to ask for equality of a string and a number, and it doesn't know how to answer such a question. Then the programmer can fix the mistake. Here's Rust for example: error[E0277]: can't compare `&str` with `{integer}` [The full diagnostic points to where exactly your code tries to perform such a comparison and explains that you could do this if PartialEq<{integer}> was implemented for &str, which it is not, and then suggests things which are PartialEq for &str, such as other strings and various string-like objects a sane person might compare them to]

flir 4y ago

It should throw FileNotFound.

wizzwizz4 4y ago
For those who missed the reference: https://thedailywtf.com/articles/What_Is_Truth_0x3f_ https://thedailywtf.com/articles/What_Is_Truth_0x3f_

michaelt 4y ago

I'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 ago
The difference is that it won't turn "abcjhd" into "1970-01-01", but rather issue an error.

jerf 4y ago

I'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.

msla 4y ago

What should 0x40 == 64 equal? Ought hexadecimal integer and decimal integer be the same type? As long as conversion between representations is well-defined and not hugely surprising, what does it matter?

tialaramex 4y ago
> As long as conversion between representations is well-defined and not hugely surprising, what does it matter? Surely the MD5 example demonstrates exactly how this ends up being a problem. On the surface "1e5" == 100000 seems like a reasonable conversion between representations and unsurprising, but by silently converting things and then comparing the result we get this astonishing result. Conversions need to be made explicit. This is an opportunity for programmers to consider whether they actually wanted a conversion (the MD5 programmer did not) and for API designers to offer multiple distinct conversions when appropriate. "1e5" == 100000 is only one reasonable interpretation. Maybe it's a lowercase hexadecimal value. If you make the programmer explicitly convert they can choose.
- giantrobot 4y ago
  > On the surface "1e5" == 100000 Coercing an explicit string e.g. "1e5" to a numeric is boneheaded. It's fine to support different numeric formats like exponent or hex format. Weak typing and type coercion is a major footgun in a language.
  - msla 4y ago
    > Weak typing and type coercion is a major footgun in a language. Type coercion is an expression of strong typing, and it's inevitable if you want a language that's usable. For example, "array of int of length 5" is a type, and "array of int of length 6" is a different type. Do you want to write a separate sort function for each of those types?
    - tialaramex 4y ago
      I don't want to write a separate sort function, the computer can and should do all that work for me automatically. Because Default is tricky to genericise, there literally are 32 distinct implementations provided for Rust's [T; 1] through [T; 32] of Default::default() https://doc.rust-lang.org/src/core/array/mod.rs.html#467 https://doc.rust-lang.org/src/core/array/mod.rs.html#467

Someone 4y ago

> What should comparing a string to a number equal anyway? I think there are two valid options: false and signaling an error (by any means such as returning null, throwing, etc). JavaScript chooses the third (for some strings)

tialaramex 4y ago

The program is semantically incorrect, the compiler or interpreter should complain that you are attempting to ask for equality of a string and a number, and it doesn't know how to answer such a question. Then the programmer can fix the mistake. Here's Rust for example: error[E0277]: can't compare `&str` with `{integer}` [The full diagnostic points to where exactly your code tries to perform such a comparison and explains that you could do this if PartialEq<{integer}> was implemented for &str, which it is not, and then suggests things which are PartialEq for &str, such as other strings and various string-like objects a sane person might compare them to]