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.
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."
> Learn about higher-order functions, higher-kinded types, parametric polymorphism, and bounded polymorphism.
Except that's not the case because most people know all of those concepts from their main language, and don't know what a monad is.
Higher order functions yup. A function can take a funtion as an argument and correctly assign the argument type (unless C where you can finagle it but it's not first class).
Higher-kinded types? Yup. Prettt much half of "generics". Taking C# that essentially the idea that List<T> is a "type constructor" that allows you to construct a type. If you specify Integer as the T you can say something like List<Integer> and you get a type which is a list of integers.
Parametric polymorphism? Yup. When defining function - for example using List<T>. You can define the implementation of the function using the generic parameter "T" and not have to specify if you are defining the implementation on a list of Integers or a List of String, and the single implementation will work for all of them.
Bounded polymorphism? Yup. Again using C#, you can specify a restring on the "T" type parameter. Instead of saying "T" can be any type at all, you can add a "where" clause that says "T" must implement the ISerializable interface, or it must be a subclass of Foo class.
So most people will read this list. And say "huh, I guess I do already know all of those concepts but by different names." But that doesn't mean they understand Monads conceptually, when to use them nor why. Even if those things are required to read the Monad definition, there is more there.
A rough analogy, but it's like saying people know the visitor or facade design pattern just by reading their type signature. Oh and if instead of having intuitive names their names useless names like "foblax" and "grobalum" design patterns.
I assure you, most people cannot tell you the difference between bounded polymorphism, parametric polymorphism, and whatever their language thinks polymorphism means. (The latter is not the same as either of those.) Most people cannot handle the idea of talking about an unapplied type constructor, because their language of choice cannot do that. Maybe the number of people who can think in higher order functions has reached the majority by now. Some good ideas eventually do spread.
But most of all, people do not understand how Haskell's type system works. It is incredibly precise and concise documentation. When you do use a function? When you have its inputs and need its output. Sometimes things are defined in terms of concrete types and need further explanation. But when talking about incredibly generic interfaces like these, that's 90% or more of the necessary documentation.
Learn how that works, and you'll see why there isn't much to say about Monad.
> I assure you, most people cannot tell you the difference between bounded polymorphism, parametric polymorphism,
And yet most people know one of Java, C# and Typescript and know how to use generics with constraints. Meaning they know those concepts. Your arguing my point for me. Knowing those concepts clearly isn't sufficient.
There are three things being discussed that you are conflating. Knowing a concept, knowing it's terminology and knowing how to all of them combine when used in a new concept. Knowing the underlying concepts does not imply the first. And similarly not knowing the terminology does not imply someone does not know the concepts as you seem to think it does.
> And similarly not knowing the terminology does not imply someone does not know the concepts
Which is why I keep focusing on understanding the Haskell type system. Those are necessary concepts, which you will learn the names of along the way.
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