What on earth makes you convinced that a monad can be implemented in Excel? You don't understand what a monad is, so you can't know whether Excel is "perfectly capable" of it or not.
Read a bunch of monad tutorials, learn Haskell, hey, even develop some "mathematical maturity" if you can get over your disdain for math. That is the way to make progress.
It's not helpful to want monads to be tangible objects. It doesn't matter how much you want it. The world doesn't work like that.
> What on earth makes you convinced that a monad can be implemented in Excel
True monads can't even be implemented in Haskell. But if we're being practical, you can totally implement monad-like things in Excel. It's almost impossible not to implement monad-like things when building anything non-trivial.
I don't think making this claim is helpful. Monads aren't found everywhere in code. Solving a problem which could be solved by monads doesn't automatically lead to code that works in a monad-like way, not in any meaningful sense.
I completely disagree... The distinction is simply that they're usually ad-hoc and not formalized, mainly because the author didn't know what they were writing and was reinventing the wheel.
What I mean is, they can easily be used as monads - and in fact every Excel user might do so without even knowing what a monad is. Like 41 is used in commutative expressions all the time by people who don't even know what communitivity or associativity mathematically is and that is a good thing! It means its useful and intuitive!
That's why I wish we could throw out the Math, if we can't even use Monads without mathematically knowing they are Monads then no one is ever going to be using them. There must be a way that these patterns can become so intuitive, like Pipes (weak) and Excel (strong) that they speak for themselves and become tangible.
> if we can't even use Monads without mathematically knowing they are Monads then no one is ever going to be using them.
You don't need to know what a monad is to use one. Everyone who has ever written a computer program has used one. Knowing that you're using a monad, and what that means about your program structure, is the entire value proposition here - actually applying particular monad operations is utterly trivial. "Monad" belongs in the same category as "data structure", not "tree".
What on earth makes you convinced that a monad can be implemented in Excel? You don't understand what a monad is, so you can't know whether Excel is "perfectly capable" of it or not.
Read a bunch of monad tutorials, learn Haskell, hey, even develop some "mathematical maturity" if you can get over your disdain for math. That is the way to make progress.
It's not helpful to want monads to be tangible objects. It doesn't matter how much you want it. The world doesn't work like that.