In practical terms, it’s most commonly a code pattern where any function that interacts with something outside your code (database, filesystem, external API) is “given permission” so all the external interactions are accounted for. You have to pass around something like a permission to allow a function to interact with anything external. Kind of like dependency injection on steroids.
This allows the compiler to enhance the code in ways it otherwise couldn’t. It also prevents many kinds of bugs. However, it’s quite a bit of extra hassle, so it’s frustrating if you’re not used to it. The way you pass around the “permission” is unusual, so it gives a lot of people a headache at first.
This is also used for internal permissions like grabbing the first element of an array. You only get permission if the array has at least one thing inside. If it’s empty, you can’t get permission. As such there’s a lot of code around checking for permission. Languages like Haskell or Unison have a lot of tricks that make it much easier than you’d think, but you still have to account for it. That’s where you see all the weird functions in Haskell like fmap and >>=. It’s helpers to make it easier to pass around those “permissions”.
What’s the point you ask? There’s all kinds of powerful performance optimizations when you know a certain block of code never touches the outside world. You can split execution between different CPU cores, etc. This is still in it’s infancy, but new languages like Unison are breaking incredible ground here. As this is developed further it will be much easier to build software that uses up multiple cores or even multiple machines in distributed swarms without having to build microservice hell. It’ll all just be one program, but it runs across as many machines as needed. Monads are just one of the first features that needed to exist to allow these later features.
There’s a whole math background to it, but I’m much more a “get things done” engineer than a “show me the original math that inspired this language feature” engineer, so I think if it more practically. Same way I explain functions as a way to group a bunch of related actions, and not as an implementation of a lambda calculus. I think people who start talking about burritos and endofunctors are just hazing.
I’m sure someone will be like “um akchuly” to my explanation. But for me it’s good enough to think if it that way.
I’ve worked in Haskell and F# for a decade, and added some of the original code to the Unison compiler, so I’m at least passingly familiar with the subject. Enough that I’ve had to explain it to new hires a bunch of times to get them to to speed. I find it easier to learn something when I’m given a practical use for it and how it solves that problem.
Lovely response! Very cool to see Unison mentioned. Haskell and Purescript are my daily drivers but I have a huge crush on it even though it intimidates me.
Ps. Unison doesn’t have monads. They are replaced by “abilities”.
It is, although I’m not sure it’s complete. A list is one kind of monad, despite working like non-mutable linked lists would in any other language. They just happen to behave monadically, providing an obvious and legal interpretation of the monad functions. Going off of OP you might think monads are all Maybe.
I will say that the concept is overhyped in at this point, at least in Haskell, and there’s a lot of monads available that do what plain functional code could but worse.
Great explanation! Though I prefer to regard monads as semicolon simulators. Monads combine actions separated by semicolons together. The combination can be exceptional, logging, multi-output, or whatever.
That’s a good run down of the “why”. The thing is, there’s way more things that are monads than things that have to be looked at as monads. AFAIK it only comes up directly when you’re using something like IO or State where the monad functions are irreversible.
From the compiler end, are there optimisations that make use of the monadic structure of, say, a list?
In practical terms, it’s most commonly a code pattern where any function that interacts with something outside your code (database, filesystem, external API) is “given permission” so all the external interactions are accounted for. You have to pass around something like a permission to allow a function to interact with anything external. Kind of like dependency injection on steroids.
This allows the compiler to enhance the code in ways it otherwise couldn’t. It also prevents many kinds of bugs. However, it’s quite a bit of extra hassle, so it’s frustrating if you’re not used to it. The way you pass around the “permission” is unusual, so it gives a lot of people a headache at first.
This is also used for internal permissions like grabbing the first element of an array. You only get permission if the array has at least one thing inside. If it’s empty, you can’t get permission. As such there’s a lot of code around checking for permission. Languages like Haskell or Unison have a lot of tricks that make it much easier than you’d think, but you still have to account for it. That’s where you see all the weird functions in Haskell like
fmapand>>=. It’s helpers to make it easier to pass around those “permissions”.What’s the point you ask? There’s all kinds of powerful performance optimizations when you know a certain block of code never touches the outside world. You can split execution between different CPU cores, etc. This is still in it’s infancy, but new languages like Unison are breaking incredible ground here. As this is developed further it will be much easier to build software that uses up multiple cores or even multiple machines in distributed swarms without having to build microservice hell. It’ll all just be one program, but it runs across as many machines as needed. Monads are just one of the first features that needed to exist to allow these later features.
There’s a whole math background to it, but I’m much more a “get things done” engineer than a “show me the original math that inspired this language feature” engineer, so I think if it more practically. Same way I explain functions as a way to group a bunch of related actions, and not as an implementation of a lambda calculus. I think people who start talking about burritos and endofunctors are just hazing.
I don’t know if this is correct, but if it is, this is best answer to this question I’ve ever seen.
I’m sure someone will be like “um akchuly” to my explanation. But for me it’s good enough to think if it that way.
I’ve worked in Haskell and F# for a decade, and added some of the original code to the Unison compiler, so I’m at least passingly familiar with the subject. Enough that I’ve had to explain it to new hires a bunch of times to get them to to speed. I find it easier to learn something when I’m given a practical use for it and how it solves that problem.
Lovely response! Very cool to see Unison mentioned. Haskell and Purescript are my daily drivers but I have a huge crush on it even though it intimidates me.
Ps. Unison doesn’t have monads. They are replaced by “abilities”.
It is, although I’m not sure it’s complete. A list is one kind of monad, despite working like non-mutable linked lists would in any other language. They just happen to behave monadically, providing an obvious and legal interpretation of the monad functions. Going off of OP you might think monads are all
Maybe.I will say that the concept is overhyped in at this point, at least in Haskell, and there’s a lot of monads available that do what plain functional code could but worse.
Great explanation! Though I prefer to regard monads as semicolon simulators. Monads combine actions separated by semicolons together. The combination can be exceptional, logging, multi-output, or whatever.
That’s a good run down of the “why”. The thing is, there’s way more things that are monads than things that have to be looked at as monads. AFAIK it only comes up directly when you’re using something like
IOorStatewhere the monad functions are irreversible.From the compiler end, are there optimisations that make use of the monadic structure of, say, a list?