It is often believed that programming languages come in only 2 forms: (1) textual and (2) visual.

Visual Programming has become to mean pixel-based image processing.

I have implemented an intermediate form of programming.  Something between (1) textual and (2) pixel-based image processing.[1]

I call it DaS – Diagram as Syntax.  It is diagrammatic programming.  I used to call this “visual programming”, but that phrase has come to mean something else, something much harder to implement.

I backed into a number of design principles.  I will do my best to summarize them below...

The canonical form of “visual programming” - which I call DaS – is the box-and-arrow diagram.  It is a network diagram wherein nodes are functions instead of full-blown computers.

Most attempts at implementing box-and-arrow diagrams have failed (as far as I know).  Most attempts at “visual programming” have failed (as far as I know – visual programming can produce pretty pictures, but do not address PLs).

I have been successfully using box-and-arrow diagrams in production since the mid-1990’s.  FBP[6] has been using box-and-arrow diagrams since the 1960’s.  UNIX® pipelines are a degenerate form of box-and-arrow-diagrams.

Why have most attempts at box-and-arrow diagrams failed?


Box-and-arrow diagrams do not work well in the sequential paradigm.

All of the working instances of box-and-arrow diagrams – that I know of – treat boxes as being concurrent components and treat arrows as pipelines of concurrent messages between (concurrent) components.

UNIX® pipelines and existing implementations of FBP use heavy-weight threads to implement concurrency.  I implemented the concurrent paradigm without using threads.  I used something like closures.

[1] “Visual Programming” also meant, for a while, software development using GUIs. MFC and Visual BASIC were touted as “visual programming”.

[2] Here, I am using the word “glyph” to mean “atomic graphical symbol”.  See also  Unlike character glyphs, atomic graphical elements are not fixed size, but, like character glyphs they can be bound to a single input gesture (e.g. a keystroke).  There are not many of these kinds of glyphs in any given notation (e.g. about 3).

[3] See my essay “DSLs - The Future of Computing”

[4] Design Intent

[5] See my essay “Divide And Conquer”

[6] <ref to FBP>

[7] See my essay “Concurrency is a Paradigm”