dneaves

After some slight frustration with the "Monadic" (Haskell/Elm) approach to null when learning Elm, I actually fully embrace it now:

unNullString : Maybe String -> String
unNullString nullable = 
    case nullable of
        Just str ->
            str
        Nothing ->
            ""

• A) Now I try to avoid nullables when possible, because handling it everywhere is often more annoying than just expecting the type (even in non-monadic languages like Python)
• B) This is theoretically a better practice anyway. Why have a nullable string when you can just have an empty string? Or a nullable array/list/object/dict/etc when you can just have an empty one? Why have a nullable quantity of items when you can just have 0? If you really, really think you need a nullable bool, you don't: just make a data (Haskell)/type (Elm)/enum (others) at this point. Most other things could just become an data/type/enum as well.

We null things for no reason, too often. Usually laziness.

Essentially, there is a massive pixel-divided canvas. It starts out pure-white.

You are allowed to place one single pixel of a certain subset of colors every x minutes (I don't remember how often, somewhere between 5 minutes to an hour).

Your pixel(s) can be overridden by any other user who places their pixel on your space after you place yours.

Some people come together to form collaborative art, messages, etc. (As seen here).

In the past, there have been countries' flags, a giant spreading black void, hidden Among Us beans, and many fandom-specific and subreddit-specific images.