here's where languages enter the picture: a compiler for a language translates programs into executable form, ie performs code generation. so one way to support programming RTCG would be to support compiler generation (and make sure they work at `runtime').
by adopting language labels, the last code fragment becomes:
program = user(); objcode = compile(program); for (i = 0; i < bign; i++) ans[i] = objcode(argument[i]);which precisely describes program developement: the programmer edits the program, compiles it, then compiled code runs many times (note it may only be some part of the compiled code that runs many times, and these are probably the only parts worth compiling).
power is an interpreter for a language of integer exponents.
just like a typical lisp eval, the program directs control flow which
effects computation of the argument. if the program is fixed, then
this control flow can be performed once by the compiler, rather than
repeated every time the program is run.
it's a stretch to say power is an interpreter with integer
programs. but if we actually look at shading in 3D graphics, we find
the per-pixel programs vary from a handful of numbers to lists of
structures (light and surface properties) to shade trees to Renderman
programs. the transition to `real' languages is smooth.
but what use is the metaphor? if we want to create functions that create code at runtime, why relabel the problem `compiler generation'? answer: because compiler generation is a classic problem in computer science, and recent results in semantics-based program transformation appear promising for our purposes. it suggests using interpreters to specify generating extensions. furthermore, the formalism of languages provides a unified approach to the usually vexingly unspecified and irregular meta-programming issues.
so if each instance of RTCG is specified with a language/compiler, then a system where RTCG is cheap+easy to program is one where it's cheap+easy to create languages/compilers---one where languages are lightweight.
there are reasons to believe that techniques for `lightweight languages' may be more broadly useful than just interactive graphics: embedded application languages, human-computer interfaces, network protocols, and software engineering module interfaces share the same fundamental problems, and may too benefit from lightweight languages.