Recorded at:

Demystifying Monads

Sections

Architecture & Design,

Development

Topics

F# ,

.NET Languages ,

.NET ,

QCon ,

Conferences ,

Programming ,

Patterns ,

QCon London 2010

The next QCon is in New York June 18-22, Join us!

Share |

RELATED Research

1. Back to top

   Horrible presentation. Total waste of time

   by Sebastian Kübeck

   remember that even if you are working for ThoughtWorks you should have a clue about what you are talking about and you should take some time to prepare presentations.

   Reply

2. Back to top

   If monads are Patterns then the examples could have been in Java

   by jean-simon Larochelle

   Or any other maintream language (C#, C++). F# is really not mainstream and looks like APL to me. Because of this the examples were useless and the presentation lost much of its interest.

   Reply

3. Back to top

   Absolutely Horrible Presentation

   by Jordan Terrell

   This presentation should be considered harmful. You will end up being more confused than when you started, and it makes many incorrect or misleading statements. I vote that it be removed from InfoQ.

   Reply

4. Back to top

   Re: If monads are Patterns then the examples could have been in Java

   by Kris Nuttycombe

   Actually, you can't represent the the general monad type in Java; the type system isn't rich enough to do so. You need higher-kinded types to express the monadic type.
   
   In Scala, the monadic type looks like this:
   
   

   
   trait Monad[M[_]] {
     def pure[A](a: A): M[A]
     def bind[A, X](m: M[A], f: A => M[X]): M[X] //aka return, aka >>=, aka flatMap...
   }
   

   
   
   See the A => M[X] part? Let's try to construct a monad interface in Java
   
   

   
   interface Monad<A> {
     public <X> Monad<X> bind(F<A, Monad<X>> function);
   }
   

   
   
   This doesn't work, because it would you imply you could pass a function returning *any* monad, whereas you must necessarily be able to pass only a function returning the type of monad you're working with. So you can write an interface for specific monads (Maybe shown below), but not the general monad interface.
   
   

   
   interface Maybe<A> {
     public <X> Maybe<X> bind(F<A, Maybe<X>> function);
   }
   

   
   
   This interface is fine. Now generalize it to List. There's no common superinterface of these two that can exist, because you can't abstract over the type constructor as we do in the Scala example.
   
   I know from recent experience that trying to give presentations on monads accessible to a broad audience is bloody difficult and frustrating. The problem is twofold; first, the "monad tutorial fallacy" issue of understanding of monads only being arrived at through use of monads is a huge hurdle - it's hard to take on faith that if you start using monads without really understanding how they work (because you must do so, in order to understand them!) will genuinely pay benefits. Second, in order to make good use of them, you've got to be writing code in an environment that supports using them, which means you have to step away from mainstream languages; Java, C++ and C# (which I suppose are the three most commonly used languages that actually support parametric polymorphism) don't support higher-kinded types, and dynamic languages miss a lot of the benefits of using monads simply because being able to reason about a computation via the types are where a lot of the benefits from using monads come from. So you have to go to Scala or F# or Haskell, and then you have to get used to thinking in types, and you have to do all of this without knowing ahead of time what the benefits will really be.

   Reply

5. Back to top

   Re: If monads are Patterns then the examples could have been in Java

   by Kris Nuttycombe

   oops, that "//aka return" was supposed to be up a line

   Reply

6. Back to top

   See. That's better already

   by jean-simon Larochelle

   From your explanation a Java programmer already gets a better intuitive feel about the concept. I think that for something like this one should not refrain from "adding" the needed features to a language. If you need to be able to pass function around just add this missing feature to Java for the sake of the presentation. Explain the syntax you will use and then proceed with the explanation. Of course this can work only if the parts that are missing are few. If you need to add too much to the language then it becomes useless.
   Thank you for your input.

   Reply

7. Back to top

   FUGLY presenter!

   by Ivan Salazar

   Beautiful language and patterns he's *trying* to explain but he's like a zombie trying to talk about vegetarianism. Kick this asshole out and read this Simon Peyton-Jones paper: research.microsoft.com/en-us/um/people/simonpj/... .

   Reply

8. Back to top

   Re: FUGLY presenter!

   by Michael Apostol

   Do you have a personal vendetta with this presenter? Where did you learn to communicate? Regardless of what you think of the presentation and presenter, it is you sir who comes across as the $%#hole. Let me guess, you are an American on East or West Coast? I would bet East...
   
   Get some manners. You come across like a child.

   Reply

9. Back to top

   Re: FUGLY presenter!

   by Ivan Salazar

   Sorry.
   
   I tend to overreact when Haskell is being misrepresented. And no, I'm not an American. And yes, in this particular one, I looked like a child. Your reply helped me to put myself in perspective.
   
   Thanks, and sorry again.

   Reply