Re^2: (OT) Generated Code vs. Libraries

I'm with William G. Davis in disagreeing with you on this. Code generation can mean that you've managed to express things in terms of a higher-level abstraction. I don't see the relevance of your distinction between code generated at runtime and that generated earlier.

It would be perfectly reasonable to invent a new language (whether a generic language or something more domain-specific), and have the implementation of the language compile it to perl code.

In fact a C compiler does exactly this: it generates an assembler program from the C code. This also I think answers the one issue I recognise from perrin's comment, on the danger of files getting out of sync if you hand-edit the intermediate results - it is a matter of expectation (I don't expect to edit the assembler source that the C compiler produces), reinforced by infrastructure (eg setting the generated files read-only) and protocol ("this is the procedure to change it").

Hugo

Comment on Re^2: (OT) Generated Code vs. Libraries

Replies are listed 'Best First'.
Re^3: (OT) Generated Code vs. Libraries by perrin (Chancellor) on Oct 22, 2004 at 15:11 UTC
If you don't see the relevance of the distinction between code generated at runtime (sometimes called "active code generation") and that generated earlier ("passive code generation"), I'm guessing you haven't worked on a large project that used passive code generation. The problem is that there will be an emergency fix and someone will edit one of the generated files because it's much easier than trying to understand and change the code generation code. And then you are in big trouble. Anyway, both of you seem to be implying that I said something like "generating anything from anything else is always bad." That's not what I'm saying at all. Let me try to re-state it more clearly: In most cases where you could use code generation to solve a problem, you could also use a data structure and some subs to solve it. To quote from the wiki link I posted, "Anything you can do by generating code, I can do by calling data driven subroutines." Using subs is better because it is easier to understand (no need to parse two-levels of code at once in your head) and avoids the danger of hand-editing. I'm not claiming that there are no situations at all where code generation is required. A common reason to use active code generation is the performance gain you can sometimes get with it (e.g. templating systems often generate perl code from templates). Even if you completely disagree, the wiki link I posted is pretty interesting reading, and makes good points on both sides.	[reply]
Re^4: (OT) Generated Code vs. Libraries by hv (Prior) on Oct 24, 2004 at 10:34 UTC
I'm guessing you haven't worked on a large project that used passive code generation. The application I've been working on for the last 4 years has had a gradually increasing amount of its code generated, some of it at install-time and more at run-time, and I expect that amount to continue to increase. The code is currently a little short of 50k lines. We have not had problems with hand-editing of the generated code. On the rare occasion that an urgent problem has been fixed by hand-editing, the immediate next step has always been to update the source to apply the equivalent fix, test and reinstall. Hugo	[reply]