1. 25
  1. 8

    What’s described in the article is a particular type of “information loss”. You have valuable information and you throw it away.

    Examples, tutorials, and blog posts should favor Either over Maybe

    Developers should be careful about not overusing Maybe

    … and more generically (and in other languages), not to throw away valuable information. (Empty catch clause is the poster child here.)

    I was thinking about that and posted on my blog: https://ilya-sher.org/2019/05/18/on-information-loss-in-software/

    Parts of “Maybe Considered Harmful” would fit well in the “Information Loss at Runtime” section of my post.

    1. 2

      On Information Loss in Software (My talk at PerlCon 2019, under 25 minutes)

    2. 4

      Another perspective not yet mentioned is that Maybe is the monad whose Kleisli category is like a category whose arrows are partial functions. A partial function is only valid on some portion of its domain, and returns Nothing when run on elements from the invalid portion. Maybe is then the most convenient way to represent and compose such functions.

      A good example of this sort of logic occurring in real-world code comes with NaN semantics when using IEEE 754 or similar numeric representations. When a floating-point routine is given NaN for input, it generally gives NaN for output, as well. Additionally, common operations like taking a square root of a negative number can lead to NaN; the square-root function is partial. Composition of floating-point operations is like composition of partial functions.

      1. 4

        In F# we have the same discussion around optional types. Do you have that integer you’re specifying? You don’t know. Maybe yes, maybe no. So you call it an int option (or a option if you like that style)

        Now you’re 47 functions away and doing something completely different than what you were doing at first. Remember that int? Turns out you actually have to know now. This is completely the wrong time to be working with that concept. You are no longer thinking about the specification, you’re thinking about getting through whatever function you’re in. Your head’s in the wrong spot and your goals are probably not the same as back when you started.

        Instead, as soon as you realize you don’t know, figure out the answer. If it’s not important you don’t need a type at all. If it is important then you need to make some kind of important business decision right now, before you go wandering off doing other things.

        1. 2

          Sometimes an exception is really the right tool to signal an error condition. I tend to lean towards the functional purist side, but I don’t feel bad for encoding errors as exceptions when there’s a small chance of an error but that error has to interrupt the computation.

        2. 2

          This is one thing that annoys me from time to time in Rust. I believe that Rust libraries tend to be better about using Result instead of Option (or in addition to—I see plenty of Result<Option<T>, E>) for errors (partly because ? doesn’t work on Option, at least on stable rust), but it is immensely annoying to try to suss out why library code is giving None for an error.

          1. 1

            If there’s more than one way things may go wrong, I believe it’s even better to use a custom sum type. A lot of time people may and will want to do different things depending on the error. It’s trivial to convert that to either or maybe.

            1. 1

              The article’s been removed and reposted as https://rpeszek.github.io/posts/2021-01-17-maybe-overuse.html, apparently

                1. 8

                  Not really the same thing here: this is about using Either instead of Maybe, Hickey’s talk is about subtyping

                  1. 0

                    I was just referring to criticism of Maybe as a solution to nulls. Starting around 8:30 to 14:00 or so in the Hickey talk.