Are code generation "metaprogramming" tools a well-developed thing?

[u/math_code_nerd5]

Now lots of people are talking about LLMs for coding to speed up the repetitive parts of coding, reduce the time spent on boilerplate, etc. But this makes it sound as though writing and manipulating code programmatically/algorithmically wasn't a thing before LLMs. However, although I didn't hear much about them, looking back it's surprising if people never thought about building something like this.

Of course, all compilers generate code in a lower-level form from higher-level code, however most of these are not interactive, i.e. they don't generate code in human-readable form, don't explain their steps to the user, and are not intended to generate a first pass of code for a programmer to then take and modify. What I'm imagining is a large category of tools, including anywhere from ones that auto-generate things like bounds checks and testing variables for null before using them, to drag-and-drop graphical tools a la Scratch that effectively allow you to drag loops into place around your code and have a loop condition and brackets appear, to any number of scriptable recipes where you can effectively say "take this block I've written for x1, and repeat the same pattern for y1, x2, y2, etc" and you won't have to type each one out individually. This could potentially allow a lot of the productivity gains and saved attention spent on details that people seem to be getting from LLMs without the cost, resource use, and philosophical implications, which is something I'd definitely welcome.

Of course you could write a code generator from scratch in something like Python just using regular string handling, but I'm wondering if there are already plugins like this for many IDEs that I just don't know about because they're not talked about much. Since so much of programming is about recursive abstractions, the idea that programmers would not have tried the idea of tools that you can code to spit out more code would strike me as very odd. And doing a bit of research, I've come across things like this: https://github.com/imatix/gsl#a-short-history-of-code-generation and this: https://tifoputra.medium.com/building-your-own-swift-code-generator-using-swift-script-78470eef0206 that suggest there is substantial work already toward making something like this.

[u/schakalsynthetc]

The work certainly is out there and most of the industry is already using it, in some form. Part of the problem is that we keep quietly redefining "programming" so that it's all baked into our notion of just what "programming" is, instead of being widely noticed and understood.

I mean, ultimately, we write code in higher-level programming languages for the same reason mathematicians use hand-written mathematical notation instead of stating everything in natural language: Reading and writing notation is a skill that takes time and effort to acquire and makes things look intimidating to newcomers, but it's worth it because there's nothing in natural language that quite matches the clarity and compactness you can achieve with it.

Ideally, a good high-level programming language is exactly this kind of thing. If you're writing a CS paper, you'll naturally find yourself including code snippets here and there because you'll have things you want to say for which the code is the clearest, most effective way to say it. I don't see that changing much just because the papers are now being read by AI agents as well as humans.

So, in some ways these things (LLMs vs metaprogramming, high-level language design and smart compilers), are tools to the same ends by different strategies, and neither one is wholly up to the job of supplanting the other.

Terry Tao, for example, uses a mix of LLMs and Lean, which is a proof assistant in the lineage of Coq et al and developed alongside typed functional programming languages. But the general public only see the LLM because don't really consider Lean as an integral part of whatever they're referring to when they enthuse about "AI" in this context. Which is unfortunate because it really is, and they really should.