Thoughts on compiler golf?

Question

Some time ago, I set this challenge as a test for a new type of challenge I called "compiler golf". In the end, my idea didn't set the world alight but I wanted to see if anyone had ideas for improving the idea.

The original version of the FizzBuzz challenge set the score by the length of the generated code, not by the compiler itself. My thinking there was that when thinking about real-world compilers, we care more about the quality of the generated code rather than the quality of the compiler. I wanted to reward writing extra code for optimizing the output, rather than to penalize it.

On reflection, the challenge I chose didn't lend itself to optimization and in the end I changed the rules to include the length of the compiler in the score, as people taking the challenge were golfing their compilers anyway.

Is compiler-golf something we want more of on this site?
What should be the rules of compiler-golf?
What else can we learn from my failed attempt to get it going?

Answer 1

As user23013 commented, this isn't really all that novel. It's normally referred to as metagolf (and as you can see, we even have a tag for it). In general, any sort of code generation challenge which is scored by the size of the generated code is metagolf, and the tag should be used if this is the primary winning criterion.

I don't think there should be a standard winning criterion which counts both the output and the generating program's size, because the balance of these too will always depend on the challenge in question (and getting mixed winning criteria right is always tricky). So if you want to take both things into account, just use the catch-all code-challenge.