I wonder if you could use annotations to manage the visuals e.g http://drakon-editor.sourceforge.net/folder-night.png
You'd have an inline annotation to separate the code blocks and generate the visuals so you don't have to maintain/update two places.
Any tool that does that?
Also, integrating different level of complexity using system 1,2,3 (from https://www.amazon.ca/Software-Requirements-3rd-Karl-Wiegers...) to represent user flow diagram in addition to flow charts.
Flow charts get confusing after some complexity. Useless if you want to represent multiple actors + messages. Systems/sub-systems view.
There is a tendency to think of visual programming as an all or nothing. Either we have all text or all visual. As long as it is "Write once, update everywhere", visual tools can be useful in navigating new code bases, obtaining insights and quickly understanding a piece of code.
The problem though is they often require maitenance and get out of date with reality (even if it is comments/annotations)
I installed MacPorts from https://www.macports.org/
sudo port install tk
And it works!!!
Interesting idea for making the structure visible and presumably, helping find corner cases that are not handled. You could presumably build a library using Drakon, and then build an app using the library so that the detail of the code in the library is hidden behind simple function calls.
This reminds me of the proliferation of graphical workflow systems such as BPMN and this nifty Data Mining app called Orange3 http://orange.biolab.si/orange3/
I think we may finally be figuring out how to apply a visual paradigm to coding in a way that works for real production apps.
Go to "Built with Blockly" which includes BBC MicroBit, MIT App Inventor, code.org, LEGO (3rd party), PBS, Minecraft (3rd party), etc.
(And this is someone who's spent most of his professional life working on visual programming systems.)
I have two thoughts around this:
1) A lot of 'simple' source code would generate large, complex diagrams - which are likely not very readable, and brings up the same old decries against visual programming.
2) maybe striving for code that works well when converted to a visual language is a good check for code quality.
(SF has new owners!)
Your comment is a bit analogous to someone commenting "Humm, this looks an awful lot like programming?" on a link documenting a forgotten programming language. Well yes, it's true, but it's a tautological statement.
We even have a tool that you can connect to your repositories and will post diffs of the graphs in FBP DSL as pull request comments:
I'm not a fan of flowcharts but DRAKON is of historical significance. The same would apply to GRAIL.
Other imperative visual programming languages such as Scratch could also be stored in a form resembling a textual imperative language. In other words, the visual element is largely "syntactic sugar".
Dataflow programs can also be stored as text rather than binary, but due to the nature of dataflow, this would be inconvenient to program directly in. This is because dataflow programs are graphs with only a partial order rather than ordered lists like programs in C or Lisp. This means that visual dataflow languages, such as LabVIEW and my own Full Metal Jacket (http://web.onetel.com/~hibou/fmj/FMJ.html) aren't simply syntactic sugar.
There are textual dataflow languages such as SISAL, but these require a compilation step before code is actually dataflow.
You should not be surprised to find that version control systems designed for text in which lines of code are executed sequentially by default is less useful for stored visual dataflow programs. You could still use diff/merge on the stored representation at the function level, but not easily at the line level, because the visual representation doesn't have lines of text and the order might change arbitrarily from version to version.
This is why visual dataflow programs need a visual equivalent of diff/merge, e.g. clicking on arrows to show the order in which changes were made to the graph instead of diff. Work is being done on this, e.g. Austin Henley's Yestercode (for LabVIEW), reviewed here: http://www.felienne.com/archives/5210
I also remember a project management tool that similarly wrote Python code under the hood. And then there is the Talend Data Integration toolkit which writes and compiles Java under the hood. There is a lot of this stuff kicking around these days if you care to hunt for it.
However I think that workflow systems like Apache Taverna and jBPMN are more useful. You still write chunks of code but the framework glues it all together in a flexible manageable way instead of creating a Big Ball of Mud.
(1) Is constrained in a way designed to enhance understanding of the visual flow, and
(2) Directly includes code (in language Foo) in the boxes, rather than text; that is, its a programming environment, not a diagramming language with text that gets converted to program code somewhere else that is maintained separately.
The first item is also a feature of DRAKON by itself.
What? The deps are pretty tame for such a large program.
tcl8.6, tk8.6, tcllib, libsqlite3-tcl, libtk-img
So, for a debian/ubuntu machine:
sudo apt-get install tcl8.6 tk8.6 tcllib libsqlite3-tcl libtk-img
All of this info is at the top of the downloads section: