6 ms·

To me, it is because the term 'a monad' refers to a thing that doesn't even exist as its own thing in programming. Of course your can realize a monad, but the m

To me, it is because the term 'a monad' refers to a thing that doesn't even exist as its own thing in programming. Of course your can realize a monad, but the monad is not the type, nor the function, but the abstract, mathematical "thing" that defines a type and the two operations (value wrapping, and the compose function). Programmers without a mathematical background will naturally struggle with such concepts. You can't point to where in the the code "the monad" is, as it's just the pattern, or the abstract mathematical combination of the type and the operations. Sure you could pack them into a class or a module, but it's still hard to point to where "the monad" is. When we describe other patterns, like a Singleton, Factory, an Adapter, etc., it's is much more clear what and where the thing is. It's just a word to describe a function, a class, or a module. Perhaps 'function composition with metainformation' would be a better title for the pattern. You take composable functions that act on certain types, and extend them to support metainformation attached to the values, while defining how the metainformation combines.

IshKebab 4y ago
Yeah, I haven't done any Haskell but from what I understand "a monad" is just a type that lets you call `.map()` on it and do the normal thing that `map()` does. Would it be wrong to call it `mappable`? That would be a much clearer name.
- tel 4y ago
  It's not that. The thing you're describing is often called a "functor". It could be called a "mappable" but generally once you've heard a functor is a thing that has a .map() function that works the way you expect it to then you don't really need to call it a mappable anymore. So the name sticks. Even to just be able to rapidly identify why having a thing that .map()s is a meaningful object represents the sort of experience with and abstraction of these concepts that'll put you ahead of the game for understanding monads.
  - IshKebab 4y ago
    Oh yeah I mixed them up. I still think `Mappable` is a much better name than `Functor`, and names matter. Especially for difficult to understand concepts. Functor isn't really even the right type of word. It should be Functable or something. Monad should be `FlatMappable`. I found this great article where they use exactly these terms to explain it: https://dev.to/joelnet/functional-javascript---functors-monads-and-promises-1pol https://dev.to/joelnet/functional-javascript---functors-mona... If people are using different terms to explain your confusing terminology then... maybe the confusing terminology is not very good.
    - nybble41 4y ago
      "Functor" is a perfectly good and descriptive name… provided you are at least somewhat familiar with the esoteric branch of mathematics it's based on. For someone from a Category Theory background renaming it to "Mappable" would be weird and unintuitive. And as in most things, those actually doing the work get to pick the names that make sense to them.
      - codebje 4y ago
        If you're not even slightly familiar with that branch of mathematics it's still a perfectly good and descriptive name, because you can search for the term and get loads of relevant information from the programming side of things. (The mathematical basis helping you get deeper insights into it is just a bonus, albeit IMO a valuable one.)
    - codebje 4y ago
      Names certainly do matter: they're how we effectively communicate with each other. If you call it a mappable, and someone else calls it a chainable (as was said elsewhere in this comment thread), how have we eased confusion? If I try to google what a chainable is, what will I find? On the other hand, if I say "it's a monad" then people who have encountered the term before know what I mean (even if they've had no need to understand monads in depth) and people who have not will successfully find information about the right thing if they search for it. Monads have a particularly bad reputation for being hard to learn, despite appearing in non-general form in every modern language. Since people seem to have little trouble grasping the way in which futures, streams, and options work I don't think there's really such a great challenge involved - but the culture of running screaming from the mere word doesn't help matters in the least.
- schwurb 4y ago
  What you are describing is a Functor, one the two other important Haskell "design-patterns" (Functor - Applicative - Monad). "Mappable" is a good name insofar as it is more familiar to new folks. However, I like the mathematical name as it forces one to embrace the interface as what it is, as opposed to thinking about Functors as collection of data that can be mapped over. Often this is true, but not always. A monad could be described as "sequencable/chainable", but that metaphor is quickly breaking down as there as so many ways in which monads show up.
  - nybble41 4y ago
    > one the two other important Haskell "design-patterns" (Functor - Applicative - Monad) These days you should probably add Foldable and Traversable to that list, as they are closely related and appear throughout the standard libraries and even in the Prelude. Traversable is a generalization of Functor to include Applicative effects. It reduces to Functor if the Applicative happens to be the Identity type. Where Functor and Traversable replace values one-to-one while preserving structure, Foldable represents reducing operations (folds) which consume the values from a structure in some defined order to build up a result. This includes basic functions like sums and products, as well as more complex operations like `sequence`.
  - IshKebab 4y ago
    > A monad could be described as "sequencable/chainable", but that metaphor is quickly breaking down as there as so many ways in which monads show up. Hmm well it might break down but simply by choosing a better word you've helped me understand what a monad is more than any article I've read on the matter.
chongli 4y ago
This is a pretty good explanation but it's missing one detail: the laws. A monad is an applicative functor which is a functor. Each of these concepts in the hierarchy comes with a set of laws which must be obeyed. For example, all functors (which define an operation, fmap) must obey 2 laws: Identity fmap id == id Composition fmap (f . g) == fmap f . fmap g All instances of Functor must obey these laws. Furthermore, since every Monad is also a Functor, all instances of Monad also obey these laws (in addition to extra laws).
renox 4y ago
I disagree: there are often different ways to implement a design pattern, so IMHO a design pattern is an abstract idea in the same way monads are. The main difference is that design patterns have 'fuzzy' rules whereas monads are more precisely defined.

IshKebab 4y ago

Yeah, I haven't done any Haskell but from what I understand "a monad" is just a type that lets you call `.map()` on it and do the normal thing that `map()` does. Would it be wrong to call it `mappable`? That would be a much clearer name.

tel 4y ago
It's not that. The thing you're describing is often called a "functor". It could be called a "mappable" but generally once you've heard a functor is a thing that has a .map() function that works the way you expect it to then you don't really need to call it a mappable anymore. So the name sticks. Even to just be able to rapidly identify why having a thing that .map()s is a meaningful object represents the sort of experience with and abstraction of these concepts that'll put you ahead of the game for understanding monads.
- IshKebab 4y ago
  Oh yeah I mixed them up. I still think `Mappable` is a much better name than `Functor`, and names matter. Especially for difficult to understand concepts. Functor isn't really even the right type of word. It should be Functable or something. Monad should be `FlatMappable`. I found this great article where they use exactly these terms to explain it: https://dev.to/joelnet/functional-javascript---functors-monads-and-promises-1pol https://dev.to/joelnet/functional-javascript---functors-mona... If people are using different terms to explain your confusing terminology then... maybe the confusing terminology is not very good.
  - nybble41 4y ago
    "Functor" is a perfectly good and descriptive name… provided you are at least somewhat familiar with the esoteric branch of mathematics it's based on. For someone from a Category Theory background renaming it to "Mappable" would be weird and unintuitive. And as in most things, those actually doing the work get to pick the names that make sense to them.
    - codebje 4y ago
      If you're not even slightly familiar with that branch of mathematics it's still a perfectly good and descriptive name, because you can search for the term and get loads of relevant information from the programming side of things. (The mathematical basis helping you get deeper insights into it is just a bonus, albeit IMO a valuable one.)
  - codebje 4y ago
    Names certainly do matter: they're how we effectively communicate with each other. If you call it a mappable, and someone else calls it a chainable (as was said elsewhere in this comment thread), how have we eased confusion? If I try to google what a chainable is, what will I find? On the other hand, if I say "it's a monad" then people who have encountered the term before know what I mean (even if they've had no need to understand monads in depth) and people who have not will successfully find information about the right thing if they search for it. Monads have a particularly bad reputation for being hard to learn, despite appearing in non-general form in every modern language. Since people seem to have little trouble grasping the way in which futures, streams, and options work I don't think there's really such a great challenge involved - but the culture of running screaming from the mere word doesn't help matters in the least.
schwurb 4y ago
What you are describing is a Functor, one the two other important Haskell "design-patterns" (Functor - Applicative - Monad). "Mappable" is a good name insofar as it is more familiar to new folks. However, I like the mathematical name as it forces one to embrace the interface as what it is, as opposed to thinking about Functors as collection of data that can be mapped over. Often this is true, but not always. A monad could be described as "sequencable/chainable", but that metaphor is quickly breaking down as there as so many ways in which monads show up.
- nybble41 4y ago
  > one the two other important Haskell "design-patterns" (Functor - Applicative - Monad) These days you should probably add Foldable and Traversable to that list, as they are closely related and appear throughout the standard libraries and even in the Prelude. Traversable is a generalization of Functor to include Applicative effects. It reduces to Functor if the Applicative happens to be the Identity type. Where Functor and Traversable replace values one-to-one while preserving structure, Foldable represents reducing operations (folds) which consume the values from a structure in some defined order to build up a result. This includes basic functions like sums and products, as well as more complex operations like `sequence`.
- IshKebab 4y ago
  > A monad could be described as "sequencable/chainable", but that metaphor is quickly breaking down as there as so many ways in which monads show up. Hmm well it might break down but simply by choosing a better word you've helped me understand what a monad is more than any article I've read on the matter.

chongli 4y ago

This is a pretty good explanation but it's missing one detail: the laws. A monad is an applicative functor which is a functor. Each of these concepts in the hierarchy comes with a set of laws which must be obeyed. For example, all functors (which define an operation, fmap) must obey 2 laws: Identity fmap id == id Composition fmap (f . g) == fmap f . fmap g All instances of Functor must obey these laws. Furthermore, since every Monad is also a Functor, all instances of Monad also obey these laws (in addition to extra laws).

renox 4y ago

I disagree: there are often different ways to implement a design pattern, so IMHO a design pattern is an abstract idea in the same way monads are. The main difference is that design patterns have 'fuzzy' rules whereas monads are more precisely defined.