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.
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.
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.
Many of these meanings seem to be captured in some modern solutions already:
Futures?
Exception?
Resultmonads? (Okay, yea, we try to avoid the m word, but bear with me there)An
OptionorMaybemonad?An enumeration of return types would seem to solve this problem. I can picture doing this in Rust.
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.
Monad.
"Monad" is a shorter term though. "Structured data type" reads almost as bulky as "Curve of constant normal intersection points".
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.
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.