[seanmcdirmid]

I don't think Bret Victor ever did a visual dataflow language, did he? This doesn't seem like the kind of thing he would do, it is more in the spirit of Quartz Composer (especially in its liveness and explorer) as well as VVVV, among many others. It also reminds a bit of Unreal blueprints in the way it handles completions on results (just draw out from the output, and you get a list of what patches you can bring in to deal with it).

It does seem like a nice replacement to Quartz Composer (well, we have Facebook Orgami now), since Apple isn't going anywhere with that these days (though aimed at data processing rather than graphics and animation).

[wdanilo]

Bret Victor's ideas are a very strong inspiration regarding where graphical interfaces could expand in the future. We strongly agree with his principle, that people need an immediate connection with data they are working on. This principle is one of two foundations on which Luna was actually built. We have described our thoughts in detail in our blog post here: https://medium.com/@luna_language/luna-the-visual-way-to-cre....

[seanmcdirmid]

Bret Victor has written about these kinds of languages before, mainly in his "Drawing Dynamic Visualizations" notes (http://worrydream.com/DrawingDynamicVisualizationsTalkAddend..., talking about what he just presented):

> 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.

[wdanilo]

@seanmcdirmid We are not yet there, but we develop Luna to target EXACTLY these use cases - program modification AND very direct data manipulation. We see Luna as an unified platform for building rich DSL's. An example of such rich DSL is what Bret Victor demonstrated in his talk. You can read more about rich DSL's and what Luna is meant to be in our blog post here: https://medium.com/@luna_language/luna-the-visual-way-to-cre...

Regarding your thoughts, Luna is a fusion of both approaches. When you create and connect nodes, you are manipulating the program structure - you define how data flows between components. However, every node has the ability to display an interactive results visualization and input data widgets. Basically these visualizations and widgets allow you to work directly with data – you can create canvas visualization which let you paint on it, you can create a 3D scene visualization which would allow you to not only inspect 3D scenes but also modify them etc. These visualizations can be displayed below nodes or can be detached to be separate windows and are defined as HTML/js snippets.

Does it make sense to you?

[seanmcdirmid]

I guess at this point, I just see a nice VPL; it seems to have the liveness properties of Quartz Composer, at least, which, as you say, displays an interactive results visualization and input data widgets (though you might have to turn the patch around or mouse over an input pin). It seems to fit into Tanimoto's liveness level 4 taxonomy.

If you have some direct manipulation and gradual abstraction going on, I haven't seen it in your examples or explained in your docs.

[seanmcdirmid]

Also, have you checked out Conal Elliott's Tangible Functionla Programming (Eros) work? It is a bit dated (2007) but explores being more direct in a Haskell-like language.

http://conal.net/papers/Eros/