4 ms·

Anybody who didn't know what monads were and now reached an epiphany thanks to this article please comment. Also is there anyone here who understands what mona

Anybody who didn't know what monads were and now reached an epiphany thanks to this article please comment. Also is there anyone here who understands what monads are but has never programmed in haskell or a functional language?

dkarapetyan 11y ago
Monads come from category theory. You can certainly know what they are without ever having programmed. "Basic Category Theory for Computer Scientists" and "Category Theory (Oxford Logic Guides)" are good places to start.
- crimsonalucard 11y ago
  Rightly so, but look at the replies to my post. Essentially nobody responded to my query. Looks like mostly Nobody knows what monads are without learning functional programming AND this article totally failed to help anyone understand what monads are.
olavk 11y ago
I don't believe monads are worth the bother without some syntactic sugar. Without sugar, it is just a sequence of operations converted into a chain of nested lambdas with one lambda for each operation. Cool, but far to convoluted to write for any real-world programs. The attempts to introduce monads in other languages like Python, Ruby etc. is missing what make them a useful tool in Haskell.
- exDM69 11y ago
  > The attempts to introduce monads in other languages like Python, Ruby etc. is missing what make them a useful tool in Haskell. While I agree that the syntactic sugar of the "do" notation in Haskell makes Monads vastly more useful, there are examples where Monads have been applied in other programming languages without any syntactic sugar. For example, there are parser combinator libraries (influenced by Parsec) in many languages. E.g. Python's pyparsec is internally using monads that are defined just as they are in Haskell. Monads are a great idea for many practical tasks in programming, their use in Haskell is often emphasized becuse they're required for IO (which is not the case for imperative languages). For many of the non-IO applications of monads, they're just as useful in other languages too.
- tikhonj 11y ago
  I've used Async and LWT in OCaml—libraries for monadic asynchronous programming—and the abstraction can still be useful without syntax sugar. Hell, JavaScript promises are basically a bastardized and slightly inconsistent monad, and they're still useful even without syntax sugar. If we could generalize over the API and use them for other things it would be even better, but that's not the JavaScript way.
  - olavk 11y ago
    How are JS promises monads?
    - tikhonj 11y ago
      They actually operate on more or less the same principle as Async and LWT, similar to Haskell's Cont. The .then method is bind. Or it would be if they didn't automatically flatten nested promises. Since they do, then is a hybrid of map and bind that doesn't quite cover the use cases for both.
falcolas 11y ago
The problem with this article is it assumes you understand Scala. There's a lot of line noise going on there, which I was later able to infer as "this is Lambda notation". Following that is the immediate (apologetic) use of `andThen` with no real explanation of what it is or what it does. Again, I can eventually infer the basics, but this interferes badly with understanding of the underlying concepts. If the OP really wanted to make this a better introduction, they really needed to slow down, use pseudo code with lots of explanations of the concept of "and then".
- jessaustin 11y ago
  ...immediate (apologetic) use of `andThen`... That is hilarious: note: the andThen method isn’t defined for functions of 0-arity, but we’re going to pretend that it is and that it works the same as it does for functions of one argument. Here's this thing that no one who doesn't already understand monads has ever seen, and that actually doesn't even work in this situation, but let's pretend it has some other definition that would work, if that were actually possible, which isn't the case. Why is everyone running, screaming, back to metaphor-based tutorials?
muaddirac 11y ago
I studied monads in a Categorical context in college (Domain Theory, if interested). Monads can be understood very simply in Category Theory if you don't care so much about the details: pick a couple of your favorite categories (which is just a bunch of objects with morphisms) and find a functor between them. Then find a functor back the other way. Composing those two functors gives a Monad - a functor from a category back into itself (an endofunctor). Not just any endofunctor will be a Monad though, so if you start with an endofunctor (instead of two functors) you need to also have two other "natural transformations". (That endofunctor + the two natural transformations is why monads are sometimes called triples). The application of monads to programming was not obvious to me, even having dealt with them a bit mathematically. I started looking at Haskell earlier this year and it turns out that a Monad in haskell is defined on the Hask category, where objects are types and morphisms are functions between them. Even that wasn't enough for me to get why they're useful, and that seems to be because as far as I can tell they're only used for "threading" state through a series of functions...but perhaps I'm still missing something?
- mindslight 11y ago
  > as far as I can tell they're only used for "threading" state through a series of functions That is why people bump up against them when learning Haskell, but monads run much deeper in functional programming.. Even "pure" functions in Haskell are monadic with respect to the non-terminating "bottom". I said it elsewhere in this topic, but check out Moggi's "Notions of computation and monads".

dkarapetyan 11y ago

Monads come from category theory. You can certainly know what they are without ever having programmed. "Basic Category Theory for Computer Scientists" and "Category Theory (Oxford Logic Guides)" are good places to start.

crimsonalucard 11y ago
Rightly so, but look at the replies to my post. Essentially nobody responded to my query. Looks like mostly Nobody knows what monads are without learning functional programming AND this article totally failed to help anyone understand what monads are.

olavk 11y ago

I don't believe monads are worth the bother without some syntactic sugar. Without sugar, it is just a sequence of operations converted into a chain of nested lambdas with one lambda for each operation. Cool, but far to convoluted to write for any real-world programs. The attempts to introduce monads in other languages like Python, Ruby etc. is missing what make them a useful tool in Haskell.

exDM69 11y ago
> The attempts to introduce monads in other languages like Python, Ruby etc. is missing what make them a useful tool in Haskell. While I agree that the syntactic sugar of the "do" notation in Haskell makes Monads vastly more useful, there are examples where Monads have been applied in other programming languages without any syntactic sugar. For example, there are parser combinator libraries (influenced by Parsec) in many languages. E.g. Python's pyparsec is internally using monads that are defined just as they are in Haskell. Monads are a great idea for many practical tasks in programming, their use in Haskell is often emphasized becuse they're required for IO (which is not the case for imperative languages). For many of the non-IO applications of monads, they're just as useful in other languages too.
tikhonj 11y ago
I've used Async and LWT in OCaml—libraries for monadic asynchronous programming—and the abstraction can still be useful without syntax sugar. Hell, JavaScript promises are basically a bastardized and slightly inconsistent monad, and they're still useful even without syntax sugar. If we could generalize over the API and use them for other things it would be even better, but that's not the JavaScript way.
- olavk 11y ago
  How are JS promises monads?
  - tikhonj 11y ago
    They actually operate on more or less the same principle as Async and LWT, similar to Haskell's Cont. The .then method is bind. Or it would be if they didn't automatically flatten nested promises. Since they do, then is a hybrid of map and bind that doesn't quite cover the use cases for both.

falcolas 11y ago

The problem with this article is it assumes you understand Scala. There's a lot of line noise going on there, which I was later able to infer as "this is Lambda notation". Following that is the immediate (apologetic) use of `andThen` with no real explanation of what it is or what it does. Again, I can eventually infer the basics, but this interferes badly with understanding of the underlying concepts. If the OP really wanted to make this a better introduction, they really needed to slow down, use pseudo code with lots of explanations of the concept of "and then".

jessaustin 11y ago
...immediate (apologetic) use of `andThen`... That is hilarious: note: the andThen method isn’t defined for functions of 0-arity, but we’re going to pretend that it is and that it works the same as it does for functions of one argument. Here's this thing that no one who doesn't already understand monads has ever seen, and that actually doesn't even work in this situation, but let's pretend it has some other definition that would work, if that were actually possible, which isn't the case. Why is everyone running, screaming, back to metaphor-based tutorials?

muaddirac 11y ago

I studied monads in a Categorical context in college (Domain Theory, if interested). Monads can be understood very simply in Category Theory if you don't care so much about the details: pick a couple of your favorite categories (which is just a bunch of objects with morphisms) and find a functor between them. Then find a functor back the other way. Composing those two functors gives a Monad - a functor from a category back into itself (an endofunctor). Not just any endofunctor will be a Monad though, so if you start with an endofunctor (instead of two functors) you need to also have two other "natural transformations". (That endofunctor + the two natural transformations is why monads are sometimes called triples). The application of monads to programming was not obvious to me, even having dealt with them a bit mathematically. I started looking at Haskell earlier this year and it turns out that a Monad in haskell is defined on the Hask category, where objects are types and morphisms are functions between them. Even that wasn't enough for me to get why they're useful, and that seems to be because as far as I can tell they're only used for "threading" state through a series of functions...but perhaps I'm still missing something?

mindslight 11y ago
> as far as I can tell they're only used for "threading" state through a series of functions That is why people bump up against them when learning Haskell, but monads run much deeper in functional programming.. Even "pure" functions in Haskell are monadic with respect to the non-terminating "bottom". I said it elsewhere in this topic, but check out Moggi's "Notions of computation and monads".