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

I completely disagree. Code generation is a sign that you've found a way to get the computer to do something tedious and repetitive for you, thus saving valuable programmer time and eliminating possible human error.

Some examples:

MS decided not to provide any reliable way to get stub error messages for socket errors. You can use FormatMessage() with GetLastError() (like how strerror(errno) works on Unix), but not with Winsock's WSAGetLastError(), for some reason or another. So I went to the page documenting the error codes returned by WSAGetLastError() and found each code had a short description beside it. I wrote a little Perl script that used LWP to fetch that page from the MSDN website, parse the HTML and extract each error code and error description, then generate C code for a lookup table of error strings. Problem solved.

I have a subsystem in a C library of mine that basically just encapsulates a few common structs, providing New() constructor routines, Get() and Set() accessor routines, and Destroy() destructor routines. The documentation for these routines would be quite predictable, so I wrote a Perl script that parsed the header file (which itself was automatically generated from the source file) and generated POD documentation for each routine. Now I only need to add a few additional, routine-specific bits of information here and there and it's done. Problem solved.

I wanted an XSUB interface to some C code of mine. I wrote a code generator that generated the XSUBs for me along with some special functions and CODE: and PPCODE: sections to do some neat stuff way beyond what h2xs (another code generator) is capable of producing. Time saved, problem solved. (xsubpp itself is a code generator, by the way.)

You'll probably say that I shouldn't have had to generate that lookup table, that MS should have made FormatMessage() work with WSAGetLastError(), or that C should be C++ and make encapsulating abstract data types easier, that XS ought to be more flexible, or whatever. The fact is that we don't live in a perfect world with perfect software. Stuff we use often times doesn't work or doesn't work very well, and we as developers find ourselves having to pick up the pieces.

Code generation can help with that, doing the repetitive stuff for you and saving some serious time in the process.

See The Pragmatic Programmer, page 102, for a discussion of this.

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 03:47 UTC
I think you're missing the point. The idea is simply that anything you can do via code generation could be done using subroutines instead, provided you are using a high-level dynamic language like Perl. In addition, your examples are mostly not what I would call code generation. Generating a lookup table from an HTML page is basically data manipulation and could be done as a config file rather than code. Generating documentation is, well, documentation. It's human-readable text, so you can't handle it as a library call the way you could with other code generation situations. I don't know enough about XSUB to comment on your last example, except to say that the rules are different in static languages like C where you really may not be able to do certain things as a subroutine. The canonical example for this discussion is generating a set of classes for manipulating database tables. Class::DBI does this in perl, and it uses code generation, but it does the generation on the fly at run-time and doesn't produce an intermediary source code that can be hand-edited and get out of sync. The use is still questionable in my opinion, but not as bad as it could be.	[reply]
Re^4: (OT) Generated Code vs. Libraries by William G. Davis (Friar) on Oct 22, 2004 at 04:51 UTC
I think you're missing the point. The idea is simply that anything you can do via code generation could be done using subroutines instead, provided you are using a high-level dynamic language like Perl. Well, you condemned code generation in general, so I gave several examples of where I found it appropriate and beneficial. It's true that the common denominator in each example was C, but there are times I've used generators for Perl too. Generating a lookup table from an HTML page is basically data manipulation and could be done as a config file rather than code. Maybe, but then I'd have to write C code to open the file, parse each line, and build up a data structure for the codes and strings dynamically. Pain in the ass, and much, much less efficient than the static array generated by the Perl script. Generating documentation is, well, documentation. It's human-readable text, so you can't handle it as a library call the way you could with other code generation situations. The Perl script generated POD, which is a form of "code," is it not? I understand what you're saying, though. But there are times you need code that's predictable enough to be automatically generated but not predictable enough to be encapsulated away by a few routines. Yes, this is much rarer in a language like Perl, but it still happens. I don't know enough about XSUB to comment on your last example, except to say that the rules are different in static languages like C where you really may not be able to do certain things as a subroutine. Converting linked lists to arrays on return, making sure everything gets garbage collected correctly, and giving each XSUB a shorter, more Perl-ish name were just a few of the problems it solved quickly for me. Class::DBI does this in perl, and it uses code generation, but it does the generation on the fly at run-time and doesn't produce an intermediary source code that can be hand-edited and get out of sync. The use is still questionable in my opinion, but not as bad as it could be. The generated code getting edited and becoming out-of-sync with the generator is only problematic if you don't know what you're doing. Hunt & Thomas described (The Pragmatic Programmer, pp. 103-05) two types of code generators: active and passive. Passive generators generate something once, then the output is taken and used and modified as needed (e.g., the XSUB generator described above). An active code generator can be used again and again as its sources of input change (e.g., the Winsock error lookup table generator described above). Just know which type of generator you're going to write and what you plan on doing with its output, and everything should work fine.	[reply]