21–30 of 48 posts
Anytime I see Monads or Monoids in the title I am obligated to share one of the greatest YouTube videos of all time :) https://www.youtube.com/watch?v=ADqLBc1vFwI
Anytime I see Monads or Monoids in the title I am obligated to share one of the greatest YouTube videos of all time :) https://www.youtube.com/watch?v=ADqLBc1vFwI
Not sure why the article has to mention monads? I mean there’s the (mathematically correct) joke that »monads are monoids in the category of endofunctors«, but understanding that requires getting elbow deep into category theory, and if you’re not one of the maybe 10 people in the world gifted that way has zero practical use when programming. > A monad is a monoid over a set of curried functions. Is that so? Sounds ve…
I found it useful to have them mentioned, since people new to this topic (or, e.g., Haskell) tend to bump onto monoids when they first try to understand monads. A 'handwavy' association that somewhat makes sense and allows you to have some sort of perspective when moving on to monads is better than simply omitting the link to monads completely, just because one can "kindof maybe" find holes in the simplified explanat…
That's unfortunate. They should be bumping onto monoids much earlier, and much more often.
Yeah, IO and do notation put monads on the face of people way before they have time to adapt to it. But monoids are the one that are extremely valuable, simple, and easy to learn. Also, they make for a nice step in a progressive adaptation to the "generalized thinking" one need to understand why Haskell does the things it does.
Not sure why the article has to mention monads? I mean there’s the (mathematically correct) joke that »monads are monoids in the category of endofunctors«, but understanding that requires getting elbow deep into category theory, and if you’re not one of the maybe 10 people in the world gifted that way has zero practical use when programming. > A monad is a monoid over a set of curried functions. Is that so? Sounds ve…
I found it useful to have them mentioned, since people new to this topic (or, e.g., Haskell) tend to bump onto monoids when they first try to understand monads. A 'handwavy' association that somewhat makes sense and allows you to have some sort of perspective when moving on to monads is better than simply omitting the link to monads completely, just because one can "kindof maybe" find holes in the simplified explanat…
Would it help if you defined a monoid as a combination of 3 things?
1) a data type A
2) an associative operation on A
3) an identity (or empty element)
Then you can correctly say that the string data type, admits an associative operation (concatenation of two strings) and you have an empty element (the empty string).
I think too many people talking about functional programming really overblow how much you need to understand about mathematics, they serious do.
Think about my definition and you can quickly understand that there are many monoid instances for numbers (with the associative operation being addition to get a monoid or multiplication to get another monoid instance).
There's infinite numbers of monoid instances for various data types.
Haskell has several shortcomings from what I remember and Haskell developers incorrectly assume that you can only have one semi group (or equality, monoid, etc) instances for your data type because they believe they are the closest to math, but in reality their language has its own limitations.
> A monad is a monoid over a set of curried functions I think this statement will have two kinds of readers. People who are not familiar with monads, for whom it'll fly right over their heads, and people who are familiar with monads, who will be annoyed at its inaccuracy.
> If I haven’t used fold-left or fold-right in a while, I sometimes forget which one computes what. I'm glad I'm not the only one struggling with this! Though I have started remembering it a different way: I pretend the 'r' in 'foldr' stands for recursive. Thus it's easier to remember that foldr(º, [a, b, ...]) ~= a º (b º ...) where the right term for each operator is given by the recursive call. In contrast, then,…
Earlier quoted context omitted.
I found it useful to have them mentioned, since people new to this topic (or, e.g., Haskell) tend to bump onto monoids when they first try to understand monads. A 'handwavy' association that somewhat makes sense and allows you to have some sort of perspective when moving on to monads is better than simply omitting the link to monads completely, just because one can "kindof maybe" find holes in the simplified explanat…
It's kind of natural that you need to progress from a magma/semi group monoid (algebra) to functors/applicative/monad (category theory) Would it help if you defined a monoid as a combination of 3 things? 1) a data type A 2) an associative operation on A 3) an identity (or empty element) Then you can correctly say that the string data type, admits an associative operation (concatenation of two strings) and you have an…
They don't assume that. The devs bent the compiler backwards several times trying to support more than one instance, but they still couldn't design an implementation that is actually good to use.
If you know of any language where this works well, it would be nice to know. AFAIK, representing that kind of thing is an open problem, nobody has an answer.
> A monad is a monoid over a set of curried functions I think this statement will have two kinds of readers. People who are not familiar with monads, for whom it'll fly right over their heads, and people who are familiar with monads, who will be annoyed at its inaccuracy.
But in between those two extremes, the curious. I know enough to be intrigued but not to critique. Hoping for some insight here.
It's best to not learn from wrong things, which is, unfortunately, statistically most of the things talking about monads.
Earlier quoted context omitted.
It's kind of natural that you need to progress from a magma/semi group monoid (algebra) to functors/applicative/monad (category theory) Would it help if you defined a monoid as a combination of 3 things? 1) a data type A 2) an associative operation on A 3) an identity (or empty element) Then you can correctly say that the string data type, admits an associative operation (concatenation of two strings) and you have an…
> Haskell developers incorrectly assume that you can only have one semi group (or equality, monoid, etc) instances for your data type They don't assume that. The devs bent the compiler backwards several times trying to support more than one instance, but they still couldn't design an implementation that is actually good to use. If you know of any language where this works well, it would be nice to know. AFAIK, repres…
Anytime I see Monads or Monoids in the title I am obligated to share one of the greatest YouTube videos of all time :) https://www.youtube.com/watch?v=ADqLBc1vFwI