Lambda the Ultimate

I like these guys, so I am glad they are being read. I fear you are a bit too optimistic about just how many programmers really read about programming when they get home from work...

Aside from hoping they read is there anything the education system should be doing?

(BTW, people should also read Jon Bentley. He belongs to the same Bell Labs gang...)

If you really need code generation your programming language simply doesn't have enough abstraction power.

Sure.

I don't think you should encourage people to learn code generation techniques.

Learning isn't the same as "using". Knowledge is power, bla bla bla...

From personal experience I never had to resort to code generation in Python, but it often comes handy in Java.

I tend to use it when I am obliged to use a framework (EJB anyone?) that requires a lot of dumb code (getters/setters).

I think it is also related to the introspesction/reflection/dynamicity of the language.

Anyway, it could be a new metric for defining the abstraction power of the language :)

Yup. One thing about generating parsers using JavaCC is that once they're generated you can use all the usual Java static typing stuff. It'd be possible to write code to read in a grammar and generate the parser and such at runtime, but with that much runtime dynamic action going on one might as well use Ruby.

If you really need code generation your programming language simply doesn't have enough abstraction power.

In that case all I have to do is convince the entire company to move to a different language. Or at least let me program in a language that is powerful enough. Unfortunately I don't think that will happen any time soon.

What sorts of languages where you thinking about? Macros (a la Lisp) would, in my opinion, fall under the umbrella of code generators, just much cleaner and less error prone than the typical generator.

Once we start defining these things the distinction between code generators, interpreters, compilers, etc. tends to blur. I'm sure these techniques really lie on a continuum; it's simply a matter of which place is the best place to be for a particular project. This is demonstrated in a quick-n-dirty (and probably very wrong) diagram:

   rigid and static                                    flexible and dynamic
<--passive generators---active generators--macros--compilers---interpreters-->

I'm guessing that the cleanest option for many projects is to build a DSL in the form of an interpreter, but sometimes that might be overkill.

Note: When I say “rigid and static” and “flexible and dynamic” I'm not talking about the type system, but about the ability of the system to change. Passive generators are run once; subsequent changes get made by hand. Interpreters, on the other hand, have the ability to dynamically generate, modify, and change their own code at runtime.

Does any of that make sense?

To blur those distinctions perhaps more, there's camlp4, where you can take the existing ML grammar and plug in new productions — or start from scratch — and generate an abstract syntax tree using convenient (if slightly ugly-looking compared to Lisp/Scheme) quotations. So, it's kind of like a macro system, except you can parse more or less arbitrary text with it; so, there's no reason it couldn't be used to parse your DSL of choice and emit OCaml source, which sounds more like a code generator.

One-Day Compilers, Or: How I Learned to Stop Worrying and Love Static Metaprogramming, implementing a DSL in O'Caml using camlp4 and generating C. :-)

I'm sorry, I can't top that. That's genius.

I work with Rich Kilmer; he did lots of work on a Ruby bridge to the Java Debug Wire Protocol. As I recall he generated a ton of Ruby code directly from the JDWP spec, which made for a pretty hefty Ruby file!