this post was submitted on 26 Jul 2023
5 points (100.0% liked)

Programming

3 readers
1 users here now

This magazine is dedicated to discussions on programming languages, software development, and coding. Whether you are a beginner programmer or an experienced developer, this is the place for you. Here you can share your knowledge, ask questions, and engage in discussions on topics such as coding languages, software engineering, web development, and more. From the latest trends and frameworks to tips and tricks for debugging, this category covers a wide range of topics related to programming.

founded 2 years ago
 

Just because you can use null or undefined doesn’t mean you should. We talk about the problems that come up and how Optionals can help overcome them.

top 1 comments
sorted by: hot top controversial new old
[–] dneaves@lemmy.world 1 points 1 year ago* (last edited 1 year ago)

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.