8 ms·

I've had an idea for a monad tutorial that I think might be quite instructive, but haven't had the motivation yet to write. In essence, the idea is that you ar

I've had an idea for a monad tutorial that I think might be quite instructive, but haven't had the motivation yet to write. In essence, the idea is that you are led through the process of implementing: early exit, nondeterminism, threaded state and coroutines using call/cc in scheme. Then monads are introduced as a way of typing those patterns.

thirsteh 12y ago
I'm 99% sure this is the way to do it. You can't explain any field of math, much less category theory, without doing exercises.
peteretep 12y ago
Have you seen "You Could Have Invented Monads"?
- agumonkey 12y ago
  I understand concepts better when taken outside their ''''natural'''' environment (namely strongly paramectrically typed [lazy] languages). I often link these two : http://stackoverflow.com/questions/11871065/monads-in-javascript http://stackoverflow.com/questions/11871065/monads-in-javasc... http://dorophone.blogspot.fr/2011/04/deep-emacs-part-1.html http://dorophone.blogspot.fr/2011/04/deep-emacs-part-1.html
mdcox 12y ago
It seems like those with functional programming experience either already understand monads or grasp it quickly. At the same time, those without it have an instinctual eye-glaze when shown Haskell, or a lisp. Would it be better to use Python or Javascript which more people understand but still has that functional flair? Just an idea. Either way I look forward to reading it!
- karavelov 12y ago
  Dynamically typed languages are not the best choice when you try to explain algebras that work on the type level I guess.
- chriswarbo 12y ago
  > It seems like those with functional programming experience either already understand monads or grasp it quickly. That's probably survivor-bias (amongst Haskellers, at least); ie. those who haven't grasped it yet probably won't class themselves as Haskellers. > Would it be better to use Python or Javascript which more people understand but still has that functional flair? The problem with using such languages is that they're always dealing with concrete values; in particular they have no concept of interfaces (like Java) or typeclasses (like Haskell). It's certainly possible to use monads in such languages, but it's often hard to justify their use, since there are always less-complex ways to implement particular examples, and without interfaces it's hard to relate the examples together. For example, here are a bunch of monad implementations ("return" and "bind", AKA ">>=") in Javascript, but it's not at all obvious why they are related to each other: function state_return(val) { return [null, val]; } function state_bind(x, f) { return f(x[0], x[1]); } function maybe_return(val) { return [val]; } function maybe_bind(x, f) { return (x.length > 0)? f(x[0]) : []; } function list_return(val) { return [val]; } function list_bind(x, f) { return [].concat.apply([], x.map(f)); } function read_return(val) { return function(x) { return val; }; } function read_bind(x, f) { return function(arg) { f(x(arg))(arg); }; } The problem is that in Javascript, the implementation details are there for all to see. I might want to give you a string which depends on some integer state, but you can always see that it's actually implemented as an array containing an int and a string. You're also free to mess up that array by adding or removing elements from it, which are perfectly valid array operations, but which makes no sense for "stateful values". Interfaces like monads are useful when we're not free to mess around with the implementation; when we must perform all actions through a limited API. When we're dealing with such concerns every day ("I'd like to allow X, but don't want anyone to abuse it and end up with Y") then monads (and functors and applicatives, which they're based on) are really useful as standard APIs for allowing arbitrary operations to be performed, under the control of the API. The only example above that even comes close to this idea is the "reader" monad, implemented with `read_return` and `read_bind`. This is because values in the reader monad lets us manipulate the return values of functions, and even in dynamic languages a first-class function is pretty much a black box, so there's little we can do to mess it up.
klibertp 12y ago
I think most monad tutorials would be quite ok if they didn't use words like "monad", "bind", "return" and so on. It's just stupid to insist on using names which mean nothing or when they mean something (return) it's actually opposite of what they're supposed to do. And no, there are no upsides to this: you math-inclined people may think so because you were trained to think that way, but it's simply not true. I suspected this for a long time, but recently I saw a talk from Gilad Bracha - http://www.infoq.com/presentations/functional-pros-cons http://www.infoq.com/presentations/functional-pros-cons - which convinced me that I was right. Scroll to ~22 minutes into the talk for relevant section. Ok, I finally said it. I feel better now, thanks ;)
- deleted 12y ago
  [deleted]
- abathologist 12y ago
  I find that talk really painful. I do not recommend it. It is mean spirited, full of misleading characterizations, and - I think - it misses the core point of functional programming. Gary Verhaegen's comment "this was a waste of time" addresses the many problems effectively. Brian Craft's "ugh" addresses others. Either of those comments are more worthwhile than the video itself.
  - klibertp 12y ago
    > I find that talk really painful. I suspect it may be painful in some cases, it's somewhat like a clash of different cultures. The guy is firmly rooted in Smalltalk and Lisp schools of thinking and everything he says is rather obvious for those who share the same background. On the other hand it may be obviously false for people following ML tradition and even more so for recent converts. Watching this talk calmed me down. It turns out that I'm not an idiot, that I know how to do FP (because I quite like it!) and that there's no need to change my ways just because some vocal minority proclaims me a heretic for preferring meaningful names or no-nonsense IO handling. On the whole I think it was an hour well-spent. YMMV ofc.
    - 12y ago
tel 12y ago
Almost everyone who "know monads well" agrees with you. Studying monads is silly. It's a pattern you'll eventually recognize and just so happens to have a syntactic trick. Study particular instances.
inglesp 12y ago
Sounds not-so-dissimilar to Tom Stuart's "Refactoring Ruby with Monads" (https://speakerdeck.com/tomstuart/refactoring-ruby-with-monads https://speakerdeck.com/tomstuart/refactoring-ruby-with-mona...) which is excellent.
antoaravinth 12y ago
What about monads in terms of JS over here: https://blog.jcoglan.com/2011/03/05/translation-from-haskell-to-javascript-of-selected-portions-of-the-best-introduction-to-monads-ive-ever-read/ https://blog.jcoglan.com/2011/03/05/translation-from-haskell...

thirsteh 12y ago

I'm 99% sure this is the way to do it. You can't explain any field of math, much less category theory, without doing exercises.

peteretep 12y ago

Have you seen "You Could Have Invented Monads"?

agumonkey 12y ago
I understand concepts better when taken outside their ''''natural'''' environment (namely strongly paramectrically typed [lazy] languages). I often link these two : http://stackoverflow.com/questions/11871065/monads-in-javascript http://stackoverflow.com/questions/11871065/monads-in-javasc... http://dorophone.blogspot.fr/2011/04/deep-emacs-part-1.html http://dorophone.blogspot.fr/2011/04/deep-emacs-part-1.html

mdcox 12y ago

It seems like those with functional programming experience either already understand monads or grasp it quickly. At the same time, those without it have an instinctual eye-glaze when shown Haskell, or a lisp. Would it be better to use Python or Javascript which more people understand but still has that functional flair? Just an idea. Either way I look forward to reading it!

karavelov 12y ago
Dynamically typed languages are not the best choice when you try to explain algebras that work on the type level I guess.
chriswarbo 12y ago
> It seems like those with functional programming experience either already understand monads or grasp it quickly. That's probably survivor-bias (amongst Haskellers, at least); ie. those who haven't grasped it yet probably won't class themselves as Haskellers. > Would it be better to use Python or Javascript which more people understand but still has that functional flair? The problem with using such languages is that they're always dealing with concrete values; in particular they have no concept of interfaces (like Java) or typeclasses (like Haskell). It's certainly possible to use monads in such languages, but it's often hard to justify their use, since there are always less-complex ways to implement particular examples, and without interfaces it's hard to relate the examples together. For example, here are a bunch of monad implementations ("return" and "bind", AKA ">>=") in Javascript, but it's not at all obvious why they are related to each other: function state_return(val) { return [null, val]; } function state_bind(x, f) { return f(x[0], x[1]); } function maybe_return(val) { return [val]; } function maybe_bind(x, f) { return (x.length > 0)? f(x[0]) : []; } function list_return(val) { return [val]; } function list_bind(x, f) { return [].concat.apply([], x.map(f)); } function read_return(val) { return function(x) { return val; }; } function read_bind(x, f) { return function(arg) { f(x(arg))(arg); }; } The problem is that in Javascript, the implementation details are there for all to see. I might want to give you a string which depends on some integer state, but you can always see that it's actually implemented as an array containing an int and a string. You're also free to mess up that array by adding or removing elements from it, which are perfectly valid array operations, but which makes no sense for "stateful values". Interfaces like monads are useful when we're not free to mess around with the implementation; when we must perform all actions through a limited API. When we're dealing with such concerns every day ("I'd like to allow X, but don't want anyone to abuse it and end up with Y") then monads (and functors and applicatives, which they're based on) are really useful as standard APIs for allowing arbitrary operations to be performed, under the control of the API. The only example above that even comes close to this idea is the "reader" monad, implemented with `read_return` and `read_bind`. This is because values in the reader monad lets us manipulate the return values of functions, and even in dynamic languages a first-class function is pretty much a black box, so there's little we can do to mess it up.

klibertp 12y ago

I think most monad tutorials would be quite ok if they didn't use words like "monad", "bind", "return" and so on. It's just stupid to insist on using names which mean nothing or when they mean something (return) it's actually opposite of what they're supposed to do. And no, there are no upsides to this: you math-inclined people may think so because you were trained to think that way, but it's simply not true. I suspected this for a long time, but recently I saw a talk from Gilad Bracha - http://www.infoq.com/presentations/functional-pros-cons http://www.infoq.com/presentations/functional-pros-cons - which convinced me that I was right. Scroll to ~22 minutes into the talk for relevant section. Ok, I finally said it. I feel better now, thanks ;)

deleted 12y ago
[deleted]
abathologist 12y ago
I find that talk really painful. I do not recommend it. It is mean spirited, full of misleading characterizations, and - I think - it misses the core point of functional programming. Gary Verhaegen's comment "this was a waste of time" addresses the many problems effectively. Brian Craft's "ugh" addresses others. Either of those comments are more worthwhile than the video itself.
- klibertp 12y ago
  > I find that talk really painful. I suspect it may be painful in some cases, it's somewhat like a clash of different cultures. The guy is firmly rooted in Smalltalk and Lisp schools of thinking and everything he says is rather obvious for those who share the same background. On the other hand it may be obviously false for people following ML tradition and even more so for recent converts. Watching this talk calmed me down. It turns out that I'm not an idiot, that I know how to do FP (because I quite like it!) and that there's no need to change my ways just because some vocal minority proclaims me a heretic for preferring meaningful names or no-nonsense IO handling. On the whole I think it was an hour well-spent. YMMV ofc.
  - 12y ago

tel 12y ago

Almost everyone who "know monads well" agrees with you. Studying monads is silly. It's a pattern you'll eventually recognize and just so happens to have a syntactic trick. Study particular instances.

inglesp 12y ago

Sounds not-so-dissimilar to Tom Stuart's "Refactoring Ruby with Monads" (https://speakerdeck.com/tomstuart/refactoring-ruby-with-monads https://speakerdeck.com/tomstuart/refactoring-ruby-with-mona...) which is excellent.

antoaravinth 12y ago

What about monads in terms of JS over here: https://blog.jcoglan.com/2011/03/05/translation-from-haskell-to-javascript-of-selected-portions-of-the-best-introduction-to-monads-ive-ever-read/ https://blog.jcoglan.com/2011/03/05/translation-from-haskell...