Author here, and I agree that using templates for complex code generation is a mess. However, it&#x27;s a popular mess in some branches of high performance computing right now, especially for dealing with the transition to execution on GPUs. If you&#x27;re stuck in C++ and want abstraction without runtime cost, templates are what you&#x27;ve got. An alternative option is to step outside of C++ and write a compiler or source-to-source translator in a more suitable language (the direction we&#x27;ve gone since), but that means existing C++ programs can&#x27;t just drop in your DSL as a library without adding more bits to their toolchain.<p>If you do decide to make a complex library based on template meta-programming, you inevitably end up needing a meta-meta language to help build it because templates are so ill-suited to the task (especially before C++ 11). Many template-based libraries (like Eigen, <a href="http:&#x2F;&#x2F;eigen.tuxfamily.org&#x2F;" rel="nofollow">http:&#x2F;&#x2F;eigen.tuxfamily.org&#x2F;</a>) have chosen to use preprocessor macros as that meta-meta language; we decided Racket was a better choice and this paper is our exploration of how that might work. I suppose an interesting takeaway is that even if user constraints force you to implement your DSL compiler as a template meta-program, you can still use an outside meta-meta language to help create the templates.<p>The statements regarding debuggability make two claims that I think are correct, if not particularly strong: 1. using Fulmar as a meta-meta language produces a more readable template meta-program to examine than do preprocessor macros; 2. Fulmar can catch some errors at the meta-meta level and provide nice errors  (section 4.5) in places you might have otherwise received the nasty template expansion errors (again unlike preprocessor macros).