Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Monads as a Programming Pattern

samgrayson.me

Post reply on HN
Print view View original

21–30 of 84 posts

Re: Monads as a Programming Pattern

#21

Post by mikorym »

I once googled "functional programming for category theorists" and obviously got instead to "category theory for programmers" (incidentally I use Milewski's book in this reverse way).

I still have a rudimentary understanding of functional programming (apart from the canonical "it's just an implementation of lambda calculus"). And I have to say that without exercise and training one grabs at wisps and mist. In mathematics it's also like this, you often have your favorite prototypical monad, adjunction, group, set, etc. (e.g.: The adjunction Set->Set^op by powerset is a strong contender.) And I view axiomatic systems in essence as sort of list of computational rules (e.g.: transitive closure).

I haven't found some idiosyncratic project to code in Haskell yet though...

Re: Monads as a Programming Pattern

#22

Post by coldtea »

chongli wrote: post #9
mbrock wrote: post #6

I 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…

Is this parody?

Re: Monads as a Programming Pattern

#23

Post by keithyjohnson »

tomstuart wrote: post #4
kybernetikos wrote: post #2

I 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.

I watched that talk a while ago and it was great, thank you.

Re: Monads as a Programming Pattern

#24

Post by zug_zug »

I guess I don't get all this "monad" stuff. This article talks about 3 types of monad. An optional, a list, and a future.

However an optional is really just a list constrained to size 0 or 1. And a future is often called "not truly a monad."

So I question the value of explaining this abstraction in great detail over so many articles when people struggle to come up with more than 1 concrete example of it (Lists), an example that engineers have already understood since our first month coding.

Maybe somebody can speak to this more.

Re: Monads as a Programming Pattern

#25

Post by rkido »

zug_zug wrote: post #24

I guess I don't get all this "monad" stuff. This article talks about 3 types of monad. An optional, a list, and a future. However an optional is really just a list constrained to size 0 or 1. And a future is often called "not truly a monad." So I question the value of explaining this abstraction in great detail over so many articles when people struggle to come up with more than 1 concrete example of it (Lists), an e…

> However an optional is really just a list constrained to size 0 or 1.

What?

Re: Monads as a Programming Pattern

#26

Post by Wildgoose »

rkido wrote: post #25
zug_zug wrote: post #24

I guess I don't get all this "monad" stuff. This article talks about 3 types of monad. An optional, a list, and a future. However an optional is really just a list constrained to size 0 or 1. And a future is often called "not truly a monad." So I question the value of explaining this abstraction in great detail over so many articles when people struggle to come up with more than 1 concrete example of it (Lists), an e…

> However an optional is really just a list constrained to size 0 or 1. What?

An empty list (length zero) is "None" and a single element list is "Some" or "Just" whatever the lone element in the list is.

And of course the list is constrained to not contain more than a single entry.

Re: Monads as a Programming Pattern

#27

Post by feanaro »

rkido wrote: post #25
zug_zug wrote: post #24

I guess I don't get all this "monad" stuff. This article talks about 3 types of monad. An optional, a list, and a future. However an optional is really just a list constrained to size 0 or 1. And a future is often called "not truly a monad." So I question the value of explaining this abstraction in great detail over so many articles when people struggle to come up with more than 1 concrete example of it (Lists), an e…

> However an optional is really just a list constrained to size 0 or 1. What?

He means that the type `Optional a` is isomorphic to the type `ListOfLengthAtMostOne a`. This is because we can pair their values up perfectly: Nothing ~ [] and Just a ~ [a].

Re: Monads as a Programming Pattern

#28

Post by feanaro »

kybernetikos wrote: post #2

I 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…

> The category theory language around it is off-putting to working programmers

Off-putting to some working programmers. I am a mathematically-minded working programmer who prefers mathematical and type theoretical explanations quite strongly since they just click for me.

Re: Monads as a Programming Pattern

#29

Post by fxj »

goto11 wrote: post #18

The 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.

I like the "do" notation in Haskell because it boils down the meaning of monads to the following:

Monads let you break the functional programming paradigm that a function should have the same value each time it is called. e.g.

    do {
    x
here getInput is called two times and each time it has a different value. When you now think about how this can happen in a functional language you have to understand what a monad does.

The heureka moment came when I learned about the flatMap in scala which is nothing else but the bind function in haskell ("just flatmap that sXXt") and voila thats how to use monads.

See the following explanation:

https://medium.com/free-code-camp/demystifying-the-monad-in-...

Re: Monads as a Programming Pattern

#30

Post by pjc50 »

I think monads highlight something underappreciated about programming, which is that different people regard very different things as "intuitive". It almost seems that modalities of thinking about programming are bigger, external things than programming itself. Certainly they're barriers to learning.

Like Lisp, there seems to be about 10% of the programmer population who think "ah this is obviously the clearest way to do it" and the remaining 90% who go "huh?", and the 10% are really bad at explaining it in a way the others can grasp.

The two monad explainers that really resonated with me were:

- How do you deal with state in a language that would prefer to be stateless? Answer: wrap the entire external universe and all its messy state up into an object, then pass that down a chain of functions which can return "universe, but with some bytes written to the network" (IO monad)

- If you have a set of objects with the same mutually pluggable connectors on both ends, you can daisy-chain them in any order like extension cables or toy train tracks.

(It's a joke, but people need to recognise why "A monad is just a monoid in the category of endofunctors" is a bad explanation 99% of the time and understand how to produce better explanations)

Post reply on HN