C9 Lectures: Greg Meredith  Monadic Design Patterns for the Web  Introduction to Monads
Description
Greg Meredith, a mathematician and computer scientist, has graciously agreed to do a C9 lecture series covering monadic design principles applied to web development. You've met Greg before in a Whiteboard jam session with Brian Beckman. The fundamental concept is here is the monad.
Greg has a very novel and conceptually simplified explanation of what a monad is and why it really matters. This is very important and a required first step in this series since this is all about the application of monadic composition to real world web development. What does this mean? Why does it matter?
Tune in.
Let's see if Greg's monadic analogies prove helpful for everyday developers in getting their heads around the elusive and beautifully complex monad.
Shape. Wrap. Roll.
See part 2
Share
Download
Download this episode
 High Quality WMV (0.0 B)
 MP3 (0.0 B)
 Low Quality MP4 (0.0 B)
 Mid Quality WMV (0.0 B)
More episodes in this series
C9 Lectures: Greg Meredith  Monadic Design Patterns for the Web 3 of n
Related episodes
C9 Lectures: Greg Meredith  Monadic Design Patterns for the Web 4 of 4
C9 Lectures: Greg Meredith  Monadic Design Patterns for the Web  2 of n
C9 Lectures: Greg Meredith  Monadic Design Patterns for the Web 3 of n
YOW! 2011: Tony Morris  Functional Programming and Functional Thinking
C9 Lectures: Dr. Ralf Lämmel  The Quick Essence of Functional Programming
C9 Lectures: Dr. Ralf Lämmel  Going Bananas
Brian Beckman: The Zen of Stateless State  The State Monad  Part 2
Brian Beckman: The Zen of Stateless State  The State Monad  Part 1
Brian Beckman: Don't fear the Monad
Tomas Petricek: How F# Learned to Stop Worrying and Love the Data
The Discussion

This is going to be good! Downloading now ...
Thanks to Greg and Charles for what will surely be another great lecture series.

Great! Greg, I visited your website ( biosimilarity.com ) a few days ago and I read you organise workshops onMonadic Design Patterns for the Web. I wanted to write you an email and ask if you have any video about this for the ones who can't attend your workshops... and now we have it!

Superb! I love the names (I guess Shape is Mr. T (or M<T>; does that pronounce "emtee"?), wrap is return and roll is bind, aka SelectMany and map is Select). Looking forward to seeing where this is going.
I'm having flashbacks to Brian's clock monoid
The designbycontract mention is also very interesting.
So far my understanding is that...
methodology Shape = t aka Mr. T wrap = w aka return roll = r aka bind aka SelectMany identity = i integer plus monoid i = w(0) w(0) + w(x) = w(x) w(x) + w(0) = w(x) r(w(a) + w(b)) = r(w(a+b)) = w(a+b) w(0) + w(6) = w(6) w(6) + w(0) = w(6) w(6) + w(1) = w(7) r(w(1) + w(2)) = r(w(1+2)) = r(w(3)) = w(3) am/pm clock monoid aka Beckman Time i = w(0,0) // time is a coordinateset w(a,b) = w(a%12,b%60) w(a,b) + w(0,0) = w(a,b) w(0,0) + w(a,b) = w(a,b) w(12,0) + w(1,0) = w(1,0) // loss of information r(w(a,b) + w(a',b')) = r(w(a+a',b+b')) = w(a+a',b+b') w(a,0) + w(0,b) = w(a,b) w(0,b) + w(a,0) = w(a,b) w(a,0) + w(b,0) = w(a+b,0) r(w(1,2) + w(4,3)) = r(w(1+4,2+3)) = w(1+4,2+3) = w(5,5) r(w(2,1) + w(3,4)) = r(w(2+3,1+4)) = w(2+3,1+4) = w(5,5) list monoid i = w() w(1) + w() = w(1) w() + w(1) = w(1) w(1) + w(2) = w(1,2) w(2) + w(1) = w(2,1) w(1,2) + w(3,4) = w(1,2,3,4) w(3,4) + w(1,2) = w(3,4,1,2) w(w(1),w(2)) + w(w(3),w(4)) ~ ((1),(2)) + ((3),(4)) = ((1),(2),(3),(4)) r(w(w(1),w(2)) + w(w(3),w(4))) = r(w(w(1),w(2)) + w(w(3),w(4))) = r(w(w(1),w(2),w(3),w(4))) = w(1,2,3,4) // "roll out"
Roll doesn't really make sense for integers and clocks because there's not really any useful structure to flatten, so it becomes a noop. For sets and lists yes because they can nest. Need to look a little more at the laws  but I love the way you "level" them.
Greg, didn't you mean strings are monads  as conceptually they are just lists of characters and therefore just a particular kind of list.
As Charles would say, if he was trapped in a monad:
"Wrap 'n Roll!".

@exoteric: I love Greg's analogies and he's a tremendous teacher. We are all in for a real educational treat. Thank you, Greg.
When you think about it; where else on the planet can you get educated, for free, by the likes of Erik Meijer, Brian Beckman, Stephan T. Lavavej, Greg Meredith, Yuri Gurevich and Don Syme? We are very fortunate. We'll have more lectures by titans of the industry, too. It's humbling to be a part of this.
Keep on learning. Stretch your minds.
Here's to Future 9.
C

Great video, looking forward to the next adition... please don't keep us waiting too long

@exoteric: Interesting that you said that Unit is 0. In the video unit is 1. This is something that confused me. It was unclear to me if the operator applied to the unit was increment or the unit meant to be identity.
I took it that it was meant to be the smallest incremental unit, especially since the unit was 1 and the operator was '+', rather than '*'. 
@Ken Jackson: I had to do a little Wikipedia'ing 
A monoid obeys 3 axioms:
 closure: whenever we compose two integers (+) we get another integer
 identity element: for integer addition (+) this has to be 0; for multiplication 1 ...
 associativity: (a + b) + c = a + (b + c);
for integers this should be true
(1 + 2) + 3 = 1 + (2 + 3);
but actually for lists too!
([1,2] + [3,4]) + [5,6] = [1,2,3,4,5,6] = [1,2] + ([3,4] + [5,6])
So actually lists and by proxy strings (lists of characters) are indeed both monoids but as opposed to integers under addition, lists (under append) are not commutative.
I guess we could also say that we have an "integer multiplication monoid", in that case:
 closure: multiplying two integers gives another integer  check
 identity element: 1 since 1 * a = a  check
 associativity: (a * b) * c = a * (b * c)  check
One thing I take away from this (perhaps wrongly) is that just saying "integer monoid" is misleading or ambiguous since there appears to be several ones, depending on what composition operator you choose (+, *, ...)
By the way  Greg is mentioned in the wikipedia article for monads

@Exoteric: In your defintion of the "integer monoid" (a.k.a. monoid of natural numbers with + and 0) you call u "unit". I find that a bit confusing as in the context of monads "unit" is often used synonymously for "return". On the other hand in algebra unit refers to a multiplicative identity element. I'd therefore prefer the termneutral element (or identity element) for u.
Again, great lecture! I'm looking forward to more!

@Novox: You're right, unit is confusing and misleading; it's as confusing as zero. So yes, i for identity would work better (I hope); fixed.

So is the monad the total off the three parts or the process of the three parts?
Timing is a wonderful thing, as I'm starting to get the idea with the help of the below link.

Really enjoyed the lecture. People might also want to check out Dan Piponi's "monads as trees" http://blog.sigfpe.com/2010/01/monadsaretreeswithgrafting.html. Also this talk is a must see: http://vimeo.com/6590617.

Hi Everyone!
Thank you Greg for a fantastic introduction to Monads and thanks Charles for making it happen. Great stuff!
I think I finally get a deeper understanding of what a monad is and would like to share an interesting revelation that I had connected with it. I realise what I say may sound somewhat strange but to me:
Monad = LIFE!
Hehe, let me elaborate...well generally speaking monad = change, I like to compare it to a transformation in life, we all go through different stages (wraps) in life and we need means (bind aka roll), in order to get from one stage to another.
It goes quite well with the KISS philosophy as well, the more complicated, scattered our life is, the more unmaintainable it is. What one would like to achieve, is to make his life simpler by taking out the unnecesary fuzz (scattered wraps) out of his life, thus ultimately creating a happier (monadic) version of life for himself, by using a kind of monadic transformation.
In that senese, to me the most difficult part of a monad would be the bind operator then, since this is were the transformation happens. In programming, just as in life, there is not one, universal bind operator, which forces us to come up with customized solutions for both our programs and lives.
Keep the lectures coming, I wonder where the next one will take me;)

I've turned my learning into an evolving blog post.
http://xosfaere.wordpress.com/2010/10/05/shapelymonads/Thanks for the great brain wash!
PS  looks like Greg's written a book about this:
http://www.amazon.com/ProScalaMonadicDesignPatterns/dp/143022844X

This is good stuff. On future slides can you use green or yellow instead of red? It doesn't show up very well ...
Thanks for posting this!

Great lecture  very enlightening and worth watching several times over.
Any news on when the next installment is likely to be available ?

2 days ago, Graham Hay wrote
Great lecture  very enlightening and worth watching several times over.
Any news on when the next installment is likely to be available ?
Greg is coming to the C9 Studio to film the next part tomorrow, so we'll have it available not too long after that (probably next week sometime).
C

@Charles: Can't wait for the next instalment to be available, keep up the good work!

I am still confused. Is there a more practical example? Like how does this make coding eaiser, clean, easier to maintain and so on?

It is all very amazing, just mindboggling
Comments closed
Comments have been closed since this content was published more than 30 days ago, but if you'd like to send us feedback you can Contact Us.