Cargo cult programming itself seems to be an overused term. According to wikipedia it means "a style of computer programming that is characterized by the ritual inclusion of code or program structures that serve no real purpose. Cargo cult programming is typically symptomatic of a programmer not understanding either a bug he or she was attempting to solve or the apparent solution". I've seen this done. I knew programmers who would call the same (side-effecting) function twice in a row, "just in case, since it might fail the first time", instead of actually checking the function's return code etc.
Do you really think the post's author has no idea of what is talking about? That he copy-pasted some code and ended up with an EDSL in C++? The particular code he shows might not be practical, but that doesn't mean it's "cargo cult". For instance, perl-golf, obfuscated C contests and implementing X in Javascript aren't practical-minded activities either, but you can't call it "cargo cult": programmers engaging in them aren't exactly clueless.
Again, monads may be perceived as "hyped" but that doesn't mean they're "cargo cult mathematics" any more than the Y combinator is.
While it is true that they work to help organize libraries like Boost Proto, it is questionable whether that's the best or even a good way to accomplish that library's goals. There's a reason the metaprogramming-heavy parts of Boost are still generally avoided in many parts of the programming world.
I see this as cargo cult because it appears as "monads are cool, and C++ templates are a weird functional language, let's do it that way" without much regard to whether monads, template metaprogramming or EDSLs are the right tools here.
Monads are an example of using patterns from category theory in programming. This can be done nicely in languages with the facilities to do so, like Haskell. For instance, Functors, Monoids, and Comonads are patterns that are sometimes used in Haskell that are taken from category theory. However, the way monads are often used in Haskell is cargo cult mathematics. Here's why.
In category theory, monads are defined as functors with two associated natural transformations. However, in Haskell, the typeclass Monad is not even defined as a subclass of Functor. Additionally, one of the two natural transformations is swapped out for another (join is replaced by bind), and both are misleadingly renamed (return and bind don't suggest their actual meanings). Also, monads are often overkill for the problems they are applied to. Rather than think carefully about which pattern to apply to the problem, programmers echo the trumpeted “Monads are the fundamental method of abstraction!” and use them in their code, for that is the right thing to do.
Monads are not actions. Monads are not defined as a way to thread state through code. The type IO a in Haskell is an action, and since the interface provided to this abstract data type is monadic, there is a great deal of confusion about what the properties of a monad are and what the properties of the IO a type are. This blog post confuses them.
Even though monads are misused in this way in Haskell, their use still brings benefits. This is because Haskell gives the programmer facilities to write code that works over every monad. However, this is not the case in this blog post. The code in this blog post is parametrized over the types returned by the actions, but not over the actual type of action. One can see where he is looking at Haskell implementations of the functions to translate into C++ that they aren't. This basically renders the monads useless.
Another telling example of how these aren't really monads is when he says “You might have noticed that I use the words “action” and “program” interchangeably, although, strictly speaking, an action is the contents of a program. However, this distinction is an artifact or a Haskell quirk — a monad can’t be defined using a type alias, so we need the Prog type to encapsulate the action. Curiously, we won’t have this problem in C++.” In Haskell, an instance of Monad needs to be a container type, because the two functions that are the fundamental definition of a monad operate on nested containers (unit puts anything into a container, and join makes a container of containers into a single container). Since his C++ code isn't doing anything like this, he hasn't made a monad at all. He's simply made an extra layer of complexity in compiling an AST into actual code at compile-time, a task which has nothing to do with the nature of a monad. I'd reckon one could write code for compile-time EDSL's in C++ using no monads at all that would be much cleaner.
Sure, you can make a structure and slap the label monad on it and use return and bind functions (which aren't really what a monad fundamentally is) to put together your code, but if you can't write code that works as well on that monad as on other monads without changes, you've accomplished nothing but useless complexity. In other words, including program structures because they are accepted as good rather than because they have any benefit.
Also, it's a monad whether he mentions it or not. Can you reference a monad explanation that is not "cargo cult mathematics"?
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.
I upvoted both of your comments because of that statement. Explaining your position (although, it is a fairly weak argument) is enough.
My trigger for cargo-cultism was him stating that you want to lay out your templates in Haskell first.