7 ms·

If you're looking to understand what Monads are or why they're interesting this isn't the place to figure that out. Monad: if you have a data structure that wr

If you're looking to understand what Monads are or why they're interesting this isn't the place to figure that out. Monad: if you have a data structure that wraps some value of any type, then you also have to implement the interface that provides `return` and `bind` (there's talk about requiring another method, `join` but I digress). The data structure is the "context" and the interface is how you compose values from other Monads together using functions. If you can prove your implementation of the interface methods follow certain rules then you have a Monad. Why is this pattern/abstraction/interface useful in Haskell? I think there are several reasons. The article touches one of the most talked about: sequencing. Because of the way the rules of the Monad interface are structured you're guaranteed that the functions you use to compose your Monads together will be executed in sequence with respect to their definition in your function body. (How it all ties together is straight-forward but requires a certain pedagogy and exposition to follow that I won't get into.) This is, consequently, what makes Haskell the best imperative language in the world. Not only do you get to use it's wonderful type system but you can compose together small imperative programs into bigger, more useful ones.

fooker 8y ago
>Not only do you get to use it's wonderful type system but you can compose together small imperative programs into bigger, more useful ones. These bigger, more useful programs you can write with Haskell are pretty much unreadable though. There is a reason everyone is not jumping into the functional programming bandwagon, despite mature languages being available for 30+ years.
- jaggederest 8y ago
  I wrote a fairly reasonable toy raytracer in it and I found it very readable. The hard part was that the type system doesn't help you get your algorithms to spit out the correct answer, only the correct kind of answer. After a while I find that errors of that sort dominate the kind of things the type system helps with. And I'm sure there are type-system-ways-to-solve-that-problem but they're nonobvious and would probably render the rest of the program more confusing. Certainly adding in error handling and state did, compared to working strictly in the IO monad.
  - svachalek 8y ago
    Everyone thinks their own code is readable. It's when you jump into a project with code written by 10 other people that you get an idea for a language's innate readability. In my experience I tend to agree that Haskell does not score high on this dimension, its syntax is too terse and too flexible and there are few conventions about how to organize large codebases.
    - jaggederest 8y ago
      Well, to clarify, I found the code in the libraries etc very readable, obviously I can read my own code :)
      - fooker 8y ago
        A significant number of interesting Haskell libraries I found are thin abstractions over some C api. It makes sense that these would be readable. Is there something for Haskell which serve a similar role as boost to C++? If that is readable, I will be convinced.
    - squiggleblaz 8y ago
      I actually disagree. I write very little Haskell but I do read it from time to time, simply because compared to any other language it's simply so readable it's almost fun. In no other language have I ever got distracted from my main goal by just reading the source code of the libraries I'm using.
- marcosdumay 8y ago
  While programming, I end up reading the source of most badly documented packages on Hackage that have some interface that looks like what I'm doing. Nearly all that mostly low quality (correlates pretty well with lack of documentation) code is perfectly legible (although some have other problems). I have never seen any language get near Haskell on the legibility of random code on the internet.
  - skgoa 8y ago
    I have found that Java enforces a higher floor of readability than most languages, simply because you have to type out so much "boilerplate" for everything. Though even that does not come close to Haskell. Ironically, the introduction of lambdas made bad Java code using them far less readable.
    - marcosdumay 8y ago
      Yes. On my eyes Java was always the clear choice for enterprise code, because people come and go, and one bad apple does not destroy the entire code base on Java. After I learned Haskell I had a "I knew nothing!" moment. Anybody writing enterprise code on anything that is not as safe as Haskell (that is, basically everybody) is letting a lot of money on the table.
- thinkpad20 8y ago
  > These bigger, more useful programs you can write with Haskell are pretty much unreadable though. This seems somewhat baseless. Unreadable according to whom? There are many large and complex programs written in Haskell by large teams of developers (open source or otherwise). It’s the nature of software in any language to become difficult to manage as the code base becomes large; I don’t think Haskell is an exceptional offender in this category. > There is a reason everyone is not jumping into the functional programming bandwagon, despite mature languages being available for 30+ years. There certainly are reasons for that, but not the ones you laid out.
  - fooker 8y ago
    >There are many large and complex programs written in Haskell by large teams of developers (open source or otherwise). How many of those projects regularly attract new contributors, vs ..say.. something written in python or C++?
- Koshkin 8y ago
  > pretty much unreadable The last readable programming language was Algol 60.
stcredzero 8y ago
Monad: if you have a data structure that wraps some value of any type, then you also have to implement the interface that provides `return` and `bind` So it's a wrapper that implements a particular interface? Then why, oh why, do we have so many people who spout, "A monad is just a monoid in the category of endofunctors, what's the problem?" Gilad Bracha covered this in a talk once. Because of the way the rules of the Monad interface are structured you're guaranteed that the functions you use to compose your Monads together will be executed in sequence with respect to their definition in your function body. So it's a way of imperatively declaring execution sequence dependencies that lets you reason as if there's only pure functions most of the time. This seems to be the case for all functional programming languages/environments. When you get down to it, they're all, in the words of Garrison Keillor, "Pure, mostly."
- bitwize 8y ago
  > Then why, oh why, do we have so many people who spout, "A monad is just a monoid in the category of endofunctors, what's the problem?" It's a joke/dank maymay that Haskells still find funny long after it's pissed everyone else off. The idea is that since category theory is described as "generalized abstract nonsense" by its practitioners, describing monads in terms of their strict category-theoretical definition helps no one, especially those new to Haskell. The problem is that unless your audience is steeped in category theory, they can't appreciate the irony of the situation and you just come off sounding like a dick.
  - stcredzero 8y ago
    The problem is that unless your audience is steeped in category theory, they can't appreciate the irony of the situation Who needs mindshare, when you can have in-jokes instead? Better to be the one everyone initially laughs at, but wind up with all the mindshare, than to be the one doing all the laughing who gets left behind.
    - derefr 8y ago
      It's not quite an in-joke. It's in-gallows humour: something common to all transmission of hard-to-communicate knowledge. Anyone on the far side of a gulf of enlightenment—and understanding monads is an enlightenment, if a small one—knows that it's effectively impossible to actually communicate the particular thing they learned that helped them achieve enlightenment. (Well, it's not impossible to communicate what they learned; it's just that that's roughly useless to anyone else. An enlightenment is a realization that culminates only from all of a set of micro-skills being attained; and each person is missing different micro-skills to start with. You can look back and see the micro-skills you learned, and teach those, but you have no idea what micro-skills you started off already in possession of that others did not—what micro-skills you take for granted—and so you cannot teach those.) When faced with someone starting on the path to an enlightenment, who asks you to simply summarize the path for them, there's no way to actually usefully tell them. But it's kind of rude to just say nothing—and on a forum like this, equally rude to assume a role of a master verbally lashing an apprentice (ala a Zen parable) for assuming they could understand the concept without working their brain up through all the micro-skills it was missing first. So, what you do instead is, you make a joke. A joke that seems opaque at the time, but which the learner, having journeyed further down the path, will realize was the truth they sought, and exactly what they asked for—it was just a truth that was, necessarily, completely useless to them at the time. Any such truth would be. You don't make the joke to be snarky. You make the joke because you wish that, this time, it would work, and the learner would skip the path and achieve the enlightenment; that you could just reach across the gulf and bring them over. But you know it won't. The punchline of the "joke" is not played on the learner, but on the teacher: it is that the world is cruel and to teach skills that require enlightenments is to suffer knowing your students lay across this gulf, and most of what you say will miss them entirely because of the mismatch in micro-skill acquisition between you. (Though, I suppose, when the learner attempts to teach the concept themselves, and realizes the only thing they want to say is the same useless thing that was said to them—this would be the joke "paying off." That pay-off makes it sort of like a traditional joke, in the sense that choosing to "tell" it rather than simply thinking it to oneself is choosing to set the learner up for that later pay-off.)
foldr 8y ago
>Because of the way the rules of the Monad interface are structured you're guaranteed that the functions you use to compose your Monads together will be executed in sequence with respect to their definition in your function body. No! Monads don't guarantee sequencing. Some particular monad instances do (e.g. IO). But there's nothing inherently sequential about monads. See e.g. point 10 of the following: https://wiki.haskell.org/What_a_Monad_is_not https://wiki.haskell.org/What_a_Monad_is_not
- agentultra 8y ago
  I knew I was going to get something about it wrong. Thanks for the clarification. It’s just one aspect that gets focused on because... IO and that's what the article focuses on. I got wrapped up in it too.
- theaeolist 8y ago
  The page on "What a Monad is not" has numerous inaccuracies. I wouldn't take it too seriously.
  - foldr 8y ago
    What inaccuracies are there in section 10?

fooker 8y ago

>Not only do you get to use it's wonderful type system but you can compose together small imperative programs into bigger, more useful ones. These bigger, more useful programs you can write with Haskell are pretty much unreadable though. There is a reason everyone is not jumping into the functional programming bandwagon, despite mature languages being available for 30+ years.

jaggederest 8y ago
I wrote a fairly reasonable toy raytracer in it and I found it very readable. The hard part was that the type system doesn't help you get your algorithms to spit out the correct answer, only the correct kind of answer. After a while I find that errors of that sort dominate the kind of things the type system helps with. And I'm sure there are type-system-ways-to-solve-that-problem but they're nonobvious and would probably render the rest of the program more confusing. Certainly adding in error handling and state did, compared to working strictly in the IO monad.
- svachalek 8y ago
  Everyone thinks their own code is readable. It's when you jump into a project with code written by 10 other people that you get an idea for a language's innate readability. In my experience I tend to agree that Haskell does not score high on this dimension, its syntax is too terse and too flexible and there are few conventions about how to organize large codebases.
  - jaggederest 8y ago
    Well, to clarify, I found the code in the libraries etc very readable, obviously I can read my own code :)
    - fooker 8y ago
      A significant number of interesting Haskell libraries I found are thin abstractions over some C api. It makes sense that these would be readable. Is there something for Haskell which serve a similar role as boost to C++? If that is readable, I will be convinced.
  - squiggleblaz 8y ago
    I actually disagree. I write very little Haskell but I do read it from time to time, simply because compared to any other language it's simply so readable it's almost fun. In no other language have I ever got distracted from my main goal by just reading the source code of the libraries I'm using.
marcosdumay 8y ago
While programming, I end up reading the source of most badly documented packages on Hackage that have some interface that looks like what I'm doing. Nearly all that mostly low quality (correlates pretty well with lack of documentation) code is perfectly legible (although some have other problems). I have never seen any language get near Haskell on the legibility of random code on the internet.
- skgoa 8y ago
  I have found that Java enforces a higher floor of readability than most languages, simply because you have to type out so much "boilerplate" for everything. Though even that does not come close to Haskell. Ironically, the introduction of lambdas made bad Java code using them far less readable.
  - marcosdumay 8y ago
    Yes. On my eyes Java was always the clear choice for enterprise code, because people come and go, and one bad apple does not destroy the entire code base on Java. After I learned Haskell I had a "I knew nothing!" moment. Anybody writing enterprise code on anything that is not as safe as Haskell (that is, basically everybody) is letting a lot of money on the table.
thinkpad20 8y ago
> These bigger, more useful programs you can write with Haskell are pretty much unreadable though. This seems somewhat baseless. Unreadable according to whom? There are many large and complex programs written in Haskell by large teams of developers (open source or otherwise). It’s the nature of software in any language to become difficult to manage as the code base becomes large; I don’t think Haskell is an exceptional offender in this category. > There is a reason everyone is not jumping into the functional programming bandwagon, despite mature languages being available for 30+ years. There certainly are reasons for that, but not the ones you laid out.
- fooker 8y ago
  >There are many large and complex programs written in Haskell by large teams of developers (open source or otherwise). How many of those projects regularly attract new contributors, vs ..say.. something written in python or C++?
Koshkin 8y ago
> pretty much unreadable The last readable programming language was Algol 60.

stcredzero 8y ago

Monad: if you have a data structure that wraps some value of any type, then you also have to implement the interface that provides `return` and `bind` So it's a wrapper that implements a particular interface? Then why, oh why, do we have so many people who spout, "A monad is just a monoid in the category of endofunctors, what's the problem?" Gilad Bracha covered this in a talk once. Because of the way the rules of the Monad interface are structured you're guaranteed that the functions you use to compose your Monads together will be executed in sequence with respect to their definition in your function body. So it's a way of imperatively declaring execution sequence dependencies that lets you reason as if there's only pure functions most of the time. This seems to be the case for all functional programming languages/environments. When you get down to it, they're all, in the words of Garrison Keillor, "Pure, mostly."

bitwize 8y ago
> Then why, oh why, do we have so many people who spout, "A monad is just a monoid in the category of endofunctors, what's the problem?" It's a joke/dank maymay that Haskells still find funny long after it's pissed everyone else off. The idea is that since category theory is described as "generalized abstract nonsense" by its practitioners, describing monads in terms of their strict category-theoretical definition helps no one, especially those new to Haskell. The problem is that unless your audience is steeped in category theory, they can't appreciate the irony of the situation and you just come off sounding like a dick.
- stcredzero 8y ago
  The problem is that unless your audience is steeped in category theory, they can't appreciate the irony of the situation Who needs mindshare, when you can have in-jokes instead? Better to be the one everyone initially laughs at, but wind up with all the mindshare, than to be the one doing all the laughing who gets left behind.
  - derefr 8y ago
    It's not quite an in-joke. It's in-gallows humour: something common to all transmission of hard-to-communicate knowledge. Anyone on the far side of a gulf of enlightenment—and understanding monads is an enlightenment, if a small one—knows that it's effectively impossible to actually communicate the particular thing they learned that helped them achieve enlightenment. (Well, it's not impossible to communicate what they learned; it's just that that's roughly useless to anyone else. An enlightenment is a realization that culminates only from all of a set of micro-skills being attained; and each person is missing different micro-skills to start with. You can look back and see the micro-skills you learned, and teach those, but you have no idea what micro-skills you started off already in possession of that others did not—what micro-skills you take for granted—and so you cannot teach those.) When faced with someone starting on the path to an enlightenment, who asks you to simply summarize the path for them, there's no way to actually usefully tell them. But it's kind of rude to just say nothing—and on a forum like this, equally rude to assume a role of a master verbally lashing an apprentice (ala a Zen parable) for assuming they could understand the concept without working their brain up through all the micro-skills it was missing first. So, what you do instead is, you make a joke. A joke that seems opaque at the time, but which the learner, having journeyed further down the path, will realize was the truth they sought, and exactly what they asked for—it was just a truth that was, necessarily, completely useless to them at the time. Any such truth would be. You don't make the joke to be snarky. You make the joke because you wish that, this time, it would work, and the learner would skip the path and achieve the enlightenment; that you could just reach across the gulf and bring them over. But you know it won't. The punchline of the "joke" is not played on the learner, but on the teacher: it is that the world is cruel and to teach skills that require enlightenments is to suffer knowing your students lay across this gulf, and most of what you say will miss them entirely because of the mismatch in micro-skill acquisition between you. (Though, I suppose, when the learner attempts to teach the concept themselves, and realizes the only thing they want to say is the same useless thing that was said to them—this would be the joke "paying off." That pay-off makes it sort of like a traditional joke, in the sense that choosing to "tell" it rather than simply thinking it to oneself is choosing to set the learner up for that later pay-off.)

foldr 8y ago

>Because of the way the rules of the Monad interface are structured you're guaranteed that the functions you use to compose your Monads together will be executed in sequence with respect to their definition in your function body. No! Monads don't guarantee sequencing. Some particular monad instances do (e.g. IO). But there's nothing inherently sequential about monads. See e.g. point 10 of the following: https://wiki.haskell.org/What_a_Monad_is_not https://wiki.haskell.org/What_a_Monad_is_not

agentultra 8y ago
I knew I was going to get something about it wrong. Thanks for the clarification. It’s just one aspect that gets focused on because... IO and that's what the article focuses on. I got wrapped up in it too.
theaeolist 8y ago
The page on "What a Monad is not" has numerous inaccuracies. I wouldn't take it too seriously.
- foldr 8y ago
  What inaccuracies are there in section 10?