3 ms·

Logical thinking and problem solving can greatly benefit from visual representations and feedback. I write code but I often wish the representation was much mor

Logical thinking and problem solving can greatly benefit from visual representations and feedback. I write code but I often wish the representation was much more visual than lines of dense monospaced text with a little bit of colour. Diagrams are often easier to parse and reason about. When trying to understand difficult code or figuring out a difficult problem before writing code I generally draw diagrams with pen and paper. These diagrams are much closer to my mental model than code, and I wish that a lot more of this translation could be automated. "Visual language" doesn't have to mean low-bandwidth interactions.

cormacrelf 7y ago
> 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.
- Firadeoclus 7y ago
  > Once you have a good mapping from thoughts to code, the visual part doesn't add much. Having the visual representation readily available is indeed "great for reading the code and sanity checking". Writing code (here meaning text or visual) involves reading code, both the code you're currently writing and anything that is connected to it. Thus the visual representation is also good for writing code. I'm not advocating a low bandwidth interaction model. I can certainly see why some people might quickly grow tired of Scratch, but I'd argue that's a problem with the specific language/editor, not something that is universally applicable to anything that tries to go beyond "text". Structured editors can beat text editors in interaction speed.

cormacrelf 7y ago

> 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.

Firadeoclus 7y ago
> Once you have a good mapping from thoughts to code, the visual part doesn't add much. Having the visual representation readily available is indeed "great for reading the code and sanity checking". Writing code (here meaning text or visual) involves reading code, both the code you're currently writing and anything that is connected to it. Thus the visual representation is also good for writing code. I'm not advocating a low bandwidth interaction model. I can certainly see why some people might quickly grow tired of Scratch, but I'd argue that's a problem with the specific language/editor, not something that is universally applicable to anything that tries to go beyond "text". Structured editors can beat text editors in interaction speed.