> more of this translation could be automated It seems to me that when creating a visual programming language for a particular class of programs, you probably

> more of this translation could be automated It seems to me that when creating a visual programming language for a particular class of programs, you probably find that making this translator is the same hard mental work that would let you make a text-based programming language instead. Once you have a good mapping from thoughts to code, the visual part doesn't add much. I was talking to a non-programmer recently who had tried Scratch and gotten tired of the visual layer very quickly. It's rare to see a visual -> code mapping that retains value after you've used it the first time, i.e. value beyond teaching. I like the general idea of going the other direction, from code to diagram. I'm not interested in editing the diagram, but it's great for reading the code and sanity checking. But it doesn't have to be the actual code. A great many projects would benefit from having a GraphViz generator instead of hundreds of printlns. I was talking today about adding a GraphViz .dot visualisation to the salsa-rs incremental computation database, because I was reading the documentation on garbage collection and just wanted to see it in action. I know the rustc folks have been doing this for ages. I think in addition to generating graphviz, it would be cool to have a log viewer that can render it. $ my-program normal logs viz:"digraph {\n0 -> 1..." more normal logs ^C $ my-program | logviz normal logs more normal logs ... and a window pops up that animates changes between each graph that appears in the logs. Or even better, a tool that takes regular printlns of edges, nodes, etc, interprets them as an append-only variant (with deletion, etc) of graphviz, and assembles them into a graphical representation that changes on the fly. So you don't need to have a graph implementation in every language you want to do it with.