This type of C++ code also makes me sad. I actually can't follow along. I can't glance at the code and parse what it is doing because the template keyword has many flavours, as does class, as does typename, as does using, as does ..., and so on. < and > seem to be the template equivalent of ( and ). I can't tell the intent of a piece of template code quickly.

I agree with your Lisp sentiment. It appears that the C++ folks have spent the last 15 (20?) years re-implementing Lisp macros badly. Every time they work out the kinks in the syntax, remove corner cases, and make it more expressive: it becomes more Lisp-like.

When you compare with the approach Ruby took (granted, Ruby is a dynamic language) you get the feeling that the C++ folks went wrong somewhere. Far be it from me who has never implemented a compiler to criticise them but that's the honest feeling I get. Ruby made everything an object with an associated class. Or what amounts to the same thing, it made every type of thing get-at-able as an object with an associated class. And here is the kicker, including Object and Class itself. Why could the C++ folks not have made type an object with an associated class with compile and runtime methods?

    class Foo {
        ...
    }

is just sugar for

    type Foo = new class();
    Foo.class_eval {
        ...
    }

How did Lisp solve (40 years ago) the problem of generating a compile time errors when types of the arguments into a function call did not match with what the developer of the function anticipated?