Discussion: visual programming code style

[jonnor]

With NoFlo UI, we are creating a visual programming language, or possibly a family of them. For that reason, I think we should discuss together a bit how we think such a language should look (be) like.

I think a programming language must serve two goals, the first more important than the other:

1. Communicate to the human readers what the actual and intended function of the program is
2. Communicate to the computer such that it can realize the program

Some open style questions I have for a visual language based on node-graphs:

• When to move a subgraph into a component of its own
• When and how to group related components
• How components should be laid out in relationship to eachother (distances, relative sizes, orientation)
• If and when to use other visual representations than nodes for a part of the program. When to use component-specific, domains specific or other general-purpose visualizations (finite state machines for instance)

[jonnor]

What I am implying here is that Noflo UI as a tool must allow for and encourage good code style, otherwise it will severely limit its own usefulness for non-trivial programs.

More style question:

• If and when to use busses or similar grouping functionality for edges
• If and when to use "portals" (named or symbolic) for connecting edges[1]
  1. Example from Electronics Enginerring include connections made to Gnd,Vcc,Vdd

[bergie]

On visualizing component state: in theory components could change their icon based on the state

[forresto]

Playing with yed #53 I'm hopeful that graph layout can be automatic. Grouping will be equivalent to comments, and help with graph autolayout.

Would be good to see how it handles graphs in other domains.

[Usnul]

FBP is not new (as many here should know, if they looked at John's work). There are many commercial implementations of this "paradigm", some that date back before many of us were born. I would suggest borrowing ideas from such products on styling guides. If you need examples just go on wikipedia, there are too many to list. As jonnor mentioned - there are tools that don't necessarily represent FBP paradigm, but still deal with large graphs represented with block/edge diagrams such as those used in electronics, maybe pick a few and steal their ideas (ones we can get away with claiming to be "common" knowledge or which were not patented/copyrighted). After all, that's what great engineering is all about - stealing other people's ideas if they are any good! :)

[bergie]

@Usnul yep, we're definitely looking at various nodal editors out there for inspiration. However, one of the reasons that FBP hasn't succeeded as a mainstream programming paradigm is that nobody has done the "right" execution of it yet. Think of pre-iPhone smartphones...

[Usnul]

what of labview, simulink, salesforce? they are obviously doing something right :)

[forresto]

Quartz Composer and Pure Data are venerable in their respective niches as well. We don't need to diminish their success.

The theory is that JS and our FBP protocol will bridge many niches. Our UI will run everywhere.

From there, we'll see.

[jonnor]

@Usnul: Thanks, was not familiar with Salesforce visual programming. Keywords to find it seem to be "visual worflow", "flow designer": http://help.salesforce.com/HTViewHelpDoc?id=vpm_designer_ui.htm&language=en_US