+bonifartius 𒂼𒄄
i'll never understand what issue people have with code generation if the code is properly formatted. no runtime magic to debug. it's all there to read, which is a damn nice feature imho.
@bonifartius So, round two was all about figuring out what parts would be changed manually and which part was going to be modified by running the code generator a second time, by doing mostly Composition hooks in a separate package.
I think most people get annoyed that after the code is generated, any manual changes will be lost, yet have the desire to run code generator again (changed the generator or changed input parameters) as they are seldom designed for it.
@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. :)
@bonifartius Everything can be made very bad, but it seems (to me) that code generators (incl my own) are extra prone to making life worse.
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).
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.
@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!
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
@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 :)
@bonifartius the code you generated is harder to read than whatever it was generated from, unless you are just wasting your time with the whole thing, so you are essentially requiring the knowledge of your DSL, especially from people who don't just want to painstakingly reverse engineer your project, but actually comfortably learn and contribute to it. That is, once you have it, you will go haywire with it, generating ton of hard to read and understand code, otherwise, if you just wanted it for one small thing, there is no point in doing it in the first place.
With this requirement in mind, you also introduce a new dependency to set up and maintain, a new build step to integrate. Especially for large projects if your generator is not careful about, what files it reads and especially writes to it can be a huge pain to deal with.
It also indicates that original language of choice was not expressive enough for the task at hand, since it by itself is conceptually the same as a code generator. In theory instead of making a code generator for your code generator, you should just improve your code generator or use a better suited code generator. If you need to write a part of C project in python, use language bindings instead of reinventing wheels.
Then there are things like Qt meta object compiler, which solves problems nobody needed solved and breaks standard language conventions, the kind of nuances that are beyond just code formatting and can have various annoying side effects.
@bonifartius There are pros and cons, and also depends what is being generated.
E.g. I made my own code generator because there were ~150 business object types that had a lot of things in common, but couldn't use common base class(es). The first round was hopeless, because we quickly realized that we forgot a few things and trying to keep manual changes were impossible.