5 ms·

Monads are like a dildo factory, staffed by midgets

42 points by monksy 13y ago

paulgb 13y ago
> You didn’t learn python via abstract tutorial, comparing lists to Smaug and dicts to Bilbo [...] > STFU and code. There is no other way to learn to code. I think this is true of a lot of languages, but learning Haskell verges on learning mathematical concepts at times and learning monads is definitely one of those times. In these cases analogies are sometimes the easiest way to grok the concepts.
- gizmo686 13y ago
  I don't think this is necessarily true. I'm fairly strong in math, and definitively enjoy approaching problems in the abstract. However, even in math, it is often the case that by using something you gain an intuition about how that thing behaves. Monads defiantly worked that way for me. I am good enough at math that I could look at their definition and 'understand' what they are doing (it really isn't complicated, its just difficult to explain). However, when it came time to use them in code I had almost no intuition about how they should behave. Now, my understanding of them is (in my opinion) not at all the natural understanding that would arrive from their definition, but an understanding that is accurate, and far more useful in code.
Pherdnut 13y ago
I salute this man. And I still don't know wtf Monads are.
- gnuvince 13y ago
  Really? I thought that we had reached the point where the number of monad tutorials exceeded all other computer science literature put together.
  - Pherdnut 13y ago
    I wasn't really trying. I mostly write JavaScript or try to bite through the arteries in my wrists while suffering through other people's Java and C#.
- cpdean 13y ago
  moan-ads
stormbrew 13y ago
Seems like there's a monad tutorial posted here every week. This is by far the best one. Honestly, they mostly come across as condescending. At least this one's honest about it.
cpdean 13y ago
+1 for title. Don't understand monads still, so didn't read.
angersock 13y ago
So, maybe I'm just being overly provincial here--I rather suspect I am--but does anybody else wish people could explain, to a three year old, why anyone should give a fuck about monads? They always seem to come up along with Haskell, and as far as I can tell they seem mainly to be CS hipsterism. So, pretend I'm a three-year old...or even better, pretend I'm a grumpy old C programmer. Can anyone here (please!) explain to me: 1. What are monads (using grade-school language)? 2. What does a monad in C look like (or C++, if you need template magic or OO stuff)? 3. When will I use one outside of my Haskell class or Google interview? EDIT: I gather that monads are some kind of weird thingy related to doing proper function composition in type systems that would otherwise get in the way, but maybe I'm smoking crack?
- chongli 13y ago
  Just imagine C gave you the power to overload the semicolon operator. You could now write a series of expressions (separated by semicolons) to express other concepts (such as non-determinism, failure or state). This is scratching at the surface of what a monad does. It effectively allows you to define a context (with its own semantics) and gives you a set of powerful (overloaded) operators for working with values inside that context. In Haskell, side effects are constrained to the IO monad. This allows one to see, at a glance, whether or not a particular function has the ability to perform side effects. In C, on the other hand, it could be said that all functions live in the IO monad and that no other monads exist. This makes it harder to reason about the behaviour of a function, as one does not know whether or not it will perform side effects.
- wonderzombie 13y ago
  I can take a stab at this, but someone else might be more comprehensive. 1) Grade-school language is too hard. I am not a mathematician, though, nor a hardcore Haskeller. But maybe that's good enough. Let's see. A Monad is typically a parametric datatype which stores a value with some context. (A "parametric datatype" is just a concise way of describing something like scoped_ptr<Foo>.) An example would be Maybe. A Maybe is a parametric type, much like your scoped_ptr<>. An example would be Maybe Int. A Maybe Int can be one of two things: Nothing, or Just x, where x is any Integer. Examples: Just 2, Just -8, Just 0. Monads support two functions: bind and return. Maybe is no exception to this. Return (unfortunate name) puts a value inside a monad, in a minimal context. So if you apply "return" to the number 6, you get Just 6. Notice that unless you implement your own arithmetic routines, you can't (hand-wave) use operations like + or - on a Maybe Int. This is what the second operation, bind, is for. Bind applies a function to the value inside the monad, with the stipulation that the function in question itself results in a monad. (Hold on to that thought.) Bind is what you'd use to add (e.g.) 3 to Just 6, or how we'd divide Just 9 by 3. Why would Nothing be useful? Well, in this dumb example, you might want to implement a division operator. So what if you have Just 0 and attempts to divide it by 3? Well, since Nothing is a valid value for Maybe Int, you could just return that instead of throwing an exception. By convention many functions which can result in a failed computation return nothing. So a key lookup in a map, for instance, will return Maybe MyVal. It's incumbent on the caller to check for whether it's an instance of Nothing or Just MyVal; there's no "null" in the picture. (I'm hand-waving here; there's a ton of syntactic stuff in Haskell to make this very simple.) I'm not going to talk about function composition, except to say that Bind lends itself well to that; you can bind multiple items expecting such as a Maybe Int in a row, since a stipulation of bind is the result has to be a monad. 2) They're probably doable in C++ with template magic, but I would never ask someone to subject themselves to that. 3) You won't necessarily use them but they are a useful concept to have in mind. Maybe itself crops up in such as Scala or other places, as an Option type. It's conceivable that instead of returning null/None or the moral equivalent you design your classes such that nobody returns null. Instead you might return an empty Person class. Calls on it which do nothing could be a no-op instead of crashing the program, or what have you; you can define what behavior you want to occur rather than a crash/stack trace. I probably didn't do a good job explaining this but I hope it helps. I tried to define monads in a more operational way rather than explaining the theory, which I myself can't explain in a systematic or comprehensive way.
tonetheman 13y ago
And I still do not know what a effin monad is...
- MetaCosm 13y ago
  Did you try "stop reading fucking monad tutorials and write some code"?

42 points by monksy 13y ago

> You didn’t learn python via abstract tutorial, comparing lists to Smaug and dicts to Bilbo [...] > STFU and code. There is no other way to learn to code. I think this is true of a lot of languages, but learning Haskell verges on learning mathematical concepts at times and learning monads is definitely one of those times. In these cases analogies are sometimes the easiest way to grok the concepts.

gizmo686 13y ago
I don't think this is necessarily true. I'm fairly strong in math, and definitively enjoy approaching problems in the abstract. However, even in math, it is often the case that by using something you gain an intuition about how that thing behaves. Monads defiantly worked that way for me. I am good enough at math that I could look at their definition and 'understand' what they are doing (it really isn't complicated, its just difficult to explain). However, when it came time to use them in code I had almost no intuition about how they should behave. Now, my understanding of them is (in my opinion) not at all the natural understanding that would arrive from their definition, but an understanding that is accurate, and far more useful in code.

Pherdnut 13y ago

I salute this man. And I still don't know wtf Monads are.

gnuvince 13y ago
Really? I thought that we had reached the point where the number of monad tutorials exceeded all other computer science literature put together.
- Pherdnut 13y ago
  I wasn't really trying. I mostly write JavaScript or try to bite through the arteries in my wrists while suffering through other people's Java and C#.
cpdean 13y ago
moan-ads

stormbrew 13y ago

Seems like there's a monad tutorial posted here every week. This is by far the best one. Honestly, they mostly come across as condescending. At least this one's honest about it.

cpdean 13y ago

+1 for title. Don't understand monads still, so didn't read.

angersock 13y ago

So, maybe I'm just being overly provincial here--I rather suspect I am--but does anybody else wish people could explain, to a three year old, why anyone should give a fuck about monads? They always seem to come up along with Haskell, and as far as I can tell they seem mainly to be CS hipsterism. So, pretend I'm a three-year old...or even better, pretend I'm a grumpy old C programmer. Can anyone here (please!) explain to me: 1. What are monads (using grade-school language)? 2. What does a monad in C look like (or C++, if you need template magic or OO stuff)? 3. When will I use one outside of my Haskell class or Google interview? EDIT: I gather that monads are some kind of weird thingy related to doing proper function composition in type systems that would otherwise get in the way, but maybe I'm smoking crack?

chongli 13y ago
Just imagine C gave you the power to overload the semicolon operator. You could now write a series of expressions (separated by semicolons) to express other concepts (such as non-determinism, failure or state). This is scratching at the surface of what a monad does. It effectively allows you to define a context (with its own semantics) and gives you a set of powerful (overloaded) operators for working with values inside that context. In Haskell, side effects are constrained to the IO monad. This allows one to see, at a glance, whether or not a particular function has the ability to perform side effects. In C, on the other hand, it could be said that all functions live in the IO monad and that no other monads exist. This makes it harder to reason about the behaviour of a function, as one does not know whether or not it will perform side effects.
wonderzombie 13y ago
I can take a stab at this, but someone else might be more comprehensive. 1) Grade-school language is too hard. I am not a mathematician, though, nor a hardcore Haskeller. But maybe that's good enough. Let's see. A Monad is typically a parametric datatype which stores a value with some context. (A "parametric datatype" is just a concise way of describing something like scoped_ptr<Foo>.) An example would be Maybe. A Maybe is a parametric type, much like your scoped_ptr<>. An example would be Maybe Int. A Maybe Int can be one of two things: Nothing, or Just x, where x is any Integer. Examples: Just 2, Just -8, Just 0. Monads support two functions: bind and return. Maybe is no exception to this. Return (unfortunate name) puts a value inside a monad, in a minimal context. So if you apply "return" to the number 6, you get Just 6. Notice that unless you implement your own arithmetic routines, you can't (hand-wave) use operations like + or - on a Maybe Int. This is what the second operation, bind, is for. Bind applies a function to the value inside the monad, with the stipulation that the function in question itself results in a monad. (Hold on to that thought.) Bind is what you'd use to add (e.g.) 3 to Just 6, or how we'd divide Just 9 by 3. Why would Nothing be useful? Well, in this dumb example, you might want to implement a division operator. So what if you have Just 0 and attempts to divide it by 3? Well, since Nothing is a valid value for Maybe Int, you could just return that instead of throwing an exception. By convention many functions which can result in a failed computation return nothing. So a key lookup in a map, for instance, will return Maybe MyVal. It's incumbent on the caller to check for whether it's an instance of Nothing or Just MyVal; there's no "null" in the picture. (I'm hand-waving here; there's a ton of syntactic stuff in Haskell to make this very simple.) I'm not going to talk about function composition, except to say that Bind lends itself well to that; you can bind multiple items expecting such as a Maybe Int in a row, since a stipulation of bind is the result has to be a monad. 2) They're probably doable in C++ with template magic, but I would never ask someone to subject themselves to that. 3) You won't necessarily use them but they are a useful concept to have in mind. Maybe itself crops up in such as Scala or other places, as an Option type. It's conceivable that instead of returning null/None or the moral equivalent you design your classes such that nobody returns null. Instead you might return an empty Person class. Calls on it which do nothing could be a no-op instead of crashing the program, or what have you; you can define what behavior you want to occur rather than a crash/stack trace. I probably didn't do a good job explaining this but I hope it helps. I tried to define monads in a more operational way rather than explaining the theory, which I myself can't explain in a systematic or comprehensive way.

tonetheman 13y ago

And I still do not know what a effin monad is...

MetaCosm 13y ago
Did you try "stop reading fucking monad tutorials and write some code"?