> Is this "visual programming"? No. The term "visual programming" has had a well-established definition for several decades, and this tool is not that.
> A "visual programming language" provides graphical representation and spatial manipulation of the program structure. (That is, static "elements" or "operators", analogous to the "code" in a conventional programming language, or schematic components in a circuit).
> This is not the case with the tool here, which actually represents program structure as a fairly conventional list of textual instructions. The only direct manipulation of the instructions is merely in selecting them for looping, deleting, etc.
> Instead, the tool provides graphical representation and spatial manipulation of the program data. (Dynamic or "runtime" information, analogous to the values of data structures in a conventional programming language, or voltages in a circuit. In this case, the data is a picture.) The program structure is built up implicitly by directly manipulating the data.
Luna seems to lay firmly in the former category rather than the latter: it is firmly steeped in writing code to manipulate and visualize data, rather than manipulating data to get code. There isn't anything wrong with that, but I see a lot more similarities between Luna and Latour's Quartz Composer or Sweeney's Unreal Blueprints than I do with Bret's systems.