115
The JavaScript type coercion algorithm (lemmy.ml)
submitted 1 year ago by to c/programmerhumor@lemmy.ml
37 comments fedilink hide all child comments
 

top 35 comments

sorted by: hot top controversial new old
[–] 17 points 1 year ago (2 children)

To make it even worse

  • permalink
  • fedilink
  • source
  • hideshow 2 child comments
    •
  • [–] 14 points 1 year ago

    Mh, '0' is a nonempty string, so !'0' returns false. Then of course !(!'0') would return true. I'd absolutely expect this, Python does the same.

    And the second thing is just JavaScript's type coercion shenanigans. In Python

    bool('0') # returns True because of nonempty string
bool(int('0')) # returns False because 0 == False

    Knowing that JavaScript does a lot of implicit type conversions, stuff like that doesn't strike me as very surprising.

  • permalink
  • fedilink
  • source
  • parent
    • [–] 13 points 1 year ago

    Javascript's type coercion is rather insane, yes, but there is an actual, practical reason it's done. JS, having been designed to be run in web browsers, wants to avoid blowing up and crashing at all costs. If it gets an unusual type comparison, usually the result of a bug, it tries to return something, such that the script can continue running if at all possible. In JS' mentality, keeping a page running, even if it might not completely function properly, is preferable to throwing an unhandled exception and completely crashing it.

    Whether or not that is the right approach is debatable, but there is at least some logic to it. Personally, I think that the proliferation of Node letting JS run outside of browsers exacerbates a lot of JS' issues, but TypeScript does a lot to make it look like a more sensible language.

  • permalink
  • fedilink
  • source
    •
    [–] 12 points 1 year ago

  • permalink
  • fedilink
  • source
    •
    [–] 20 points 1 year ago (1 child)

    So JavaScript type coercion is odd, but if you understand it and the WHY, it isn’t that bad.

    Complain about this instead: https://jsdate.wtf/

  • permalink
  • fedilink
  • source
  • hideshow 1 child comment
    •
    • [–] 7 points 1 year ago (2 children)

    This is Haverbeke's book, right? Eloquent JavaScript?

  • permalink
  • fedilink
  • source
  • hideshow 2 child comments
    •
    • [–] 6 points 1 year ago

    This makes it make so much more sense...

    Its not really insanity, just a lot of hidden function calls

  • permalink
  • fedilink
  • source
    •
    [–] 5 points 1 year ago (1 child)

    Hey OP, do you mind checking if your book explains the type coercions that are used with the + operator? I remember it also being mind-boggling, so I was hoping you book could demystify it too.

  • permalink
  • fedilink
  • source
  • hideshow 1 child comment
    •
    load more comments (1 reply)
    [–] 4 points 1 year ago

    I mean, it is the basic concept of truthiness. At least they let you use strict equal.

  • permalink
  • fedilink
  • source
    •
    [–] 4 points 1 year ago

    The description in the first photo about int - steing comparison is incomplete though, right? Wasn't there also a rule anout which one of then comes first (the second parameter gets converted?), and what happens if a string contains non-numeric values?

    It's all so confusing…

  • permalink
  • fedilink
  • source
    •
    [–] 2 points 1 year ago

    why convert boolean to integer instead of converting the other operand to boolean? it doesn't make sense.

  • permalink
  • fedilink
  • source
    •
    [–] 2 points 1 year ago (1 child)

    Is that a tear on the "again"?

  • permalink
  • fedilink
  • source
  • hideshow 1 child comment
    •
    • [–] 2 points 1 year ago (6 children)

    But then why 2 == true if true is converted to 1

  • permalink
  • fedilink
  • source
  • hideshow 6 child comments
    •
  • [–] 8 points 1 year ago (4 children)

    It's not. Just tried in my Browser Console:

    2 == true // returns false
  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] 6 points 1 year ago (3 children)

    I genuinely wasn't aware of that. I must be getting javascript confused for almost any other language. I wonder how many times ive !!'d a value to make that work without actually absorbing that into my head now..

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] 3 points 1 year ago (1 child)

    In other languages that shouldn't be equal either though, right?

    Maybe you meant

    if (2){
console.log("nonzero ints are truthy")
}
else {
console.log("no they're not")
}

    Which would output

    nonzero ints are truthy

    and that would actually work in all languages I know. But that's different from being equal.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
    • [–] 1 point 1 year ago

    Hello from Perl! Looks reasonable to me!

  • permalink
  • fedilink
  • source
    •
    [–] -3 points 1 year ago* (last edited 1 year ago) (9 children)

    Yes, we should all use rigid types. Name me one language you actually like writing quickly with that has types?

    Pyth-oh. Bash-oh. Lisp-oh. Perl-oh. Oh yeah... typed languages suck because of all the boiler

    Edit: Fine, Python / Lisp / Perl are all technically "typed" languages, but I ask you what's point of throwing type errors at runtime. Javascript and Rust actually have it right here that the code is either going to run, or it simply isn't. No pussyfooting letting it run first to throw complaints

  • permalink
  • fedilink
  • source
  • hideshow 9 child comments
    •
  • [–] 5 points 1 year ago (2 children)

    Python. Don't know why you excluded it.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
    • 12 comments in c/programmer_humor@programming.dev view that post
    [–] 29 points 1 year ago (2 children)

    TL;DR do not use ==

  • permalink
  • fedilink
  • source
  • hideshow 2 child comments
    •
    • [–] 16 points 1 year ago (5 children)

    It's so crazy to me that they convert from string to int and not the other way round.

  • permalink
  • fedilink
  • source
  • hideshow 5 child comments
    •
  • [–] 12 points 1 year ago (4 children)

    "1e2" == 100 I guess is the reason? I mean if there were some "reasons" to begin with 😮‍💨

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] 4 points 1 year ago (3 children)

    There surely are strings that can be converted into numbers (even something as simple as "1"). But in general, when languages do implicit conversions, they do it towards the more general type.

    For example, if I do 1.1 == 1 in pretty much any language that has separate float and int types, the integer gets casted into a float (from more specific to more general type) and the comparison returns false. It would be utterly ridiculous if the language auto-casts the float to int and then returns true.

    JS does just that. Instead of casting the more general number into a string and comparing that, it goes the other way round.

    Every number has an equivalent string representation, not every string has an equivalent number representation.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] 2 points 1 year ago (2 children)

    Not quite. As the previous commenter said, every string has at least one string representation (i.e. 100 -> "100", "1e2"). So there's no sensible way to write a pure function handling that, you're just cooked no matter what you do.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 1 point 1 year ago (1 child)

    Other languages handle that easily:

    Implicit cast from number to string, explicit parsing in the other direction.

    For comparisons as number, parse the string to a number and compare two numbers.

    The main point of the implicit cast from number to string is to concattenate number to string, e.g. print("testValue: " + testValue).

    Another option (e.g. taken by Python) is to acknowledge that there's no pure 1:n mapping in any direction between string and number, so any conversion between those two needs to be done explicitly. That's probably the most correct implementation, but it makes string concattenation annoying. But then again, f-strings and similar techniques make that problem pretty much obsolete.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 1 point 1 year ago

    Yeah I mean it's definitely possible to write a mostly sensible string-number equality function that only breaks in edge-cases, but at this point it's all kinda vibes-based mush, and the real question is like... Why would you want to do that? What are you really trying to achieve?

    The most likely case is that it's a novice that doesn't understand what they're doing and the Python setup you describe does a better job at setting up guardrails.

    I don't really see the connection to concatenation, that's kind of its own thing.

  • permalink
  • fedilink
  • source
  • parent
    • [–] 6 points 1 year ago

    if you hate JS and think it's dumb, but still have to use it, look into Eloquent Javascript (free) https://eloquentjavascript.net/ and the mozilla docs https://developer.mozilla.org/en-US/docs/Web/JavaScript.

    Eloquent JS is written by someone who also hates JS, but understands it very well.

    I used them while I worked on the Microtonal Music Grid (still in progress)

  • permalink
  • fedilink
  • source
    •
    [–] 4 points 1 year ago

    Having worked with JavaScript, I understand the usefulness of a "less strict" equality comparison like this, but the coercion of objects still does my head in...

    (And for the record, most of the time I did use strict equality).

  • permalink
  • fedilink
  • source
    •
    [–] 3 points 1 year ago

    Just use ===

  • permalink
  • fedilink
  • source
    •