I literally cannot tell whether you're still being funny or serious. Poe's law is in full effect. (It's still pretty funny to me either way.)
That said, try:
Haskell tries to be a language where all code only does this: Take input, produce output from it; whenever input is the same, output needs to be the same, nothing else may happen, no exceptions whatsoever. Since this forbids things like printing to the screen, reading from a network connections and other useful things, there needed to be a single construct that is excempt from these rules, so Haskell can be useful. Monads are these constructs.
Monads are the house rules you bring to your Monopoly game to make it fun.
(Yes, that means Haskell is not a fully functional language, it's just more functional than most.)
> I literally cannot tell whether you're still being funny or serious. Poe's law is in full effect. (It's still pretty funny to me either way.)
I am dead serious.
> Haskell tries to be a language where all code only does this: Take input, produce output from it; whenever input is the same, output needs to be the same, nothing else may happen, no exceptions whatsoever. Since this forbids things like printing to the screen, reading from a network connections and other useful things, there needed to be a single construct that is excempt from these rules, so Haskell can be useful. Monads are these constructs.
Stop conflating monads with IO. Monads just happen to be usable for modeling IO, but they can model other things as well.
> Monads are the house rules you bring to your Monopoly game to make it fun.
Ironically, when I program in Haskell, I try to keep as much stuff outside of IO as possible. The reason is precisely that IO is usually not fun.
> (Yes, that means Haskell is not a fully functional language, it's just more functional than most.)
No, it just means that IO is a DSL for constructing imperative programs functionally.
===
Anyway, I have no desire for being trolled, so this discussion ends here.
Wow, that was a clever troll, didn't catch on until the end. Would've been better if you hadn't ended it on an obvious declaration of intent though. :)
--
Edit: In retrospect and for later readers i guess i should point out that i forgot one house rule Haskell brings along: Any function can only ever take one single argument. Some monads make it possible to bunch multiple values into one. So the monopoly analogy above is still perfectly accurate.
Taking multiple arguments has nothing to do with Monads. You can either take in a tuple of arguments
f (x,y,z) = x*y + z
or take them in curried form
f x y z = x*y + z
where f 3 is a single argument function that returns another function. This ends up being the same as functions having multiple arguments, in practice.
That said, try:
Haskell tries to be a language where all code only does this: Take input, produce output from it; whenever input is the same, output needs to be the same, nothing else may happen, no exceptions whatsoever. Since this forbids things like printing to the screen, reading from a network connections and other useful things, there needed to be a single construct that is excempt from these rules, so Haskell can be useful. Monads are these constructs.
Monads are the house rules you bring to your Monopoly game to make it fun.
(Yes, that means Haskell is not a fully functional language, it's just more functional than most.)