Hi! I'm one of the guys behind Luna. I completely see your point of view. Working with visual grpahs is something you have to learn to do, exactly the same way like writing a code. Unlike code, diagrams are thought more obvious for people without really strong technical expertise. I cannot agree with one of your points - namely that with each use case diagrams would look differently. Nodes have a position on 2D whiteboard - just like text is layouted in a file and displayeb by your favorite editor. The colors in the graph indicate the type of data and all the variable names are just hidden, because you don't have to manually track where they have been used. If you just look at the lines, you instanlty knows what is happening to that chunk of data, no matter if you're processing text, tweets or programming hardware with it :)

Show me how you support error handling or concurrent processes. Heck, show me nested iteration or even basic recursion - then show me all of that, scaled up to real-world complexity.

My suspicion is that as your model approaches the complexity of real-world systems, the visual language you're creating will be unable to efficiently capture that complexity.

Would love to be proven wrong.

People have been doing "real world" (commercial products used by hundreds of thousands of people) in environments like Max/MSP and Reaktor. There are also lots of huge commercial done projects (Hollywood movie CGI and complex behavior) programmed in node based compositing and 3D environments -- heck, people even use Quartz composer for prototyping projects.

Moreover, nothing prevents you from writing code, as they say Luna maps 1:1 to the code they show next to the diagrams.

But when you want a higher level view of the whole program architecture, code can't show you that -- with code you only get some source file or another, and even that rarely all of it in a single screen. A visual representation can, and it can group larger units in single modules (e.g. your packages).

>My suspicion is that as your model approaches the complexity of real-world systems, the visual language you're creating will be unable to efficiently capture that complexity.

One can even make a trivial visual language of 2-3 node types that is turing-complete and can capture ANY complexity. Luna is, of course, far better than that. As for sufficiency, this depends on the level that one wants to play. You might still write code at the lower function level, but if the language makes it easy to group functionality in larger visual units, it would be great for the larger structure, and also great for configurable parts meant for non-coders.

> One can even make a trivial visual language of 2-3 node types that is turing-complete and can capture ANY complexity. Luna is, of course, far better than that.

I don't disagree with you on the first part - that you can make a trivial visual language that can capture any complexity. The challenge is - can a user "visually" parse through the visual representation of that complexity?

I haven't seen any evidence that Luna can effectively do that at scale. Until I do, I remain extremely skeptical.

I would love to prove you are wrong :) I've described error handling in a reply to another question here and we'll update the website later to illustrate it there too. All other stuff like nested iterations or recursions will be shown in our documentation and will be available for alpha testers. But there is no magic involved - I'll shortly describe the mechanisms here too. Each function is a node and each function usage is a node as well. If you are defining function, you can dig inside the node to define the graph of its body. You can use in this graph a node representing usage of exactly this function. I completely understand that textual clarification is not enough here (heh, just proven graphs are easier here! :D), but live demos and examples will be available for alpha testers now.