@bonifartius And another problem is that generated code is often hard to understand how it hangs together, i.e. "what do I need to do to X" is black magic rather than the excruciating pain of learning how that should be done. What you save in work, you lose in learning.
@niclas yeah, the generated code has to be sensible of course. this isn't often the case, but that's not a problem of codegen but by the generating tools writing out a mess :)
i think an easy way to deal with manual changes for generated code is - if the generated code permits that - to use subclasses (or whatever serves that purpose) with the generated ones as superclass.
in any case, i don't think that generated code is worse to debug than magic runtime stuff like SQL-query builders etc. :)
@niclas
> Everything can be made very bad, but it seems (to me) that code generators (incl my own) are extra prone to making life worse.
they certainly have to be build with great care :)
> And if you put the generated code in the superclass(es), then why not create those manually as a solid abstraction, designed for inheritance (also not trivial).
as you've written, manually writing things sometimes just isn't feasible. if one ends up doing a lot c&p, codegen is the cleaner solution imho.
> In general, the problem isn't technology, the problem is people. Solving "people problems" with "technology solutions" is what we programmers do, and equally perplexed when it didn't help.
agreed!
@velartrill @bonifartius Yeah, one could argue that every compiler is a code generator. But I think the problem is when a human expected to modify the generated code, which is often the case/goal.
@velartrill @niclas guess you sometimes want to do that, that's why i suggested subclassing or similar techniques to modify generated code :)
https://c.hale.su/parsav/file?name=tpl.t&ci=tip (which compiles things like https://c.hale.su/parsav/file?name=view/compose.tpl&ci=tip into machine code when the program is built)
https://c.hale.su/parsav/file?name=render/docpage.t&ci=tip