3 ms·

You're using monads whenever you use Java 8 streams, Javascript promises, ActiveRecord and collection operations in Rails / Ruby; monads are everywhere these da

You're using monads whenever you use Java 8 streams, Javascript promises, ActiveRecord and collection operations in Rails / Ruby; monads are everywhere these days. Monads are one of the handiest design patterns you can use; all you really need is a decent lambda syntax and you're off to the races.

skybrian 9y ago
The monad abstraction takes a lot of unlike programming features and abstracts away most of the important stuff to show something they have in common. The question is whether users of those features need to know about this abstraction? Why should we care that they have something in common? They're mostly different. As concepts get more abstract, they get harder to teach. I don't think knowing that JavaScript promises are a monad is all that helpful when learning to do async I/O.
- the_af 9y ago
  > Why should we care that they have something in common? They're mostly different. You can of course ignore it, but it's useful to care about this because they are actually similar over this shared commonality. You start seeing patterns over which you can apply the same general functions. Just like you can map over an Option or a List or any "mappable-over" structure. This is similar to asking (in a made up language, forget the specifics): "why should I care that Lists and Sets and Arrays and Enumerations have a shared 'iterable' interpretation? Sets and Lists are mostly different!" Well, because sometimes it's useful to have functions that operate on iterables, instead of writing one for Lists and another for Sets. Once this idea "clicks" in your mind, you start seeing more and more of this commonalities, and it starts to shape how you think about coding.
  - skybrian 9y ago
    Sure, I agree. My point is that just as with other design patterns, it's possible to overdo it and lose your audience. Enthusiasts can definitely go overboard here.
- dragonwriter 9y ago
  > Why should we care that they have something in common? Well, for one thing, you can write reusable code that leverages this commonality and provides common functionality with regard to any Monad (ditto with related abstractions like Monoids, Applicative Functors, basic Functors, etc.) That's kind of the whole point: you can provide in reusable library code what in other language would, at best, be recipe-driven repeated-boilerplate design patterns.
OtterCoder 9y ago
Monads are too general though. Saying 'try monads' to solve a problem is like telling someone, 'try vowels' when they're trying pronounce a word.
nybble41 9y ago
You're using monads whenever you code in any imperative language. The "bind" pattern is simply so pervasive that you don't even recognize that it's there, but any time you use information obtained through one side-effect as part of another side-effect, that's a monad. That trivial read-a-name-and-print-a-greeting program which frequently shows up on the first day of Intro to Programming? Yep, that's using a monad. The difference with functional programming is that you can choose not to use monads, and IO, and other powerful abstractions which are baked in so pervasively into other languages. This enables more powerful static analysis and code reuse, but it also means that you need to be aware of what you're giving up in the process, such as the ability to choose effects at runtime based on the results of prior effects. People who have been using monads throughout their entire programming career are thus suddenly faced with trying to understand what a monad actually is and what sets it apart from non-monadic code. This leads to people writing tutorials and papers and blog posts, which causes people to think it's some super-complex concept accessible only to genius mathematicians, which leads to more tutorials... The neat thing is, once you've begun to see the pattern, it turns out to be useful in other areas besides sequencing I/O effects; non-determinism, coroutines, generators, parsers, and so on. Most languages make sequencing I/O effects so easy you don't even notice it's happening, but other monadic patterns, lacking built-in syntax, are far more unwieldy. Haskell puts them all on the same footing via the Monad typeclass and do-notation.

skybrian 9y ago

The monad abstraction takes a lot of unlike programming features and abstracts away most of the important stuff to show something they have in common. The question is whether users of those features need to know about this abstraction? Why should we care that they have something in common? They're mostly different. As concepts get more abstract, they get harder to teach. I don't think knowing that JavaScript promises are a monad is all that helpful when learning to do async I/O.

the_af 9y ago
> Why should we care that they have something in common? They're mostly different. You can of course ignore it, but it's useful to care about this because they are actually similar over this shared commonality. You start seeing patterns over which you can apply the same general functions. Just like you can map over an Option or a List or any "mappable-over" structure. This is similar to asking (in a made up language, forget the specifics): "why should I care that Lists and Sets and Arrays and Enumerations have a shared 'iterable' interpretation? Sets and Lists are mostly different!" Well, because sometimes it's useful to have functions that operate on iterables, instead of writing one for Lists and another for Sets. Once this idea "clicks" in your mind, you start seeing more and more of this commonalities, and it starts to shape how you think about coding.
- skybrian 9y ago
  Sure, I agree. My point is that just as with other design patterns, it's possible to overdo it and lose your audience. Enthusiasts can definitely go overboard here.
dragonwriter 9y ago
> Why should we care that they have something in common? Well, for one thing, you can write reusable code that leverages this commonality and provides common functionality with regard to any Monad (ditto with related abstractions like Monoids, Applicative Functors, basic Functors, etc.) That's kind of the whole point: you can provide in reusable library code what in other language would, at best, be recipe-driven repeated-boilerplate design patterns.

OtterCoder 9y ago

Monads are too general though. Saying 'try monads' to solve a problem is like telling someone, 'try vowels' when they're trying pronounce a word.

nybble41 9y ago

You're using monads whenever you code in any imperative language. The "bind" pattern is simply so pervasive that you don't even recognize that it's there, but any time you use information obtained through one side-effect as part of another side-effect, that's a monad. That trivial read-a-name-and-print-a-greeting program which frequently shows up on the first day of Intro to Programming? Yep, that's using a monad. The difference with functional programming is that you can choose not to use monads, and IO, and other powerful abstractions which are baked in so pervasively into other languages. This enables more powerful static analysis and code reuse, but it also means that you need to be aware of what you're giving up in the process, such as the ability to choose effects at runtime based on the results of prior effects. People who have been using monads throughout their entire programming career are thus suddenly faced with trying to understand what a monad actually is and what sets it apart from non-monadic code. This leads to people writing tutorials and papers and blog posts, which causes people to think it's some super-complex concept accessible only to genius mathematicians, which leads to more tutorials... The neat thing is, once you've begun to see the pattern, it turns out to be useful in other areas besides sequencing I/O effects; non-determinism, coroutines, generators, parsers, and so on. Most languages make sequencing I/O effects so easy you don't even notice it's happening, but other monadic patterns, lacking built-in syntax, are far more unwieldy. Haskell puts them all on the same footing via the Monad typeclass and do-notation.