brainstorming dataflow language visualizations

Hi everyone,

I am having trouble being creative. I am trying to find alternative visualizations for dataflow languages that would allow a programmer to program as quickly and efficiently as a text-based language. A diagram is just not productive enough for serious coding. Does anyone have any suggestions or ideas on how to do this?

My end goal is to find a language that can represent non-linear, conditional sequential execution for imperative languages in a way that is continuous without having to diagram like a dataflow language does.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Middle ground?

What if folks programmed via ASCII but visualizations were automatically generated and updated as the programming went along, and if the diagrams were editable and would update the ASCII in turn? (I know this is done for some GUI tools / IDEs with greater and lesser success.)

that brings up an important note...

...the system basically does have to be a keyboard typing input to be quick and productive. I guess I should explain myself better.

Normally you would write something in a functional text-based language like so:

int X(int I) {
int B(int J) = 2-3*J+4;
} = I*B(I) + Sum(1..5) + B(I)/2;

Where the function B (that returns an integer type) is a closure inside the function X.

This function X, has an irregular dependancy, meaning that if both X and B were parsed into a tree, the tree structure would be irregular, becaues X refers to B twice. B would branch off to two places of the tree of X. In imperative programming, one would make use of a temporary variable to store the result of B(I) to eliminate redundancy:

int X(int I) {
int B = 2-3*I+4;
result = I*B + Sum(1,5) + B/2;

For imperative languages, this creation of a variable is syntactic overhead that shouldn't be needed using the functional approach.

Now here is the idea: A dataflow language can represent the tree structure itself, which is not disconnected into parts. The structure of a dataflow language is continuous, eliminating the need to name a variable/closure and reference it. From the point of view of a dataflow language, not only is variables a sin, but so are (at least) these kinds of closures. This is what I am trying to achieve--to eliminate even more verbosity, while allowing one to program irregular dependancies in a continuous, rather than a broken up fashion, and the same will be true of flow of execution, which will not be restricted to a one-way, sequential order, but can be irregular (like a flow chart). This is where the discrepancy comes in between just typing in code, and the visualization.

This could go in so many

This could go in so many directions I'm not sure what kind of advice to give you. First, you might want to look at Jonathan Edwards's Subtextual language, which does away with names all together in a language with a structured programming editor. In any language, there is a balancing act between abstraction (hiding details) and directness (code resembling program execution), and you often have to tradeoff one for the other. Subtextual provides a way around this.

You might want to also look at Simony's intentional programming project, where imperative C# code can be visualized and edited in different ways (e.g., as a flow chart or spread sheet).

In my own SuperGlue language, which is basically a textual data-flow language, I've found closures (and functions!) to not be very usable and have instead replaced them with declarative (quantification and connection-based abstractions). Data-flow programming is very different from imperative or even functional programming and benefits from different core abstractions. The nice thing about SuperGlue is that a rule parameterized by universally quantified variables placed anywhere in the code can affect the execution of the entire program.

representing DAGS with strings

It was not until I started reading Iverson's papers that I realized that he often used phrases of the form


which these days we'd tend to write in the Landin tradition as

X•X where X = Y

Now, using naming to indicate sharing in the graph structure doesn't immediately solve your problem, even if no actual closures or temporaries need be generated. However, J hooks and forks were a later attempt to capture common branching patterns in code graphs, and express them without needing to invent names. (it is unclear to me how successful J is in practice. I think that Whitney has said (as implemented in K) that he finds composition to be far more useful than the J sharing patterns)

A halfway point on the spectrum from pointing (as in Subtext?) to naming might be to have a common set of pronouns. English speakers have former and latter, even this, that, and those. American Sign Language apparently has a pronoun structure by which a noun phrase is signed in a particular area, and subsequently referred to by location. To some degree, APL had this as well, for the standard α and ω (left and right arguments to an operator) could be duplicated several times in a definition.

As an example, I believe the APL definition of counting sort would be


in which the lexical order for the sort is duplicated, but all the names are forced by the conventions of the language.

visual programming

I've been keeping an eye on interesting visual environments for programming. As you say, it is difficult to do any serious programming using existing systems. Sean McDirmid (too) breifly discusses* one of the challenges of visual programming:

"Quartz Composer can abstract over mutable state but does not support abstraction over data structures very well; e.g., multiplexor like components are used to deal with iteration in a very visual but also very tedious way. Without the ability to abstract over both space and time, simple languages are often severely constrained and do not feel like real programming languages."

(Quartz Composer, by Apple, is one of the more widely distributed visual programming environments)

*"Turing Completeness Considered Harmful: Component Programming with a Simple Language"

There are non-visual dataflow languages

Take a look at languages like Lucid Synchrone and Esterel. They are dataflow languages with a textual syntax. This may give you ideas.

Check out Toontalk

The underlying formalism which Toontalk visualizes is concurrent committed-choice logic programming, of which dataflow is a straightforward subset.

Very short example

I've been experimenting with dataflow representations for some time. I have one small example on my site now that may be worth looking at.

Scroll down to 2007.01.06 and give it a look. It might not make a lot of sense, but perhaps it will give you some ideas when it comes to avoiding the usual mess of lines. Unfortunately, to create a representation that is both efficient to enter and doesn't rely on naming is extremely difficult.

Please share any progress you make on this... It is something I've been bashing my head against for years without too much to show for it. I'm now of the opinion that employing dataflow techniques in more traditional languages is the way to go for situations that can benefit from such an approach -- It is generally more useful at higher levels of abstraction anyway.