I don't even think the author should be using monads for expressions how he was doing in Haskell, which arguably does have suitable tools for using monads in th

I don't even think the author should be using monads for expressions how he was doing in Haskell, which arguably does have suitable tools for using monads in this way. Doing it in C++ is ridiculous. One can have expressions like that in C++ using C++'s many other abstractions, such as classes and inheritance. This will result in code much shorter, cleaner, more general, more useful, and more readable code than what is found in this blog post. The author hasn't achieved the abstraction of a monad in C++ anyway; there's no way to write code that works on both this monad and others, which effectively makes modeling something as a monad as he has done completely without benefit. This would be quite accurately referred to as cargo cult programming. A monad explanation that is not cargo cult mathematics would be one that explains what a monad is in category theory (a functor with two associated natural transformations), explains it as one of many other patterns, and explains why simply including monads and these other patterns in your code does not automatically give them the Mathematical Seal of Approval™, especially when using a language with no support for abstracting over them.