5 ms·

As a compiler developer I honestly shudder reading this. From the last example: > $ node > "5" + "1" > '51' > "5" - "1" > 4 How is this in anyway reasonab

• Nadya 11y ago
  >'+' is string concatenation but '-' is interpret these strings as numbers and perform arithmetic? That's precisely it. You cannot subtract a string so it coerces "5" and "4" to integers instead of treating them as strings. So it results in 5 - 4. The first concatenates two strings, "5" and "1" and results in "51". It's perfectly reasonable behavior. If you want to add numbers you should give it integers - namely 5 and 1 instead of two strings "5" and "1". The unreasonable behavior is giving integers as strings.
  • casion 11y ago
    The unreasonable behaviour is this not being an error.
  • kyllo 11y ago
    You cannot subtract a string Maybe in Javascript you can't, but you sure could design a language where you could subtract strings, if you wanted to. You could treat the strings as two arrays of characters and subtract them. The result would be the characters that are in the first string but not in the second string. "Hello" - "o" would be "Hell". I'm sure you could do this in Ruby by monkeypatching the string class to overload the minus method.
    • Nadya 11y ago
      How would your method subtract "lo" from "Hello" and leave "Hel" instead of "He"? It gets complicated enough that I think you'd be re-implementing a more limited version of regex. Also I was speaking in context of Javascript so I fail to see how this applies.
      • kyllo 11y ago
        More of a general observation about how arbitrary the type juggling rules and operator overloadings in programming languages are.
    • chias 11y ago
      > The result would be the characters that are in the first string but not in the second string A result would be that, but I certainly would not call it the result. Another result would be to treat the strings as byte arrays and subtract one byte from another, e.g. [a1,a2,a3] - [b1,b2,b3,b4] would result in [a1-b1, a2-b2, a3-b3, -b4]. I'm sure you could do any number of different "correct" operations. And then it's up to you, as a language designer, to decide what you think string-minus-string should actually do... and there is zero probability that everybody in the programming community will agree with your decision.
  • mikeash 11y ago
    It's unreasonable for the programmer to give integers as strings. It's unreasonable for the computer to take integers given as strings and subtract them as integers anyway. The former doesn't preclude the latter.
  • PhasmaFelis 11y ago
    What possibly value is there in coercing strings to integers for _some_ operations but not _all_? I can see rationales for always doing it or never doing it, but this seems like the worst of both worlds.
    • recursive 11y ago
      The rationale is that + is defined for strings, but - is not.
      • PhasmaFelis 11y ago
        That's less a "rationale" and more a "cause," though. If adding quoted integers always treats them as strings, never integers, then allowing coders to subtract quoted integers as integers can only possibly lead to confusion. One or the other should be removed entirely (probably the second, but what do I know).
  • dumael 11y ago
    I'll freely admit I'm not a fan of dynamic languages (mostly due to hacking the Erlang HiPE compiler) and in a previous life I was a Haskell guy. So I'm a fan of strict typing. > The unreasonable behavior is giving integers as strings. That I can agree with. But in that case this notion of reusing '+' as string concatenation but '-' is coercing strings to integers is utterly bizarre. I'm afraid to ask what '*' does (string replication?) and '/' "space magic"?
    • Nadya 11y ago
      I absolutely prefer strict typing myself. The issue becomes whether or not one thinks type coercion should be a thing. I'm personally against type coercion - but I also understand how it functions (and why it functions). I disagree with the "why" but as long as I understand the "how" I can avoid gotchas like string coercion. :) Multiplication ( * ) and division ( / ) coerce to integers. Only + is used for strings, particularly concatenation. Personally I'm a fan of & being used for string concatenation and can't think offhand why not to use it, other than slight possibility of confusion over &&. However I'm not aware of a language that uses it. >>"5" * 5 25 >>"5" * "5" 25 >>"5" / 5 1 >>"5" / "5" 1
      • dumael 11y ago
        > I absolutely prefer strict typing myself. The issue becomes whether or not one thinks type coercion should be a thing. As a strong typing fanatic, I'd rather have the interpreter/compiler scream at me. In my opinion automatic type coercion is slightly less wrong than undefined behavior in C. (Aside, did you know that if GCC spots a statically provable null pointer deference, it will insert __builtin_trap() after the deference? I didn't know either until yesterday. This is acceptable because undefined behavior can mean "eat you hard drive".) If for strings '+' is concatenation, and '*' is for replication with '-' and "/" as exception behavior I can fully understand. (Admittedly '+' over '&' is either style or hard-core "the operation is different, therefore we need a different symbol choice"). Your example worries me. Personally I would not design a language like that. (Though I may have abused it in the past.)
        • 11y ago
  • codarama 11y ago
    >> It's perfectly reasonable behavior. I get what you're saying literally, I strongly disagree that it is reasonable, at all. If you can't subtract them, there should be an error at that point, telling the programmer it can't be done.
• chucksmash 11y ago
  If you haven't seen the Gary Bernhardt "Wat" talk [1], I think you'll very much appreciate the sentiment. https://archive.org/details/wat_destroyallsoftware https://archive.org/details/wat_destroyallsoftware
  • dumael 11y ago
    That video was amazing, thank you.
• tjbrennan 11y ago
  Even better, +"5" will coerce the string to an integer. I'm ashamed to admit that I've abused it.
  • grrowl 11y ago
    To quickly cooerse to a boolean: !!0 === false; !!"zipzap" === true; !!NaN === false To cooerse to a integer (not float): ~~0.5 === 0; ~~"12zipzap" === 0; ~~(Math.PI) === 3; I tend to avoid it for readability (for other developers)
• adrusi 11y ago
  It's quite bad, and that's been pretty universally agreed upon, but back in the 90s we didn't think it would be too bad. It turns out in javascript it isn't actually that bad because you can write out a short list of very unambiguous rules to completely avoid loose-typing issues. And virtually everyone except people who just picked up the language follow these rules religiously. My impression is that in PHP-land it's very hit-or-miss. Some developers adhere to strict guidelines to avoid these kinds of problems and others don't. Perl programmers generally avoid loose-typing when writing libraries and larger programs, but not while writing scripts for personal use, which I think is a pretty reasonable attitude to have.
  • MichaelGG 11y ago
    Eh I don't know if you can blame it on the 90s. I remember using VB and being utterly paranoid because I had no idea what it might end up doing in the name of being helpful.
• e28eta 11y ago
  Our Java backend serializes strings that look like numbers as numbers in JSON. When the ObjC code deserializes, we have properties that might be the NSString we expect, or an NSNumber just because the user entered all digits. I wonder if the Java library was comfortable doing that because of JS's quirks with types. I think it's still bonkers behavior though.