Live data from Hacker News

The Monad Challenges: Jump start your understanding of monads

mightybyte.github.io

11–20 of 51 posts

Re: The Monad Challenges: Jump start your understanding of monads

#11
post #7

I found a math background is a disadvantage for learning Haskell, since most mathematicians don't really use a lot of category theory. Lately that is changing, http://math.stackexchange.com/questions/1617592/is-set-prime... There's a lot of confusion on how the math version of "functor" or "monad" maps to the CS definitions. I found this tutorial on Monads and Applicatives helpful http://adit.io/posts/2013-04-17-func…

Something that doesn't help the Math->CS understanding of Functors is, for example, that languages like C++ use "Functor" to mean other things (function pointer in this case).

It's not though, in C++ a functor is generally something which defines the operator which lets you treat it as a callable. (a thing which acts like a function)

Though the suppose the dissonance in naming point still applies.

Re: The Monad Challenges: Jump start your understanding of monads

#12
post #7

I found a math background is a disadvantage for learning Haskell, since most mathematicians don't really use a lot of category theory. Lately that is changing, http://math.stackexchange.com/questions/1617592/is-set-prime... There's a lot of confusion on how the math version of "functor" or "monad" maps to the CS definitions. I found this tutorial on Monads and Applicatives helpful http://adit.io/posts/2013-04-17-func…

I don't quite understand the relevance of the stackexchange link. Are you just pointing out that some mathematicians sometimes discuss categories, with this as an arbitrary example? I don't think anyone doubted that.

Re: The Monad Challenges: Jump start your understanding of monads

#13
post #3

Cool tutorials. I think it's much more effective to start with learning functors and applicatives before monads. I'm surprised at the number of tutorials aimed at teaching people monads who don't yet understand the more basic type classes.

Coming at this from a mathematician's perspective, it's complete madness to learn what a monad is before learning what a natural transformation (and therefore a functor) is. I would also consider it somewhat eccentric to do monads without learning what an adjunction is, since adjunctions are basically why we're interested in monads in the first place.

Having been mildly disappointed by the simplicity of monoids, after intimidation from the complexity in maths, i expect that something like an adjunction is something already known to a commoner in any case, just that the vocabulary, particaularies and relations to the concept in question are not always obvious.

Re: The Monad Challenges: Jump start your understanding of monads

#14
post #7

I found a math background is a disadvantage for learning Haskell, since most mathematicians don't really use a lot of category theory. Lately that is changing, http://math.stackexchange.com/questions/1617592/is-set-prime... There's a lot of confusion on how the math version of "functor" or "monad" maps to the CS definitions. I found this tutorial on Monads and Applicatives helpful http://adit.io/posts/2013-04-17-func…

Something that doesn't help the Math->CS understanding of Functors is, for example, that languages like C++ use "Functor" to mean other things (function pointer in this case).

I'm curious to know which came first?

In any case it's annoying to have different languages adopting the same word to mean vaguely related but actually completely different things. I suspect that is why a lot of tutorials about Monads skip talking about Functors altogether which ends up making the whole thing more confusing.

Re: The Monad Challenges: Jump start your understanding of monads

#15
post #6
post #4

Earlier quoted context omitted.

Adjunctions aren't highly relevant to programming. Monads in programming have much less category theory than monads in math.

The significance of monads in programming is entirely because of the adjunction between the category of types and "pure" functions and the category of types and "monadic" functions (i.e., the Kleisli category of the monad). A monad is used to encode the latter in terms of the former via the Kleisli adjunction (whereby monadic maps from FX to FY correspond to pure maps from X to GFY, with the monad GF thus arising fro…

If you're going to talk like that, stay far, far away from anyone who is trying to learn monads.

I assert that most people coming to Haskell do so because "I hear Haskell and/or FP is cool, I'll try to learn it" rather than "Category theory is so cool, wouldn't it be awesome to program that way". What you said may be true, as the theoretical foundation for why monads are useful, but for someone trying to learn to program in Haskell, what you said is the last thing they need to learn about monads.

Re: The Monad Challenges: Jump start your understanding of monads

#16
Great. I was wondering if anyone is interested in writing a book or a blog titled something to the effect of "all the brutal concepts in the languages you want to learn or respect." For example, monads in Haskell, macros and continuations in Scheme...Maybe languages like C, Forth, Prolog, Smalltalk etc also have such arcane concepts that "scare" people??

Re: The Monad Challenges: Jump start your understanding of monads

#17
post #6

Earlier quoted context omitted.

The significance of monads in programming is entirely because of the adjunction between the category of types and "pure" functions and the category of types and "monadic" functions (i.e., the Kleisli category of the monad). A monad is used to encode the latter in terms of the former via the Kleisli adjunction (whereby monadic maps from FX to FY correspond to pure maps from X to GFY, with the monad GF thus arising fro…

If you're going to talk like that, stay far, far away from anyone who is trying to learn monads. I assert that most people coming to Haskell do so because "I hear Haskell and/or FP is cool, I'll try to learn it" rather than "Category theory is so cool, wouldn't it be awesome to program that way". What you said may be true, as the theoretical foundation for why monads are useful, but for someone trying to learn to pro…

That comment of mine wasn't the spiel I'd give to someone first trying to learn about the typical use of monads in a programming context, any more than I'd lecture a beginning programmer on the general theory of commutative rings while introducing integer and floating-point arithmetic (the latter not actually comprising a commutative ring...).

But teaching the use of monads to unfamiliar programmers wasn't my goal in that comment. I was just pointing out the accurate response to "Adjunctions aren't highly relevant to programming".

Re: The Monad Challenges: Jump start your understanding of monads

#18
post #14

Earlier quoted context omitted.

Something that doesn't help the Math->CS understanding of Functors is, for example, that languages like C++ use "Functor" to mean other things (function pointer in this case).

I'm curious to know which came first? In any case it's annoying to have different languages adopting the same word to mean vaguely related but actually completely different things. I suspect that is why a lot of tutorials about Monads skip talking about Functors altogether which ends up making the whole thing more confusing.

> I'm curious to know which came first?

The math definitions. These were invented by Saunders Mac Lane and Samuel Eilenberg back in 1945ish, about a year before ENIAC was built.

Re: The Monad Challenges: Jump start your understanding of monads

#19
post #6
post #4

Earlier quoted context omitted.

Adjunctions aren't highly relevant to programming. Monads in programming have much less category theory than monads in math.

The significance of monads in programming is entirely because of the adjunction between the category of types and "pure" functions and the category of types and "monadic" functions (i.e., the Kleisli category of the monad). A monad is used to encode the latter in terms of the former via the Kleisli adjunction (whereby monadic maps from FX to FY correspond to pure maps from X to GFY, with the monad GF thus arising fro…

I'm not very familiar with category theory and can't really make heads or tails of what you're writing there, but I think the idea behind the statement that "adjunctions aren't highly relevant in programming" is to say that there isn't a huge amount of immediate utility of adjunctions as a programmer. On the other hand, programmers use monads all the time (even if they don't realize it, which is the most common case, as the monad in question is the evaluation of the imperative language they're writing in). Of course, to be honest, I wouldn't know an adjunction from a hole in the ground, so perhaps the same is true for adjunctions -- but I've never heard of them so I'm assuming that's not the case. Either way, what makes monads worth understanding is precisely how useful they are in day-to-day, real-world programming, and in particular understanding how they're used in Haskell is practically essential for understanding almost any extant Haskell code.

Re: The Monad Challenges: Jump start your understanding of monads

#20

Great. I was wondering if anyone is interested in writing a book or a blog titled something to the effect of "all the brutal concepts in the languages you want to learn or respect." For example, monads in Haskell, macros and continuations in Scheme...Maybe languages like C, Forth, Prolog, Smalltalk etc also have such arcane concepts that "scare" people??

I don't know about scaring people, but many programming languages have concepts that are best demonstrated with small examples that make people say "whoa".

For example, it's amazing that append() in Prolog can be run "backwards" from the concatenated result to yield all the lists that can be concatenated to produce it. Or that the monadic bind operator in Haskell (>>=) can be defined in terms of join and fmap, or that ($) = id.

Programming languages have idiomatic expressions, and learning why they do what they do can produce enlightenment. It's no accident that C supports syntax like 3["hello"]. It looks mysterious, but not when you know that x[y] == *((x)+(y)) by definition. APL was especially rich in idiomatic expressions; I suppose that it's a sign of having easily composed primitives.

Post reply on HN