Odin » Forums » Are complex meta programming features actually worth it?
ratchetfreak
262 posts
#10056 Are complex meta programming features actually worth it?
5 months ago

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.
pragmatic_hero
30 posts
#10059 Are complex meta programming features actually worth it?
5 months ago

What counts as a complex meta programming feature?
When would you use it?
ratchetfreak
262 posts
#10060 Are complex meta programming features actually worth it?
5 months ago

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.)
pragmatic_hero
30 posts
#10063 Are complex meta programming features actually worth it?
5 months ago Edited by on Dec. 23, 2016, 12:27 p.m.

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?


Mr4thDimention
Allen Webster
218 posts
2 projects

Heyo

#10080 Are complex meta programming features actually worth it?
5 months ago

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.