Monads as a Programming Pattern
11–20 of 84 posts
Re: Monads as a Programming Pattern
#12I get the intention but it's even harder to understand with this Java/C# syntax. I feel like if you're gonna talk about FP you should probably highlight along the Haskell or Scala code (or similar) and provide OOP stuff for reference in case it's not clear. It ends up being so verbose that I don't many people see the 'point'.
Re: Monads as a Programming Pattern
#13I think for newbies there are two separate aspects to explain: first an intro to algebraic structures perhaps using groups as an example, then monads in particular. It’s important to emphasize that algebraic structures are abstractions or “interfaces” that let you reason with a small set of axioms, like proving stuff about all groups and writing functions polymorphic for all monads. With monads in particular I think…
You really don't need to introduce groups or other algebraic structures to understand monads, and if your goal is to teach monads I believe it is harmful to do this.
The average programmer is much more likely to encounter monads (e.g. error handling, promises), than they are to encounter groups in an abstract context. Unnecessary maths will drive people away. Making a big deal of axioms, reasoning, and all this stuff that functional programmers love (including myself) is the approach that has been tried for the last 20 years, and it has failed to reach the mainstream. If you want to reach the average programmer you need to solve problems they care about in a language (both programming and natural) they understand.
Re: Monads as a Programming Pattern
#14I think for newbies there are two separate aspects to explain: first an intro to algebraic structures perhaps using groups as an example, then monads in particular. It’s important to emphasize that algebraic structures are abstractions or “interfaces” that let you reason with a small set of axioms, like proving stuff about all groups and writing functions polymorphic for all monads. With monads in particular I think…
groups as an example Why not go all the way and teach functors and applicatives before monads? Then the student can see that monads are just a small addition built on top of the other two. Functors, in particular, are very easy to grasp despite their intimidating name. They just generalize map over arbitrary data structures: l_double : List Int -> List Int l_double xs = map (* 2) xs f_double : Functor f => f Int -> f…
Functors are not useful for much on their own, so they are difficult to motivate.
The Haskell formulation of applicatives doesn't make much sense outside of languages where currying is idiomatic---which is most languages. In these languages you tend to see the product / semigroupal formulation, and here applicatives become a bit trickier to explain as you need more machinery.
Re: Monads as a Programming Pattern
#15Earlier quoted context omitted.
groups as an example Why not go all the way and teach functors and applicatives before monads? Then the student can see that monads are just a small addition built on top of the other two. Functors, in particular, are very easy to grasp despite their intimidating name. They just generalize map over arbitrary data structures: l_double : List Int -> List Int l_double xs = map (* 2) xs f_double : Functor f => f Int -> f…
Functors are not useful for much on their own, so they are difficult to motivate. The Haskell formulation of applicatives doesn't make much sense outside of languages where currying is idiomatic---which is most languages. In these languages you tend to see the product / semigroupal formulation, and here applicatives become a bit trickier to explain as you need more machinery.
[deleted]
Re: Monads as a Programming Pattern
#16I think it's important to separate the issue of what monads are/how they're used from the question when they should be used at all. While monads are very useful for working with various streams/sequences even in imperative languages, they are used in Haskell for what amounts for effects in pure-FP, and that use ("Primise" in the article) has a much better alternative in imperative languages. Arguably, it has a better alternative even in pure-FP languages (linear types).
Here's a recent talk I gave on the subject: https://youtu.be/r6P0_FDr53Q
Re: Monads as a Programming Pattern
#17This seems pretty good; the only thing on my mental checklist of "common monad discussion failures" is only a half-point off, because I'd suggest for:
"A monad is a type that wraps an object of another type. There is no direct way to get that ‘inside’ object. Instead you ask the monad to act on it for you."
that you want to add some emphasis that the monad interface itself provides no way to reach in and get the innards out, but that does not prevent specific implementations of the monad interface from providing ways of getting the insides. Obviously, Maybe X lets you get the value out if there is one, for instance. This can at least be inferred from the rest of the content in the post, since it uses types that can clearly be extracted from. It is not a requirement of implementing the monad interface on a particular type/class/whatever that there be no way to reach inside and manipulate the contents.
But otherwise pretty good.
(I think this was commonly screwed up in Haskell discussions because the IO monad looms so large, and does have that characteristic where you can never simply extract the inside, give or take unsafe calls. People who end up coming away from these discussions with the impression that the monads literally never let you extract the values come away with the question "What's the use of such a thing then?", to which the correct answer is indeed, yes, that's pretty useless. However, specific implementations always have some way of getting values out, be it via IO in the case of IO, direct querying in the case of List/Maybe/Option/Either, or other fancy things in the fancier implementations like STM. Controlling the extraction is generally how they implement their guarantees, if any, like for IO and STM.)
Re: Monads as a Programming Pattern
#18The problem with monads is they are horrible without some form of syntax sugar. I like the metaphor of "programmable semicolon", but in languages without some built-in support, the "semicolon" becomes repetitive boilerplate which is more code than the actual operations happening in the monad.
Re: Monads as a Programming Pattern
#19This really was excellent. It actually helps with the category theory def.
Re: Monads as a Programming Pattern
#20wow nice post. I can also recommend Mark Seemanns take on monads: https://blog.ploeh.dk/2019/02/04/how-to-get-the-value-out-of...