10 ms·

As much as I am anally pained by the following things in JS: 1 + "2" = "12" but "1" - 1 = 0 0 == false ( "if window.scrollTop ..." will occasionally break on

• marchelzo 12y ago
  What do you mean by "native operators like ? and if uses == and not ==="?
  • osconfused 12y ago
    I believe ffn is referring to the ternary operators [1] not using identity operator, but rather the equality operator. [1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Conditional_Operator https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... [2] http://stackoverflow.com/questions/359494/does-it-matter-which-equals-operator-vs-i-use-in-javascript-comparisons http://stackoverflow.com/questions/359494/does-it-matter-whi...
• timepiece 12y ago
  "1" - 1 = 0 Seriously, what answer were you expecting other than this? I'm really curious!
  • rpcope1 12y ago
    48 might have been a much more reasonably sane answer, or just disallow operations that don't really make any sense, instead of implicitly casting in non-obvious ways.
    • timepiece 12y ago
      48? Why's that? How did you reach this conclusion?
      • haberman 12y ago
        "1" is 49 is ASCII.
      • rpcope1 12y ago
        When you see a character, it usually has an underlying representation an unsigned (or byte or array of bytes or int if that's your thing, with size depending on ASCII, Unicode, etc). In both UTF-8 and ASCII the character "1" has a value of decimal 49. If the language actually allows you to subtract a number from a character (or length-one string, depending on language semantics), which is dubious to allow anyways, the expected behavior should be to return 48, but that's really a code smell to even attempt that operation. EDIT: Clarified last statement.
        • pcthrowaway 12y ago
          String.prototype.charCodeAt and String.fromCharCode are never called in implicit type conversion. Type conversion is always done by calling primitive constructor functions. In the case of subtraction ("1" - 1), Number is called on any non-numeric operand. Also see: > false - 1 > true - 1
          • rpcope1 12y ago
            If you have any experience in most other programming languages this would seem to violate principle of least astonishment (see "wat").
        • timepiece 12y ago
          Why do you think that '1'.charCodeAt() and then subtracting 1 is more appropriate and logical than Number('1') and then subtracting 1? Please note that the subtraction operator is not defined for strings in js and the language is loosely typed.
  • Shoop 12y ago
    Type Error
    • timepiece 12y ago
      Don't you know already that js is a dynamically typed language?
      • Dewie 12y ago
        "Dynamically typed" doesn't mean "refuses to give any type errors, ever".
      • rpcope1 12y ago
        Python is also dynamically typed, but it does something sane: >> "1" - 1 Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: unsupported operand type(s) for -: 'str' and 'int'
      • seba_dos1 12y ago
        You're confusing dynamic/static typing with weak/strong typing. JavaScript typing is dynamic and weak, while Python's is dynamic and strong.
        • timepiece 12y ago
          No I'm confusing dynamically typed langs with loosely typed ones. Thanks for bringing this to my attention :)
  • Strilanc 12y ago
    Justifiable and terrible answers: - "" (the 1 gets converted to a string, and string-string could have meant remove-if-tail) - NaN or undefined (bad operations could give bad results) - "1" (bad operations could be ignored) - "1-1" (because life is hilarious, and a-b = a+(-b)) - Parse failure (the -1 could get parsed as a constant because there's no string minus int operation, and two adjacent constants is invalid) - throws (bad operations could act like 'undefined()' does)
    • MichaelGG 12y ago
      What's terrible about throwing in such a case? Edit: Apart from the terrible behaviors of browsers to just silently ignore all errors.
      • Strilanc 12y ago
        Some of them are justifiable, some are terrible, and some are both. That's one of the justifiable ones.
    • timepiece 12y ago
      I really like this "1-1" answer. That's very creative :) But honestly, compare each one of these answers to js's official workaround calling the Number() constructor on the primitive string value and attempting to convert to a number since the subtraction operator is only defined for number and then proceeding to complete the operation. For me, it looks very logical and convincing given that the language is loosely typed and it breaks her heart that it fails any of its loved users :)
  • michaelmartin 12y ago
    It's the inconsistency. 1 + "2" (12) does a string concatenation. 1 - "2" (-1) does math. That said, whilst JS is loosely typed and won't fall over when you do this, I'd just see it as bad form to find code mixing types to this extent. Just because the language will let you do it, doesn't mean you should actually do it!
    • timepiece 12y ago
      I always hear this complaint from classical inheritance people, are you a C/Java supremacist?
      • Retra 12y ago
        Have you heard of this language called "Mathematics?"
    • TazeTSchnitzel 12y ago
      To be fair, the + issue is a mistake many other languages have made too. Incredibly, PHP, poster child of bad languages, gets this right and splits + and . (though this may just be because it copied Perl).
      • Nitramp 12y ago
        It's fine to have a (string) + (string) operator, it's just generally a less than brilliant idea to have a (string) + (arbitrary) operator that does an implicit string conversion. But all of that's fine compared to PHP's implicit number conversion that ignores trailing characters, presumably so that you can add "3 onions" to "1 kg of bacon" or some such...
        • TazeTSchnitzel 12y ago
          (string) + (string) isn't fine either, if only for performance reasons and because an operator should just do one thing.
  • pwang 12y ago
    Any decent language that wants devs to be able to reason about operators and types would throw a TypeError here. Shitty languages will cause devs to have to purchase books entitled "ShittyLanguage: The Non-Shitty Parts", wherein chapter 8 talks about "avoid using the subtraction operator because of ambiguous precedence, transitivity, and coercion rules; instead use jQuery.minus()."
    • timepiece 12y ago
      We caught another Java supremacist here :)
    • tracker1 12y ago
      Easy.. don't let shitty programmers write code.. oh, that's right, everyone has to learn/start somewhere. I've seen some pretty horrible code, with any number of bugs in pretty much every language I've ever seen. If you're passing a string into a function that expects a number, you deserve what you get. parseInt(value,10) for user input isn't so hard.. if you want to ensure a numeric value, you can always ~~value ... though that's slightly less obvious to someone new to the language. JS evaluation expressions are far nicer than most languages I've worked with.. aside from C#'s addition of .? I can't think of much that comes close to as fluid in terms of handling end user input and massaging it into something that works correctly. Your comments remind me of the XML everywhere mindset that used to be so prevalent in "enterprise" programming... JSON is a much better abstraction for data models, as it is less disconnect from actual code. Personally, I prefer a "don't cause an error unless you really have to" approach to development... if you can recover from an error condition, log it and do so... if you can't, blow up the world. Java's error handling comes to mind here as particularly cumbersome to deal with... Node's typical callback pattern, and similarly promises/thenables is much easier to work with in practice. JS has some really hideous parts... just the same, the Browser is an environment where you expect things to do "something" and mostly still work when parts break... the services that back browsers should likely do the same. JS is a good fit for this use case.
  • Klockan 12y ago
    function f(a,b){ return a+b-b } Now tell me, what is f("1",2)? Is this really what you would expect? Treating strings like strings sometimes and integers other times messes up functions, creating bugs that are extremely hard to track. Usually you can get back what you started with if you subtract after you add, but JavaScript ruins that unless you first check that the input are numbers. If it always tried to coerce the string into an integer or vice versa then it would be fine.
    • timepiece 12y ago
      I know that at face value, things look messy and unpredictable but if you really know js in and out, you'd guess the right answer (1) (Check operator precedence and associativity for reference) The problem with people coming from more classical programming languages to learn js is that some have this condescending attitude toward the language from the get go and expect that by the virtue of having C/Java experience under the belt, that everything should look similar in js and when they encounter something like "automatic type casting" they freak out and start dissing the language but once they seriously put the effort to understand it, their frustration and bad experience starts to give away to a more positive experience and consequently more positive sentiment toward the language. So for me it's just a question of attitude and story of prejudice and perceived supremacy of one's own language background at play here.
      • Klockan 12y ago
        It isn't hard to see the answer, but that wasn't my point. The point is that you want predictable behavior from your functions. If you saw the output of said function for integers you could never have guessed the output of said function with the combination of a string and an integer. JavaScript forces you to work more to get predictable type conversions by having a lot of random conversions. While each of those conversions might make sense the combination of them usually doesn't. Why can I use other maths operators to coerce the string into a number but not '+'? Because '+' is a special case since it tries to coerce to a string before it tries to coerce to an integer, it isn't hard to get that. But it makes the other conversions dangerous since when you want to use '*', '-' or '/' you usually want to use '+' as well but as it is the other works but not '+'. What would make sense is to either remove the special case of '+' or you add special cases for the other operators so that they act similarly as '+' with strings.
• deleted 12y ago
  [deleted]