I think I approximately understand monads, but I find the "wrap the entire external universe" type of explanation to confuse me a bit. It's just the result of one IO computation + a way of handling / unwrapping it!
When trying to map (or bind :) a monad to OOP/imperative programming, it strikes me as more straightforward to think that, e.g., the IO monad is an object that encapsulates the result of a network operation, together with some utility functions for dealing with the result and not having to deal with the unwrapping of the result. Kind of like Futures or Promises.
(Now, here the real FPers will say that the comparison is flawed because of certain FP desiderata like referential transparency, but that's beyond the extent to which I've internalized monads.)
But for many people, they will be used to IO returning nothing, or error values they can ignore. So the case has to be made as to why you need a monad there at all.
(I've just had the slightly disturbing realisation that C++ streams are also monads .. the documentation never uses this term.)
> I've just had the slightly disturbing realisation that C++ streams are also monads
You might like [1].
It's part of Bartosz Milewski's extensive discussion of C++[2], but I'm unsure how that mass can be accessibly approached... maybe by starting around 2011. I very fuzzily recall liking his "Re-discovering Monads in C+" (2014)[3], but I didn't quickly find video. Apparently he gave a "Monads for C++" talk in 2017[4].
When trying to map (or bind :) a monad to OOP/imperative programming, it strikes me as more straightforward to think that, e.g., the IO monad is an object that encapsulates the result of a network operation, together with some utility functions for dealing with the result and not having to deal with the unwrapping of the result. Kind of like Futures or Promises.
(Now, here the real FPers will say that the comparison is flawed because of certain FP desiderata like referential transparency, but that's beyond the extent to which I've internalized monads.)