Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

ziggy (25)

ziggy
  (email not shown publicly)
AOL IM: ziggyatpanix (Add Buddy, Send Message)

Journal of ziggy (25)

Monday November 04, 2002
01:06 PM

Justifications for code generation

[ #8759 ]
Shawn Wildermuth is thinking about code generators again:

So this is my stake in the ground. Using Code Generators to create code that is based on metadata to help make a performant, but flexible system. Anyone else use code generation in this way? If so, please let me know. I want to confirm my suspicion.

I've used code generators before. I haven't written a code generator or a used one in a few years. Why? Because the code generators that (I think) Shawn is talking about are an inelegant hack around a bad programming language. That is, when writing code in a statically typed language, it is often necessary to abstract out the metadata for a system and write an external program to generate code. The benefit is that the system is somewhat easier to maintain. The drawback is that the system is defined in three places -- the handwritten portion, the metadata, and the code generator. Often, these are three different types of systems, requiring three totally different skills and mindsets to understand.

The approach I've been using for the last few years (ever since I became comfortable using Perl) is to use dynamically generated code. There's still a benefit of defining the system in terms of metadata, but the handwritten code, the code generator and the metadata are all maintained in the same environment. That is, the code generator is a bit of Perl code that gets run at compile time (after the program is loaded, but before it starts execution), and the data is a set of Perl data structures (or something else, like YAML or XML if you absolutely prefer).

Add it all up, and dynamically generated code is much easier to understand, use, and implement. Based on my limited experience, it's also easier to debug, but I could be wrong...


List all Journal entries
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Justifications for code generation 5 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • When you consider that a "compiler" is just a "code generator" for machine language, all the same rules apply.

    When we first got compilers, people complained that they couldn't debug, because the debuggers showed only the translated version. And there were times when the compilers generated sub-optimal code, and there was no way to tune or fix the output without breaking the paradigm.

    But now, high-level languages are commonplace. High-level debuggers are commonplace. The resulting machine code is opti

    --
    • Randal L. Schwartz
    • Stonehenge

    • When you consider that a "compiler" is just a "code generator" for machine language, all the same rules apply.

      When we first got compilers, people complained that they couldn't debug, because the debuggers showed only the translated version. And there were times when the compilers generated sub-optimal code, and there was no way to tune or fix the output without breaking the paradigm.

      I don't think it's the same thing here. In an abstract sense, it is all about the maturity of the tools. But in a pra

  • Lately, we've been using code generators to build C (gcc and quircky C compilers for embedded processors) in two areas:
    1. State machines. Using something I call StateML to defined events, actions, states and arcs along with snippets of documentation and snippets of source code for zero, one, or more languages side by side in the same file to generate any and often all of:
      • State diagrams (via GraphViz) in .png or .ps format.
      • HTML text + graphics docs, HTML generated using a TT2 template and graphics from t
    • Wow.

      Suffice it to say that I'm suffused with the itch to build a better diagramming tool that scales between expressivity (so my firm can communicate designs clearly, both internally and externally) and rigourousness / completeness (so we can reap the rewards of literate programming) while not being so exclusive and prescriptive that it's all or nothing. A pipe dream, but a useful one to persue, I hope. All in my copious spare time.

      Sounds like you're attacking an interesting, yet different problem tha

  • Are you suggesting that the popularity of templates in C++ indicates that something's horribly wrong with its typing system? I could be persuaded to agree, especially with the push for genericity in Java. :)

    It's interesting to hear some of the more recent XP ideas about code generators. I think it was Alistair Cockburn's Agile Programming book that suggested the master programmers should write code generators and the rest of us should customize the output as appropriate. (That sounds like a horrible

Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.