3 ms·

I think the main issue for programmers is VCS, and the associated tooling like diffs. With git + code, you have an easy way to modularize, diff, collaborate and

by klabb3 4y ago

I think the main issue for programmers is VCS, and the associated tooling like diffs. With git + code, you have an easy way to modularize, diff, collaborate and review. In these other professions, you mostly work alone or go through the painful process of working together on the same project. This shouldn't be impossible for flow-based tools, either by making them collab based (like figma) or by having multiple representations (declarative code and visual - possibly by having visual be read-only). Flow based programming already have a straightforward and imo excellent path for modularization (which is the only known way to deal with software complexity). I would love to see flow based programming combined with individual components written in conventional languages. Regular code is clearly superior for many tasks, so flow should be applied between components, and not be too granular. Another challenge is meta-programming. If you need to produce components at runtime, you would naively lose visualization and other benefits. So more research and idioms are needed to really present a coherent system that maintains a similar DX when that extra flexibility is needed. Still, I'm very bullish on medium-term applications of flow based programming within software design. At least for me, it has some absolute killer features; such as understanding existing systems, mapping to my mental model better and spotting bottlenecks and inconsistencies much earlier. I already use pencil-and-paper flow diagrams for software design, but resort to conventional code when implementing.

bj-rn 4y ago
Do you know vvvv gamma[1][2]? It's a visual programming environment for the .Net ecosystem. It's documents are saved in a XML format and they have build a visual merge / diff tool that works quite well. The strategies it applies are explained in detail in the readme of the repo[3]. [1]https://visualprogramming.net https://visualprogramming.net [2]https://thegraybook.vvvv.org https://thegraybook.vvvv.org [3]https://github.com/vvvv/MergeVLDocs https://github.com/vvvv/MergeVLDocs
- bmitc 4y ago
  This highlights the crux of the issue. The problem is not that visual programs are inherently resistant or impossible to being compared and merged. In fact, because a lot of syntactic and semantic information is built into the representation, it often becomes more clear when doing comparisons. The actual problem is that existing tooling, like Git, are myopic in that they assume all programs should have text-based representations. The problem is that the status quo does not scale to visual programs and not the other way around. Thus, visual tooling for comparison is currently bespoke for particular environments, like that of vvvv or LabVIEW, and are usually hampered because of things like Git. There's a reason why game and art studios often use Perforce and Plastic SCM rather than Git, and it's because those studios have comparison needs that do not revolve around pure text.
  - ryukafalz 4y ago
    It feels like this should be solvable though. I’m reminded of this which was posted very recently: https://www.fast.ai/2022/08/25/jupyter-git/ https://www.fast.ai/2022/08/25/jupyter-git/
    - bmitc 4y ago
      Definitely solvable! People just got to work on it like they have text-based diffing tools. I'm trying to, but I am slow. For visual languages, the problem mainly lies in graph and constraint algorithms, something I'm trying to come up to speed on.
  - wizofaus 4y ago
    Is the ability to show a non-text-based diff that related to how a source control system works under the hood though? Sure, a text-based diff tool may use some of the same underlying algorithms to determine what the differing lines are, but I wouldn't assume they have to, and usually have options to do things line ignore case/whitespace/line endings/ formatting or show mid-line (even per character) differences that go beyond how git itself calculates diffs. A top level diff-tool that can proxy out to file-format specific tools would seem to fit well enough into the git toolchain. It's having them integrated into something like bitbucket or github for PR reviews that would be truly powerful.
    - bmitc 4y ago
      That's a good point. The issue may simply be one primarily of framing in that text-based diffing and merging tools were not natural, so to speak, but had to be built. And even now, they're not great. I'm constantly irritated by text-based diffing tools because they barely understand anything beyond lines of text. I'm interested to see more semantic diff and merge tools built out. Regarding source-code control, I think it's a problem mainly of Git and not tools like Perforce or Plastic SCM which handle binary files that change over time better. It's also an issue for things like GitHub, which as far as I know, does not provide any hooks for custom diffs to be viewed in the browser.

by klabb3 4y ago

bj-rn 4y ago

Do you know vvvv gamma[1][2]? It's a visual programming environment for the .Net ecosystem. It's documents are saved in a XML format and they have build a visual merge / diff tool that works quite well. The strategies it applies are explained in detail in the readme of the repo[3]. [1]https://visualprogramming.net https://visualprogramming.net [2]https://thegraybook.vvvv.org https://thegraybook.vvvv.org [3]https://github.com/vvvv/MergeVLDocs https://github.com/vvvv/MergeVLDocs

bmitc 4y ago
This highlights the crux of the issue. The problem is not that visual programs are inherently resistant or impossible to being compared and merged. In fact, because a lot of syntactic and semantic information is built into the representation, it often becomes more clear when doing comparisons. The actual problem is that existing tooling, like Git, are myopic in that they assume all programs should have text-based representations. The problem is that the status quo does not scale to visual programs and not the other way around. Thus, visual tooling for comparison is currently bespoke for particular environments, like that of vvvv or LabVIEW, and are usually hampered because of things like Git. There's a reason why game and art studios often use Perforce and Plastic SCM rather than Git, and it's because those studios have comparison needs that do not revolve around pure text.
- ryukafalz 4y ago
  It feels like this should be solvable though. I’m reminded of this which was posted very recently: https://www.fast.ai/2022/08/25/jupyter-git/ https://www.fast.ai/2022/08/25/jupyter-git/
  - bmitc 4y ago
    Definitely solvable! People just got to work on it like they have text-based diffing tools. I'm trying to, but I am slow. For visual languages, the problem mainly lies in graph and constraint algorithms, something I'm trying to come up to speed on.
- wizofaus 4y ago
  Is the ability to show a non-text-based diff that related to how a source control system works under the hood though? Sure, a text-based diff tool may use some of the same underlying algorithms to determine what the differing lines are, but I wouldn't assume they have to, and usually have options to do things line ignore case/whitespace/line endings/ formatting or show mid-line (even per character) differences that go beyond how git itself calculates diffs. A top level diff-tool that can proxy out to file-format specific tools would seem to fit well enough into the git toolchain. It's having them integrated into something like bitbucket or github for PR reviews that would be truly powerful.
  - bmitc 4y ago
    That's a good point. The issue may simply be one primarily of framing in that text-based diffing and merging tools were not natural, so to speak, but had to be built. And even now, they're not great. I'm constantly irritated by text-based diffing tools because they barely understand anything beyond lines of text. I'm interested to see more semantic diff and merge tools built out. Regarding source-code control, I think it's a problem mainly of Git and not tools like Perforce or Plastic SCM which handle binary files that change over time better. It's also an issue for things like GitHub, which as far as I know, does not provide any hooks for custom diffs to be viewed in the browser.