Demystifying Monads
Recorded at:
- Share
-
- |
Read later
My Reading List
Bio
Josh Graham, ThoughtWorks, has over 19 years experience in the software industry and is the Chief Dispenser of Pleasantries at ThoughtWorks. Graham has spoken at and chaired conferences on SOA, enterprise architecture, agile software delivery, and technology innovation.
QCon is a conference that is organized by the community, for the community.The result is a high quality conference experience where a tremendous amount of attention and investment has gone into having the best content on the most important topics presented by the leaders in our community.QCon is designed with the technical depth and enterprise focus of interest to technical team leads, architects, and project managers.
Horrible presentation. Total waste of time
by
Sebastian Kübeck
If monads are Patterns then the examples could have been in Java
by
jean-simon Larochelle
Absolutely Horrible Presentation
by
Jordan Terrell
Re: If monads are Patterns then the examples could have been in Java
by
Kris Nuttycombe
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.
Re: If monads are Patterns then the examples could have been in Java
by
Kris Nuttycombe
See. That's better already
by
jean-simon Larochelle
Thank you for your input.
FUGLY presenter!
by
Ivan Salazar
Re: FUGLY presenter!
by
Michael Apostol
Get some manners. You come across like a child.
Hello stranger!
You need to Register an InfoQ account or Login to post comments. But there's so much more behind being registered.Get the most out of the InfoQ experience.
Tell us what you think