Can you explain how this is not 'visual programming'? The interface seemingly allows for arbitrary code to be written and then graphically arranged in a dataflow-like format. If you mean that the fundamental elements of 'code' are the text inside each block, how is that fundamentally different than if each block was a black-box whose functionality was implemented using more blocks?

The emphasis of this project seems to be text based coding and visual description of dependencies at the cell level. Visual programming, at least according to wikipedia, refers to "manipulating program elements graphically rather than by specifying them textually," which this project does not do.

Not really in disagreement. However, I think that there is more than one level of granularity to this project. If you were to step back to the level where someone has a 'library' of these blocks of code (which seem to be able to present a 'black-box' style presentation) and then visually placing them and connecting the inputs and outputs of those various blocks is essentially visual programming within the meaning of the standard definition, like from Wikipedia.

The graphical elements themselves contain code (all visual programming systems work this way, even if the code is hidden). That's how new program elements are born.

Visual workflow languages work in a bunch of different ways. Nodes, in Blender, is a visual programming environment. Blockly is a visual programming environment. Those nodes in scratch have code behind them!

Dependency relations are very much "program elements".

This is literally visual programming. Nodes connected with edges, nodes represent execution models that take inputs over in edges and write outputs over out edges. Everything right there in the video.

The about page describes it as

> An open-source tool for visual and modular block programing (sic) in python

If they wanted to distance it from visual programming, they have done a bad job at it.