monads are the MCP of functional programming—no one really knows what they are but everyone writes an article about them using analogies that break when you actually use them in practice.
What is MCP?
Functors, Applicatives, and Monads
21–30 of 90 posts
Re: Functors, Applicatives, and Monads
#22Unfortunately, while you may not have appreciated the tone of the Haskell interaction, they are correct in their assessment from a factual perspective. This explanation propagates a number of misunderstandings of the topics well known to be endemic to beginners. In particular, I observed the common belief that functors apply to "containers", when in fact they apply to things that are not containers as well, most nota…
Functions are just containers of calculations (the whole “code is data”).
I don’t know why lists as values in a container would be confusing. Lots of very popular languages literally have box types which may not be exactly the same, but show that expecting containers to potentially commission complex data isn’t unusual.
Re: Functors, Applicatives, and Monads
#23monads are the MCP of functional programming—no one really knows what they are but everyone writes an article about them using analogies that break when you actually use them in practice.
What is MCP?
Model Context Protocol. It is a way to give an LLM access to an API. There's a lot of hype about it right now, and, thus, a great many half-baked articles floating around. https://www.anthropic.com/news/model-context-protocol
Re: Functors, Applicatives, and Monads
#24Earlier quoted context omitted.
A list [b] is a container for bs indexed by integers. A function a->b is a container for bs indexed by as.
> A function a->b is a container for bs Anecdotally, this is one of those things that's trivially true to some people, but really hard for other people to internalize. I think it's why the "container" can lead people astray- if you haven't internalized the idea of functions as being indexed by their argument, it's a really mind twisting thing to try to make that leap.
I can recommend learnung some scala, where HashMap extends PartialFunction
Re: Functors, Applicatives, and Monads
#25I feel like Haskell is easier to use than it is to explain, and in my experience a lot of these kind of tutorial / explanations actually make things seem harder and more complicated than just working with the concepts and observing what they do. (This one included.)
Every “hard” concepts I’ve seen in Haskell is immediately clear to me if explained in almost any other language. The hard part is Haskell, not the concept.
Usually I’m left wondering why whatever-it-is even has a name, it’s so simple and obvious and also not that special or useful seeming, it’d never have occurred to me to name it. I guess the people giving them names are coming at them from a very different perspective.
Exception: type classes. Those are nice and do need a name.
Re: Functors, Applicatives, and Monads
#26monads are the MCP of functional programming—no one really knows what they are but everyone writes an article about them using analogies that break when you actually use them in practice.
Nah. Lots of people know what monads are. And critically, they don't write monad explainers.
This is because if you understand the fundamentals well enough to understand an explanation, monads are so trivially straightforward that the definition is 100% of the explanation you need. Learn about how Haskell denotes types. Learn about higher-order functions, higher-kinded types, parametric polymorphism, and bounded polymorphism. Once you are comfortable with what all of those do in Haskell, Monad is a way to bound polymorphism with a couple extra expectations about how things behave. It takes about 5 minutes to explain and show a bunch of examples.
But before you're comfortable with those parts, it's like trying to explain exponentiation to someone who doesn't understand addition. People who understand exponentiation don't do that. They don't try to use analogies. They say "you need to learn about addition first, then multiplication. You can learn about exponentiation after that."
Re: Functors, Applicatives, and Monads
#27Part of why monads are not interesting to talk about is that they’re generic enough that most explanations are incomplete, and sufficient explanations are boring and unhelpful.
But the biggest reason is that they’re sort of intuitive, plenty examples exist. And then at some point someone tells you that those things are monads, but it’s in the kind of way that social psychologists make up some fancy word for crap we all know about in our gut.
Nobody gives a shit that a list is a monad, people give a shit that it’s a list. Anyone who’s written lisp or node or any nontrivial C program or anything with coroutines or anything with concurrency can and will tell you that, yeah, duh, control flow can be represented by a data structure. A couple more fancy “monad laws” and you have something that looks like other monads, and lists and if expressions and IO meld together. Ok, how unhelpful.
Re: Functors, Applicatives, and Monads
#28the bit at the end is quite rude of the haskeller responding but I also think they're largely right; another monads explained through boxes tutorial is not gonna help anyone. In fact it's really a step in the wrong direction. Using a few different monads is where to start.
Was it rudeness or honesty without malice? The "monad tutorial" instinct is a well-documented fallacy. In my culture we don't whitewash our opinions to make them palatable to someone who's obviously doing something wrong in a known way.
On first read, I was prone to agree with the author -- why put down someone seeking your input? Then I read your comment and went through it again. After a re-read I think you have it right. The response was direct, and perhaps quite cutting to the author who had devoted significant time to the article only to be told they're one of hundreds who have made the same mistake. But the only denigrating in the linked blog article seemed to be the grouping with others who had fallen into the same trap.
Re: Functors, Applicatives, and Monads
#29[dead]
Re: Functors, Applicatives, and Monads
#30I feel like Haskell is easier to use than it is to explain, and in my experience a lot of these kind of tutorial / explanations actually make things seem harder and more complicated than just working with the concepts and observing what they do. (This one included.)
Why are there so few practical, example and code driven tutorials? I've never run across a succinct "build Twitter with Haskell" in the wild.
Yes, I really need a real word Haskell project simple enough to understand all the math concept. Like, I don't know when to implement the Monad type-class to my domain data types. For example, taking the twitter example, if I have Tweet data type:
- should I implement the Monad, Applicative or Functor type class?
- How would that help in the big picture?
- What if I don't do it?
All these funny example of boxes, burritos or context doesn't not help me solve problems.
Take for example Monoid, I understand (partially maybe) that it useful for fold (or reduce) a list to a single value.