9 ms·

http://dev.stephendiehl.com/hask/#monads http://dev.stephendiehl.com/hask/#monads

jnordwick 10y ago
Are you serious? > Monads are not complicated. They are implemented as a typeclass with two methods, return and (>>=) (pronounced "bind"). In order to implement a Monad instance, these two functions must be defined in accordance with the arity described in the typeclass definition: This is a great example of what I just said: it uses complex Haskell code and functions to describe a monad. If you already know what it assumes you know, you most likely already know what a monad is.
- setra 10y ago
  If I define this in c++ lingo words barely change. You take a c++ parent class with two virtual methods. These methods are "return" and "bind". In order to implement a monad instance you must derive from this parents class and implement the virtual methods.
  - jnordwick 10y ago
    What is bind and what is return? What do they do?
    - setra 10y ago
      I was translating your quote to c++ lingo not defining functions. return takes a value and returns an instance of your template class containing the value. bind takes an instance of your (template class A) a function of (type a ) to (template class B) and produces a value of (template class B). If you don't care about the "laws" your definitions are expected to follow thats it. The idea bind is you take a value of a template class such as (std::vector<Int> type) the value {3}, then based on value either pass it to the next function or return it. one definition of bind would be if the vector is empty return it, if its not empty pass it to this function and return the result of that function. return is just a way of placing a value into your template container class.
    - deleted 10y ago
      [deleted]
- seagreen 10y ago
  I posted that because I think it's the best you're going to get. Monads can be two things: (1) a concept in category theory, (2) a rough implementation of that concept in a programming language. If you want to learn about monads from the category theory perspective, great! This is really hard though, I wouldn't recommend it for most people (and haven't really even succeeded myself). If you want to learn about a specific programming language's implementation of monads, you will naturally have to know how that language works. This road is far easier than category theory, but still requires knowing (for Haskell) what a typeclass is, what a higher-kinded type is, etc. It sounds like you want an explanation without prereqs from either category theory or Haskell. If you google for monad tutorials you will find dozens of quick explanations, but I personally don't think this is a good way to actually understand them.
  - jnordwick 10y ago
    Describe monads to Lisp, Scheme, APL person. You can do that with the y-combinator but why not monads?
    - tel 10y ago
      Because these languages lack a way of discussing something at the right "higher order" as Monads. You can implement them, but there's no word for the kind of thing a monad is. There's not even a real word for a type. You need types. Then you need "higher order types" or parameterized types. Then you need a way to discuss a common set of operations which appear repeatedly for some of these parameterized types and it can't be OO-like. You can exemplify the operations in, e.g., Lisp, but you have a hard time "talking about" the thing. --- In Scheme, monads are the answer to the following question: The functions (define (pure a) (list a)) and (define (join ls) (foldl append (list) ls)) are related to lists in the same way that (define (pure a) (lambda (k) (k a))) and (define (join z) (lambda (k) ((z k) k))) is related to CPS-transformed programs. What is the commonality?
      - deleted 10y ago
        [deleted]
      - 10y ago
- Nadya 10y ago
  To understand monads one must first understand monads. I'm not even saying that a bit sarcastically. I've read countless "tutorials" and even tried messing around with Haskell in an attempt to grok monads. According to the link shared by GP comment, my understanding is still completely wrong. There is a reason there is a joke about it. "A monad is just a monoid in the category of endofunctors, what's the probleⅿ?" - James Iry, taken from [0] [0] http://james-iry.blogspot.com/2009/05/brief-incomplete-and-mostly-wrong.html http://james-iry.blogspot.com/2009/05/brief-incomplete-and-m...
  - Smaug123 10y ago
    I consider that quote to be a demonstration of the simple/easy axes referenced in a relative of this comment. It demonstrates that monads are simple things, since endofunctors, categories and monoids are all simple concepts.
- jghn 10y ago
  As a scala developer the thing which got me on my way was the explanation "something which has a flatMap method". That's not entirely true but it gets you in the right ballpark.
  - deleted 10y ago
    [deleted]
- zodiac 10y ago
  Well, you really should know the amount of Haskell it assumes you know (typeclasses, maybe infix functions, arity etc) before learning about Haskell monads. Otherwise you're learning multiple concepts at once - why not learn about those other concepts in other contexts first? The Stephen Diel article even lists the prerequisites explicitly. My favourite monad explanation is Tikhon Jelvis's at https://www.quora.com/What-are-monads-in-functional-programming-and-why-are-they-useful https://www.quora.com/What-are-monads-in-functional-programm..., but reading through it, it does assume some prerequisite knowledge about Haskell.
- chongli 10y ago
  Simple /= easy. Complex /= hard. Monads are very simple. They just aren't easy because most people don't have the base of terminology. When you grok them you'll laugh because you'll realize how simple and powerful and obvious they seem in hindsight. This is the reason so many people write monad tutorials after they learn them. It's actually really weird. Does anyone else have some examples of things they learned which seemed really difficult but turned out to be really simple in hindsight?
  - smallnamespace 10y ago
    > They just aren't easy because most people don't have the base of terminology That's like saying a giant, complex library with a nice, tight API is 'simple'. It's not, the complexity is just hidden. Same thing with monads. Once you understand some of the machinery of category theory, or really grok functional programming, then yes, monads are 'simple', but all the complexity lies in getting there.
    - kccqzy 10y ago
      I think you're confusing complexity with learning curve. Complex things can be made easy to learn, if, for example, you have "a nice, tight API." Monads are the opposite. They are simple things that are difficult to learn.
      - smallnamespace 10y ago
        Why would something be difficult to learn if there wasn't complexity underneath it? There are lots of things that are simple to state, like the fundamental theorem of algebra, but the machinery behind it is complex.
        chousuke 10y ago
        A simple thing can be difficult because understanding why it works may be nontrivial. However, it remains simple (by definition) if understanding is not affected by complecting factors such as side-effects or the global state of the system. A pure function is always simple, even if it implements a difficult algorithm. I hold the opinion that complicated things can never be truly easy: they can only have the appearance of ease until there comes a time that you must understand all the complexity.

Are you serious? > Monads are not complicated. They are implemented as a typeclass with two methods, return and (>>=) (pronounced "bind"). In order to implement a Monad instance, these two functions must be defined in accordance with the arity described in the typeclass definition: This is a great example of what I just said: it uses complex Haskell code and functions to describe a monad. If you already know what it assumes you know, you most likely already know what a monad is.

setra 10y ago
If I define this in c++ lingo words barely change. You take a c++ parent class with two virtual methods. These methods are "return" and "bind". In order to implement a monad instance you must derive from this parents class and implement the virtual methods.
- jnordwick 10y ago
  What is bind and what is return? What do they do?
  - setra 10y ago
    I was translating your quote to c++ lingo not defining functions. return takes a value and returns an instance of your template class containing the value. bind takes an instance of your (template class A) a function of (type a ) to (template class B) and produces a value of (template class B). If you don't care about the "laws" your definitions are expected to follow thats it. The idea bind is you take a value of a template class such as (std::vector<Int> type) the value {3}, then based on value either pass it to the next function or return it. one definition of bind would be if the vector is empty return it, if its not empty pass it to this function and return the result of that function. return is just a way of placing a value into your template container class.
  - deleted 10y ago
    [deleted]
seagreen 10y ago
I posted that because I think it's the best you're going to get. Monads can be two things: (1) a concept in category theory, (2) a rough implementation of that concept in a programming language. If you want to learn about monads from the category theory perspective, great! This is really hard though, I wouldn't recommend it for most people (and haven't really even succeeded myself). If you want to learn about a specific programming language's implementation of monads, you will naturally have to know how that language works. This road is far easier than category theory, but still requires knowing (for Haskell) what a typeclass is, what a higher-kinded type is, etc. It sounds like you want an explanation without prereqs from either category theory or Haskell. If you google for monad tutorials you will find dozens of quick explanations, but I personally don't think this is a good way to actually understand them.
- jnordwick 10y ago
  Describe monads to Lisp, Scheme, APL person. You can do that with the y-combinator but why not monads?
  - tel 10y ago
    Because these languages lack a way of discussing something at the right "higher order" as Monads. You can implement them, but there's no word for the kind of thing a monad is. There's not even a real word for a type. You need types. Then you need "higher order types" or parameterized types. Then you need a way to discuss a common set of operations which appear repeatedly for some of these parameterized types and it can't be OO-like. You can exemplify the operations in, e.g., Lisp, but you have a hard time "talking about" the thing. --- In Scheme, monads are the answer to the following question: The functions (define (pure a) (list a)) and (define (join ls) (foldl append (list) ls)) are related to lists in the same way that (define (pure a) (lambda (k) (k a))) and (define (join z) (lambda (k) ((z k) k))) is related to CPS-transformed programs. What is the commonality?
    - deleted 10y ago
      [deleted]
    - 10y ago
Nadya 10y ago
To understand monads one must first understand monads. I'm not even saying that a bit sarcastically. I've read countless "tutorials" and even tried messing around with Haskell in an attempt to grok monads. According to the link shared by GP comment, my understanding is still completely wrong. There is a reason there is a joke about it. "A monad is just a monoid in the category of endofunctors, what's the probleⅿ?" - James Iry, taken from [0] [0] http://james-iry.blogspot.com/2009/05/brief-incomplete-and-mostly-wrong.html http://james-iry.blogspot.com/2009/05/brief-incomplete-and-m...
- Smaug123 10y ago
  I consider that quote to be a demonstration of the simple/easy axes referenced in a relative of this comment. It demonstrates that monads are simple things, since endofunctors, categories and monoids are all simple concepts.
jghn 10y ago
As a scala developer the thing which got me on my way was the explanation "something which has a flatMap method". That's not entirely true but it gets you in the right ballpark.
- deleted 10y ago
  [deleted]
zodiac 10y ago
Well, you really should know the amount of Haskell it assumes you know (typeclasses, maybe infix functions, arity etc) before learning about Haskell monads. Otherwise you're learning multiple concepts at once - why not learn about those other concepts in other contexts first? The Stephen Diel article even lists the prerequisites explicitly. My favourite monad explanation is Tikhon Jelvis's at https://www.quora.com/What-are-monads-in-functional-programming-and-why-are-they-useful https://www.quora.com/What-are-monads-in-functional-programm..., but reading through it, it does assume some prerequisite knowledge about Haskell.
chongli 10y ago
Simple /= easy. Complex /= hard. Monads are very simple. They just aren't easy because most people don't have the base of terminology. When you grok them you'll laugh because you'll realize how simple and powerful and obvious they seem in hindsight. This is the reason so many people write monad tutorials after they learn them. It's actually really weird. Does anyone else have some examples of things they learned which seemed really difficult but turned out to be really simple in hindsight?
- smallnamespace 10y ago
  > They just aren't easy because most people don't have the base of terminology That's like saying a giant, complex library with a nice, tight API is 'simple'. It's not, the complexity is just hidden. Same thing with monads. Once you understand some of the machinery of category theory, or really grok functional programming, then yes, monads are 'simple', but all the complexity lies in getting there.
  - kccqzy 10y ago
    I think you're confusing complexity with learning curve. Complex things can be made easy to learn, if, for example, you have "a nice, tight API." Monads are the opposite. They are simple things that are difficult to learn.
    - smallnamespace 10y ago
      Why would something be difficult to learn if there wasn't complexity underneath it? There are lots of things that are simple to state, like the fundamental theorem of algebra, but the machinery behind it is complex.
      - chousuke 10y ago
        A simple thing can be difficult because understanding why it works may be nontrivial. However, it remains simple (by definition) if understanding is not affected by complecting factors such as side-effects or the global state of the system. A pure function is always simple, even if it implements a difficult algorithm. I hold the opinion that complicated things can never be truly easy: they can only have the appearance of ease until there comes a time that you must understand all the complexity.