5 ms·

Oh, haven't seen a monad article in quite some time. > Monads really are just a convenient way to build up action values Except when they aren't, because list

Oh, haven't seen a monad article in quite some time. > Monads really are just a convenient way to build up action values Except when they aren't, because lists/arrays (with map) and Maybe (with map) and .. are something totally different. And that's the problem with _all_ these monad tutorials/how-tos/...: the problem is, that monads (and functors) are not burritos or elephants but _both_. So they are hard to understand looking only at a single instance. Btw. monads are not the only way FP deals with effects, see algebraic effects. https://github.com/yallop/effects-bibliography https://github.com/yallop/effects-bibliography https://www.youtube.com/watch?v=DNp3ifNpgPM https://www.youtube.com/watch?v=DNp3ifNpgPM

vmchale 5y ago
A bunch of those mentioned don't address laziness and how the IO monad deals with it: http://blog.vmchale.com/article/effects http://blog.vmchale.com/article/effects
- ReleaseCandidat 5y ago
  Actually the most important part of monads in Haskell is the do-notation. Without that, monadic code would look like JS' callback hell (although composition of monads using monad transformers/monad stacks isn't much better). Haskell without laziness is Purescript, btw.
  - nerdponx 5y ago
    A lot of people I've talked to seem to think Purescript is a better Haskell.
    - shirogane86x 5y ago
      Disclaimer: personal opinion Having used both extensively over the years... I'll have to disagree. Don't get me wrong, purescript is awesome in its own way, but it falls short of haskell in a few major ways. - Lacks ergonomics (for example it has better extensible records, but they are clunky to manipulate due to the lack of features at the type level) - as of now it's tied mostly to the JS ecosystem and runtime(s): that means no TCO, which _really_ hurts when using monads that require on a lot of recursion. And in fact purescript sometimes has to take a performance penalty and use specific trampolined stack-safe monads to avoid stack overflows - Haskell layout rules may be complex, but purescript's break in weird and unintuitive ways (by layout rules I mean the indentation-sensitive syntax) - Haskell is catching up on _a lot_ of the feature that made/make purescript great (mostly talking about syntactic things right now, like RecordDotSyntax, QualifiedDo, BlockArguments...) - as it turns out, when programming "Haskell-style", laziness is really damn effective. So many times I've had to forcefully (and painfully) introduce laziness in purescript to make things behave well... As much as I like purescript, I think if you want that kind of strict programming, maybe OCaML or a derivative thereof (or maybe even ReasonML/Rescript?) would work better? I feel like whenever I use purescript it looks so similar to Haskell that I try doing things the haskell way and it just doesn't work, and the "purescript" way will often look weird to a trained haskeller.
    - ReleaseCandidat 5y ago
      Yes, it does do some things better than Haskell. And row types and row polymorphism are a really nice way of handling records and some type level programming.
  - shirogane86x 5y ago
    I still think that it would look a lot less bad than JS callback hell, mostly because of syntax. actA >>= \a -> actB a >>= \b -> pure doSomethingWith b is a lot better (to my eyes) than: actA(a => actB(a, b => doSomethingWith(b) ) ) and it gets worse from there (blocks to have statements to declare variables, or to call multiple functions. pre ES6 those would've also been functions rather than lambdas. Admittedly monad transformers aren't that great, but that's mostly because of the nxm amount of instances (to avoid explicit lifting).
    - ReleaseCandidat 5y ago
      Yes, that's true, the infix bind and general Haskell syntax helps with the readability of the chained function calls.
gnulinux 5y ago
Monads are algebraic objects that conform to certain axioms. The same way burritos and elephants can end up being groups, rings, Hilbert spaces or whatever under right conditions and right operations, many things can be monad too, under the right operation. The issue with these monad tutorials are in their very premise. They want to explain what monad is without giving its mathematical definition (and its mathematical context) but this inevitably causes significant amount of nuance to be lost.
- nerdponx 5y ago
  A "mathematical object" in this case is a description of how the object is expected to behave. But even so, I think something is lost in reducing monads to a clump of related behaviors and properties. You still need intuition about what these behaviors actually mean and what kinds of real-world objects actually conform to these properties. So you are right that monad "is not" a nondeterministic computation or a container or whatever, but a monad "is" a common set of behaviors/properties that we should expect nondeterministic computations and containers to conform to. Abstraction without intuition is obfuscation!

vmchale 5y ago

A bunch of those mentioned don't address laziness and how the IO monad deals with it: http://blog.vmchale.com/article/effects http://blog.vmchale.com/article/effects

ReleaseCandidat 5y ago
Actually the most important part of monads in Haskell is the do-notation. Without that, monadic code would look like JS' callback hell (although composition of monads using monad transformers/monad stacks isn't much better). Haskell without laziness is Purescript, btw.
- nerdponx 5y ago
  A lot of people I've talked to seem to think Purescript is a better Haskell.
  - shirogane86x 5y ago
    Disclaimer: personal opinion Having used both extensively over the years... I'll have to disagree. Don't get me wrong, purescript is awesome in its own way, but it falls short of haskell in a few major ways. - Lacks ergonomics (for example it has better extensible records, but they are clunky to manipulate due to the lack of features at the type level) - as of now it's tied mostly to the JS ecosystem and runtime(s): that means no TCO, which _really_ hurts when using monads that require on a lot of recursion. And in fact purescript sometimes has to take a performance penalty and use specific trampolined stack-safe monads to avoid stack overflows - Haskell layout rules may be complex, but purescript's break in weird and unintuitive ways (by layout rules I mean the indentation-sensitive syntax) - Haskell is catching up on _a lot_ of the feature that made/make purescript great (mostly talking about syntactic things right now, like RecordDotSyntax, QualifiedDo, BlockArguments...) - as it turns out, when programming "Haskell-style", laziness is really damn effective. So many times I've had to forcefully (and painfully) introduce laziness in purescript to make things behave well... As much as I like purescript, I think if you want that kind of strict programming, maybe OCaML or a derivative thereof (or maybe even ReasonML/Rescript?) would work better? I feel like whenever I use purescript it looks so similar to Haskell that I try doing things the haskell way and it just doesn't work, and the "purescript" way will often look weird to a trained haskeller.
  - ReleaseCandidat 5y ago
    Yes, it does do some things better than Haskell. And row types and row polymorphism are a really nice way of handling records and some type level programming.
- shirogane86x 5y ago
  I still think that it would look a lot less bad than JS callback hell, mostly because of syntax. actA >>= \a -> actB a >>= \b -> pure doSomethingWith b is a lot better (to my eyes) than: actA(a => actB(a, b => doSomethingWith(b) ) ) and it gets worse from there (blocks to have statements to declare variables, or to call multiple functions. pre ES6 those would've also been functions rather than lambdas. Admittedly monad transformers aren't that great, but that's mostly because of the nxm amount of instances (to avoid explicit lifting).
  - ReleaseCandidat 5y ago
    Yes, that's true, the infix bind and general Haskell syntax helps with the readability of the chained function calls.

gnulinux 5y ago

Monads are algebraic objects that conform to certain axioms. The same way burritos and elephants can end up being groups, rings, Hilbert spaces or whatever under right conditions and right operations, many things can be monad too, under the right operation. The issue with these monad tutorials are in their very premise. They want to explain what monad is without giving its mathematical definition (and its mathematical context) but this inevitably causes significant amount of nuance to be lost.

nerdponx 5y ago
A "mathematical object" in this case is a description of how the object is expected to behave. But even so, I think something is lost in reducing monads to a clump of related behaviors and properties. You still need intuition about what these behaviors actually mean and what kinds of real-world objects actually conform to these properties. So you are right that monad "is not" a nondeterministic computation or a container or whatever, but a monad "is" a common set of behaviors/properties that we should expect nondeterministic computations and containers to conform to. Abstraction without intuition is obfuscation!