3 ms·

I don't understand your ideological point. The editable representation has no bearing whatsoever on the storage representation of a program. There is nothing pr

by GuiA 10y ago

I don't understand your ideological point. The editable representation has no bearing whatsoever on the storage representation of a program. There is nothing preventing you from having a visual programming environment where everything is just ASCII text under the hood.

lawpoop 10y ago
In fact, that's literally what every GUI is. The graphics system just represents ascii characters. Hell, even a terminal is basically the same thing!
qwertyuiop924 10y ago
Actually, I'd be totally cool with that, and there are a few pieces of software that do it. But it's not all that common.
bergie 10y ago
Exactly. With Flowhub we're persisting the graphs as JSON, but there is a way to convert them to a human-readable/writable DSL: https://github.com/flowbased/fbp https://github.com/flowbased/fbp 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: https://github.com/jonnor/fbp-diffbot https://github.com/jonnor/fbp-diffbot
lmm 10y ago
In theory it would be possible to have a visual programming language that had a readable stored representation with meaningful diff/merge/blame. But in practice I've never seen one.
- DonaldFisk 10y ago
  DRAKON represents programs as flowcharts, and there's no reason why the underlying representation couldn't just be C, Python, or some other imperative language, and there's no reason why C or Python originally written in vi couldn't be represented in DRAKON. 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 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 http://www.felienne.com/archives/5210

by GuiA 10y ago

lawpoop 10y ago

In fact, that's literally what every GUI is. The graphics system just represents ascii characters. Hell, even a terminal is basically the same thing!

qwertyuiop924 10y ago

Actually, I'd be totally cool with that, and there are a few pieces of software that do it. But it's not all that common.

bergie 10y ago

Exactly. With Flowhub we're persisting the graphs as JSON, but there is a way to convert them to a human-readable/writable DSL: https://github.com/flowbased/fbp https://github.com/flowbased/fbp 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: https://github.com/jonnor/fbp-diffbot https://github.com/jonnor/fbp-diffbot

lmm 10y ago

In theory it would be possible to have a visual programming language that had a readable stored representation with meaningful diff/merge/blame. But in practice I've never seen one.

DonaldFisk 10y ago
DRAKON represents programs as flowcharts, and there's no reason why the underlying representation couldn't just be C, Python, or some other imperative language, and there's no reason why C or Python originally written in vi couldn't be represented in DRAKON. 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 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 http://www.felienne.com/archives/5210