How long did it take you guys to read this post?
I went through the same phase in my C++ career. (Mine was attempting to add FOREACH to my projects without depending on Boost.) I think at some point every C++ dev gets tired of writing boilerplate code, and then spends the next few days implementing something that would've otherwise taken them a few hours.
Once you accept that C++ is not Lisp, and doesn't need to be, then you become much more productive.
Additionally, your resulting C++ code is much more likely to actually be used by other C++ engineers.
Lastly, these sorts of libraries tend to be very difficult to debug unless you were the one who wrote it.
I understand your rant, but I'm not sure this is the place to go and spew it... Actually some people enjoy studying programming languages themselves and sometimes come up with useful stuff for engineers that like building more concrete stuff.
It's fine to pursue this as fun for its own sake if you are under no pretense as to its practical utility. But the danger of having your fun it in a bread-and-butter language like C++ is that you will be tempted to let it infect your workaday coding style. That's one of the perpetual dangers of hiring bright, overeager C++ programmers at the junior level.
Boost is a minefield. Its less booby-trapped libraries have made it into the next C++ standard library, but the more hardcore indulgences in metaprogramming like Spirit deserve all the scorn that is customarily heaped on them, if not more.
Where are they overused?
This trend originated with Haskell and then when people who learned monads without understanding the other (often better) abstractions spread them everywhere else, we got things like this article.
Using monads, especially in a language like C++ templates or Scala, but also in Haskell, can overcomplicate things and make things longer than if you just solved the problem the direct way.
--
As an example of where monads are overused, look at the Maybe/Option type. I've read several articles that advocate using bind and/or Haskell's do-notation to move a string of null checks out of the main program.
This is great, but it's much more easily and expressively done with applicative functors. Instead of assigning all the intermediate results to names, you can just do
someFunction <$> Just 3 <*> Just "Something"
and it looks like regular function application. Because Applicative is a more general interface that Monad, it also has the plus of working with more types.
I think the Maybe example may be wrong, though. You may need the power of Monads sometimes. If you have a function that requires the result of a different function which was wrapped in Maybe, Applicative will not be enough.
Example:
xmlChild :: String -> Element -> Maybe Element
myPath = xmlChild "a" >=> xmlChild "b" >=> xmlChild "c"Likening Haskell to C++ TMP makes a good deal of sense to me.
http://boostcon.boost.org/program/schedule#schedule.milewski...
Unfortunatelly, slides are gone.