The more I keep thinking about metaprogramming the more I feel like it's more of a detriment than a boon.

For one it's another layer in the Chinese whispers game that programming has turned into.

For another debugging the eventual code is going to be tricky. When debugging you want the machine code to be correlated to something human readable. For non-trivial metagenerated code, this is hard to do in a way that is easy to use.

For another sometimes you will want to debug the meta program itself, I have yet to see a language that lets you step through the compile time execution like that.

The only meta programming that actually lets you do this is separate source-generation tools. But you don't need language facilities for that.

What counts as a complex meta programming feature?
When would you use it?

pragmatic_hero
What counts as a complex meta programming feature?
When would you use it?

For example D's string mixin combined with compile time function evaluation.

It lets you parse things at compile time and then generate code for it at compile time. For example regex patterns getting compiled into optimal code to parse it.

However this brings me to another point I wanted to bring up but slipped my mind:

Each time the source is compiled, the compiler will need to redo all the meta-programmed work. There aren't any real facilities to cache the results of the metaprogramming except by using a build system and not recompiling that source file. (Which of course doesn't work when doing single translation unit builds.)

Each time the source is compiled, the compiler will need to redo all the meta-programmed work. There aren't any real facilities to cache the results of the metaprogramming except by using a build system and not recompiling that source file. (Which of course doesn't work when doing single translation unit builds.)

Is there a reason to do single translation unit builds - if your programming language supports modules (such as D)?

One of the key-problems with metaprogramming in C++ is that it doesn't simply "slow down" compilation - (slowing down is already bad enough) - It blows up the compilation times by an order of magnitude.

Can compile-time costs of metaprogramming features - be similar to cost of performing the same code at run-time?
If it can be, is there any other drawbacks (except debug-ability)?

Without compile-time introspection (in combination with compile time metaprogramming), is there any other way to generate fast-automatic serialization and similar automatic object-state-mapping features?

ratchetfreak

The only meta programming that actually lets you do this is separate source-generation tools. But you don't need language facilities for that.

After thinking about it myself, I came to a similar conclusion, that metaprogramming really only makes sense to me when the generated code is actually in a file you can read, and the metaprogram can be debugged like any other program, and that I probably will always want to write a "metaprogram" as something that is separately compiled and run. So I tend to think the language's "metaprogramming" features should be features that support the existence of this separately maintained source generation system.