I'm not a Haskell expert, but I dabbled quite a bit. This is my explanation of what monads are that doesnt rely on math lingo and understanding the maths behind it. I don't fully understand myself but maybe thats actually helpful for trying to explain to someone not familiar with the concept. My understanding relies on concepts used in other programming languages. So depending on how familiar you are with them, this might or might not be helpful for you.

A monad is kind of like a generic class to boxes that adds additional logic to the data it boxes without actually caring about the data itself.

My goto monad for that concept is a linked list and the map operator. So an instance of the linked list might be Node(5) -> Node(7) -> EmptyList. Now let's call map with a function f(x) = str(x) + " * 2 = " + str(2x). This gives us Node("5 2 = 10") -> Node("7 * 2 = 14") -> EmptyList.

Now let's separate the monad from this. The monad is the structure and logic around the data and the function that we provide. The monad doesn't care what data it holds and is doesn't care what function we provide. It only defines the structure and how functions are applied to the data it holds.

▲

rowbin 11 hours ago | parent [-]

Since the monad structure itself carries some inherent information, that is how "side effect" information can be carried outside of the actual data and be part of the monad structure instead. So e.g. the Maybe monad. It either has data or it does not have data. The information whether carries data or not lives outside the data itself. Or the list monad carries information on how many data points it carries and the order of the data points without that being being part of the actual data it holds.

This is how "side effect" information is carried outside the actual information the monad is carrying. Real side effects like writing to disk however are not real monads. The IO monad pretends to be a real monad but it's not. It just helps with hiding the impurity of IO from the pure parts of Haskell.

So one might think about the IO monad kind of like the list monad where the order of the IO operations is encapsulated. It kind of pretends that the IO part is pure and deterministic when its actually not in order to have a somewhat clean separation between pure and non pure parts of the program.

Hope that helps.

	▲	rowbin 10 hours ago \| parent [-]
		So the answer to your questions: 1. Is answered in the parent comment 2. It's not really about solving problems directly. Its more about a common way to hold meta information about your data. But of course that might help you with approaching similar problems. 3. Thats hard. You dont really think about it that way. Again its not really the type of problems directly. Its more about similar approaches to solving different kinds of problems. So you can use monads for solving basically any problem. But you can also choose to not use monads to solve the problem. This is something you'll need to get a feel for. And it shouldn't be for first line of thought. When solving a problem you might recognize that a certain monad lends itself to solving the problem. But it's not really something you actively go looking for.