Monads as a Programming Pattern
samgrayson.me
Monads as a Programming Pattern
1–10 of 84 posts
Re: Monads as a Programming Pattern
#2I think the programming pattern paradigm is the right way to explain monads (as you can tell from my own monad explanation: https://kybernetikos.com/2012/07/10/design-pattern-wrapper-w...) The category theory language around it is off-putting to working programmers, and many of the ways people explain it is by trying to introduce yet more terminology rather than just working with the perfectly adequate terminology that working programmers already have.
I think part of it is that lots of languages don't have sufficient abstraction ability to encapsulate the monad pattern in their type system, and those that do tend to be academic focused. That doesn't mean you can't (and do) use monads in the other languages, it's just that you can't describe the whole pattern in their type systems.
I was pretty sad that the discussion around javascript promises sidelined the monad pattern.
Re: Monads as a Programming Pattern
#3This seems a pretty good introduction to monads.
There is a cliche that no-one can write a good introduction to monads. I don't think that is true. My opinion is more that monads were so far from the average programmer's experience they could not grok them. I think as more people experience particular instances of monads (mostly Futures / Promises) the mystique will wear off and eventually they will be a widely known part of the programmer's toolkit. I've seen this happen already with other language constructs such as first-class functions. ("The future is here just not evenly distributed.")
Re: Monads as a Programming Pattern
#4I think the programming pattern paradigm is the right way to explain monads (as you can tell from my own monad explanation: https://kybernetikos.com/2012/07/10/design-pattern-wrapper-w... ) The category theory language around it is off-putting to working programmers, and many of the ways people explain it is by trying to introduce yet more terminology rather than just working with the perfectly adequate terminology t…
In my experience it’s easiest for people to understand monads when they’re presented as an abstract data type (e.g. what I wrote at https://codon.com/refactoring-ruby-with-monads#abstract-data...) rather than a programming pattern, because despite having “abstract” in the name, abstract data types are a relatively concrete thing that programmers already know how to use.
Re: Monads as a Programming Pattern
#5This seems a pretty good introduction to monads. There is a cliche that no-one can write a good introduction to monads. I don't think that is true. My opinion is more that monads were so far from the average programmer's experience they could not grok them. I think as more people experience particular instances of monads (mostly Futures / Promises) the mystique will wear off and eventually they will be a widely known…
I like the comparison with first class functions. I do feel like they are more commonly understood nowadays than when I first started programming ~12ish years ago.
I think because languages like Java are evolving towards a world where those things are common, the average programmer is 'forced' to learn those concepts.
Re: Monads as a Programming Pattern
#6I 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 the pure/map/join presentation is great. First explain taking “a” to “m a” and “a -> b” to “m a -> m b” and then “m (m a)” to “m a”. The examples of IO, Maybe, and [a] are great.
You can also mention how JavaScript promises don’t work as monads because they have an implicit join semantics as a practical compromise.
Re: Monads as a Programming Pattern
#7This seems a pretty good introduction to monads. There is a cliche that no-one can write a good introduction to monads. I don't think that is true. My opinion is more that monads were so far from the average programmer's experience they could not grok them. I think as more people experience particular instances of monads (mostly Futures / Promises) the mystique will wear off and eventually they will be a widely known…
"Introduction to monads" articles generally miss the mark because either 1) they insist on using Haskell syntax throughout, and this is most likely to be unfamiliar and obtuse to programmers looking for this kind of articles. Expecting people to learn a new syntax at the same time as a new concept is bound to be confusing. At least it was for me when I first came across the idea. Or 2) they go through a bunch of examples with various names and number of methods, like Maybe and Collection in this article, and the reader is supposed to infer the common structure themselves. At least this article goes through the formal definition, but I think that ideally that should come first, as it is easier to see the structure of the examples once you have established a mental model.
Re: Monads as a Programming Pattern
#8This seems a pretty good introduction to monads. There is a cliche that no-one can write a good introduction to monads. I don't think that is true. My opinion is more that monads were so far from the average programmer's experience they could not grok them. I think as more people experience particular instances of monads (mostly Futures / Promises) the mystique will wear off and eventually they will be a widely known…
"Introduction to monads" articles generally miss the mark because either 1) they insist on using Haskell syntax throughout, and this is most likely to be unfamiliar and obtuse to programmers looking for this kind of articles. Expecting people to learn a new syntax at the same time as a new concept is bound to be confusing. At least it was for me when I first came across the idea. Or 2) they go through a bunch of exam…
> they insist on using Haskell syntax throughout, and this is most likely to be unfamiliar and obtuse to programmers looking for this kind of articles.
Indeed, that is a big part of a problem.
I find "Functional Programming Jargon" [1] extremely approachable (if you already know modern JS) even though it has been pointed out that their definitions might not be "pure"/correct enough.
[1] https://github.com/hemanth/functional-programming-jargon#mon...
Re: Monads as a Programming Pattern
#9I 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 Int
f_double xs = map (* 2) xs
m_add : Maybe Int -> Maybe Int -> Maybe Int
m_add x y = case x of
Nothing => Nothing
Just x' => case y of
Nothing => Nothing
Just y' => Just (x' + y')
m_add' : Maybe Int -> Maybe Int -> Maybe Int
m_add' x y = [| x + y |]
[1] http://docs.idris-lang.org/en/latest/tutorial/interfaces.htm...
Re: Monads as a Programming Pattern
#10It's hard to explain 20 years ago, but today if someone has used enough something like Reactive extension, Promise, LinQ, async/await, Optional, etc. There's a great chance to make one wonder about the similar pattern behind this, and then he can understand the abstraction very easily.