The idea of Maybe is that you usually don't check for None. The idea is that you use it sort of like a collection in most cases, allowing the None to propagate up as the result of collection operations on other Nones. The issue can be that you get a None at the end and it isn't clear where it came from originally, and how it reached you. Adding stack trace information to each intermediate None, when in debug mode, can help you trace what went wrong.
>The idea is that you use it sort of like a collection in most cases
Sort of like a monad, even!
Honestly if you're running into problems like that though you should probably be using Either instead of Maybe like GP suggested. In my opinion, most of the benefit is still derived from strong static type checking, because otherwise you basically have to trust that callers respect your contract with these types. Perhaps Ruby 3.0 will make this feasible. I'm not sure of the details of the type system they intend to implement; whether it supports ADTs and such.
Yes that's it - they're monads! Either is also a monad, and you can store error information in the other side if you want, but a good thing about Maybe is it could transparently store the error information, and produce it when debugging, rather than baking it into the normal runtime semantics.
> you basically have to trust that callers respect your contract with these types
This is table-stakes for a dynamic language like Ruby, though. Yes people can do anything, but usually they follow the rules they're given.
Yes I’m aware they’re monads, my primary languages are OCaml and Haskell. I don’t understand what you’re suggesting with Maybe, that sounds like maybe adding some layer of magic onto it?
> Yes people can do anything, but usually they follow the rules they're given.
Sure, but the primary advantage remains in not having to trust that, not having to write tests for it, and communicating the contract itself inside the code it restricts. I’m just honestly not sure what purpose they serve here, and why you’d bother to call them monads when what you really seem to want is the stored debugging information.
> I don’t understand what you’re suggesting with Maybe
I’m suggesting adding a trace of where a None value is created and propagated, for debugging purposes.
> the primary advantage remains in not having to trust that, not having to write tests for it
Is that the primary advantage? I’m not as sure as you seem to be.
And of course there’s one huge part of monads that you have to take on trust even in Haskell isn’t there? The monad laws! No type system is enforcing those. If you’re comfortable trusting someone else is following that rule why is trusting they follow another so alien?
But if you don’t like the idea don’t worry I’m not going to come round to your house and force you!