• kibiz0r@midwest.socialEnglish
    1141·
    1 year ago

    One of the most frustrating things about null is that it has so many possible meanings:

    • We don’t plan to provide a value here, so use a default instead
    • We plan to provide a value, but memory for this value hasn’t been allocated yet
    • The memory has been allocated, but we haven’t attempted to compute/retrieve the proper value yet
    • We are in the process of computing/retrieving the value
    • There was a code-level problem computing/retrieving the value
    • We successfully got the value, and the value is “the abstract concept of nothingness”
    • or the value is “please use the default”
    • or the value is “please try again”

    And so on. “Null” probably has more different meanings based on context than the word “fuck”.

    • Badland9085@lemm.ee
      21·
      1 year ago

      Many of these meanings seem to be captured in some modern solutions already:

      • We plan to provide a value, but memory for this value hasn’t been allocated yet.
      • The memory has been allocated, but we haven’t attempted to compute/retrieve the proper value yet
      • We are in the process of computing/retrieving the value

      Futures?

      • There was a code-level problem computing/retrieving the value

      Exception? Result monads? (Okay, yea, we try to avoid the m word, but bear with me there)

      • We successfully got the value, and the value is “the abstract concept of nothingness”

      An Option or Maybe monad?

      • or the value is “please use the default”
      • or the value is “please try again”

      An enumeration of return types would seem to solve this problem. I can picture doing this in Rust.

      • david@feddit.uk
        81·
        1 year ago

        Don’t call it a monad, call it a structured data type or something, that’s what it is! Calling it a monad is like saying that you’re using a curve of constant normal intersection point. Why not just say it’s a wheel?

        Yes, it’s mathematically true that you’re having a smooth ride precisely because the normals have a constant intersection point, but it’s also true to say that it’s a wheel and it goes round and isn’t bumpy and doesn’t scrape, and people can get a handle on that.

        So yeah, use a Result or Option or Maybe structured data type because it keeps explicit track of whether there’s a value or not, and yeah, you can change or combine them and preserve the tracking, but there’s no point calling it a monad unless you’re trying to make people believe that avoiding the $1bn mistake of allowing/using null requires category theory. It doesn’t, it’s just a structured data type. It’s simpler than an array! Stop calling it a monad.

        • Spzi@lemm.ee
          3·
          1 year ago

          “Monad” is a shorter term though. “Structured data type” reads almost as bulky as “Curve of constant normal intersection points”.

          • david@feddit.uk
            3·
            1 year ago

            True. But the word Monad has done more harm to the accessibility, popularity and reputation of pure functional programming than pretty much anything else.

            Yeah, I could have said circle rather than curve of constant normal intersection points, but that word is very commonly understood, so it’s not that same as unnecessarily calling something a Monad. Maybe it’s the equivalent of calling it a 2-manifold instead of a wheel.

            Perhaps just ditch the generalisation, then, and just call them Result or Maybe. After all, circle is a short word, but we just call them wheels.

      • Camilo@discuss.tchncs.de
        6·
        1 year ago

        Yeah, for this reason null shouldn’t be part of any production code. If there’s the possibility of having a null value, you need to check every variable or returned value to be safe.

        These monads tell the consumer of your functions to do something (a check for emptiness or wait for it to be ready, or iterate it) to access the value inside. In a safe language, if the value is not wrapped by a monad, then you should expect to access it without issues.

        I kind of get why people don’t want to call them monads, since it sounds like a heavy term and more things to learn that are not strictly “necessary”, but the earlier you learn about their importance, the earlier you can use any of their benefits in your codebase.

    • unalivejoy@lemm.eeEnglish
      9·
      1 year ago

      Null was added to JavaScript because Java had it. Null is unnatural. Undefined is the canon “no value” value.

    • lemmy_see@lemmy.world
      8·
      1 year ago

      “Other alternatives” is a pleonasm, “alternatives” suffices.

      We should make a linter for Lemmy. That’ll shut me up.

      • Phen@lemmy.eco.br
        4·
        1 year ago

        Except you can add the key with an undefined value and it may have different behaviors than if the key was really not there.

          • activ8r@sh.itjust.works
            21·
            1 year ago

            In JS a Boolean has 4 states.
            true
            false
            undefined (where the key is set to undefined)
            undefined (where the key doesn’t exist on the object)

            if (obj.value === true) {  
    console.log(1);
} else if (obj.value === false) {
    console.log(2);
} else if ("value" in obj) { // key "value" is in the obj, but it is set to undefined 
    console.log(3);
} else { // key "value" is not in object
    console.log(4);
}

            You’re welcome.

    • Skyhighatrist@lemmy.ca
      14·
      1 year ago

      That’s not true these days. You can try it yourself right in your browser’s dev console.

      These results are from Firefox’s console.

      0 == null == undefined
> false
0 == null
> false
0 == undefined
> false
null == undefined
> true
null === undefined
> false

      And even in the one case where == says they are the same, you can fix that by making sure you are using === so that it doesn’t do type coercion for the comparison.

              • shrugal@lemm.ee
                2·
                1 year ago

                What’s confusing about that? It’s null, just two different kinds with slightly different meanings. Is having two boolean values also confusing?! Should we simplify it?

                I mean I can get behind trying to remove null entirely and replacing it with better concepts, but I cannot understand why having one more null value suddenly makes it confusing. You don’t even have to care in 95% of the cases, and it can be useful in the other 5%.

                Honestly, it looks more like some kind of misguided purism to me.

    • ryan@the.coolest.zone
      8·
      1 year ago

      Oh man, you’ve got me itching to get into the intricacies of JavaScript…

      One fun example of the difference: when doing arithmetic operations, null is indeed converted to 0, but undefined is converted to NaN. This has to do with null being an assigned value that represents empty, whereas undefined is not actually a value but a response indicating that there was no value assigned in the first place.

      • dan@upvote.au
        7·
        1 year ago

        response indicating that there was no value assigned in the first place.

        You can explicitly assign undefined to a variable though.

        Another fun fact about JavaScript is that undefined never used to be a keyword. If you did var foo = undefined, foo would indeed have a value of undefined, but it was only because there was no variable called undefined in scope!

        You could do var undefined = 42 then var foo = undefined would actually set foo to 42! window.undefined = 42 would break all sorts of things.

        Thankfully this was fixed with ES5 in 2009, although it took a few years for browsers to make the change.

    • Dandroid@dandroid.app
      21·
      1 year ago

      NaN would be something that isn’t toilet paper. So I’m gonna say a picture of a whole rotisserie chicken on the toilet paper bar.

        • Dandroid@dandroid.app
          1·
          1 year ago

          I thought it was established that in the context of this meme and the comment above mine, numbers were represented by toilet paper as an analogy. If that’s not the case, then I don’t get the meme at all.

      • MotoAsh@lemmy.world
        22·
        1 year ago

        It gets funner when it’s a value that actually is a complex number with an “imaginary” component, but gets represented by NaN because the real value doesn’t make sense by itself. In reality, imaginary components are extremely critical for some equations and are totally valid.

        I wish I remembered my math well enough to have one off the top of my head, but I don’t use it often enough… IIRC, it’s even important for magnetics, let alone more complex physics, so it does come up in practice quite often. I think there’s even a fundamental part related to derivatives, but yea, don’t exercise math enough. Might be misremembering.

    • CanadaPlus@lemmy.sdf.org
      3·
      1 year ago

      Infinities: The toilet paper just keeps piling up until it’s out of frame. It probably ends somewhere, but nowhere we can measure.

      Alternately, the toilet paper it tightly wedged in the little hole and no more could be accommodated.

      Subnormals: There’s less than one square left, but there is still toilet paper.

      -0: The glue marks on the empty tube are pointing the other way. This shouldn’t matter, but is apparently enough to confuse some toilet users.

  • lanaa@lemmy.ml
    122·
    1 year ago

    Isn’t the undefined one incorrect? From what I know undefined means it can contain whatever value. So it could be no toilet paper, full toilet paper or anything in-between.

    • stebo02@sopuli.xyz
      241·
      1 year ago

      not undefined in mathematics, an undefined variable is just a variable that hasn’t been defined (yet) and is therefore nonexistent

      • ActuallyRuben@actuallyruben.nl
        3·
        1 year ago

        Depends on what undefinedwe’re talking about. JavaScript undefined is just a value for undefined variables. In C undefined behavior could be anything, ranging from reading in random garbage to time travel or summoning eldritch terrors.

      • palordrolap@kbin.social
        3·
        1 year ago

        There’s deeper subtlety here. There are declared variables, uninitialised variables and variables that will at some point be declared, uninitialised or not, that don’t exist in the logic of the program flow yet. Compilers / interpreters may or may not make distinctions between these, especially if memory is (perhaps only considered to be) in short supply.

        What specific languages do in these cases is wide and varied. Some automatically give all variables a safe, but identifiably undefined value the moment they’re declared, which may or may not be equivalent to the language’s interpretation of null. Or is equivalent in some senses but not others. Looking at you, Javascript.

        In the toilet paper example, the holder might actually still exist but the middle bar might be missing for “identifiably undefined”, and the blank wall is that variable you have literally no idea about.

        Maybe in trying to access it you amaze yourself by finding that you’ve punched through the wall and managed to grab some toilet paper from a neighbouring bathroom cubicle.

        Maybe you instead discover your hand goes through a mincing machine and the pain, oh god why the pain nothing will ever be the same, is that my hard drive churning? No way to tell. Now that’s undefined behaviour.