[hinkley]

When this last round of discussion of visual programming happened I had a minor epiphany.

For a little background, I’ve maintained that visual programming goes absolutely nowhere until we have visual diffs that work (work as in workflow). I’ve been saying that since before the UML Trough of Disillusionment kicked into high gear. Without diffs, without analysis, we are going nowhere fast. Almost every other link of the lifecycle is still intact with visual code but focusing on an editor without diffs breaks the chain. There’s no producing and maintaining commercial grade software without it. It’s either toy programs, or absolutely heroic effort, and what else could you have done with that much energy?

The epiphany was this: motion detection has been a feature of digital video since at least the MPEG days. Someone with a background in video compression needs to tackle the problem of doffing visual code. Figuring out how the code should look (mechanical sympathy) to facilitate this.

[bccdee]

> Without diffs, without analysis, we are going nowhere fast.

The victory of plaintext coding over visual programming is another example of worse is better. Semantic, language-aware diffs exist, but I see them much less frequently than dumb plaintext diffs. Intelligent code search exists, but in many cases grep is just as good. IDEs come with very advanced refactoring tools, but I still prefer to refactor using vim macros.

When we write code in plaintext, we're expressing our code in a lower level of abstraction with really great tooling. Doesn't matter if it's java or yaml or something custom—plaintext tools work on all of them. Visual programming languages can't do this. There's no language-agnostic vim or git for visual programming. Even if we wanted to invent sort of unified language-agnostic visual programming abstraction, the ecosystem isn't there, and there's no guarantee it'd get adopted.

So I think plaintext will remain king for the foreseeable future. Visual tools have to use human-readable, human-editable plaintext as their source of truth, if they want to succeed.

[datavirtue]

I think of it like comparing cuniform and hieroglyphs to phonetic alphabets.

The pictures are easier to learn and use but they are not as expressive and precise as the more abstract text. Text is a marvelous innovation. The fact that most people on the planet can communicate complex ideas and emotions as well as program machines with it (in many different dialects) is mind blowing.

Using pictures to program feels like a regression.

[lhamil64]

I work with a few proprietary languages and many tools don't have semantic information but it's still tolerable as plain text. I suspect I'd be stuck using awful tools if these were visual languages.

[TYPE_FASTER]

The challenge with visual programming from my perspective is how to get the abstraction level just right. It's like Terraform/HCL modules: too granular, you wind up passing in a billion parameters, and the module adds little value. Too high-level, too many assumptions, also adds little value.

I have an idea that I think would be suitable for visual programming. Every time I think about it, I come to the conclusion that first you need a DSL, or at least a JSON Schema or something.

If you have a DSL/schema, then you also have a way to diff.

Then, you implement your visual programming environment, and visual diffs turn into effectively communicating those differences visually. Faded color to indicate a deleted node and connector, bold parameter and value to indicate a change, etc.

[kmoser]

I think this idea has promise but I wonder how it would work when many of the visualizations I create to help explain logic wouldn't fit neatly into a DSL/schema. For example, I might use red in some places to refer to data from a particular client, or underlines to indicate constants, or arrows to indicate things that are related from a business perspective but not data or logic flow. I guess this could be standardized, but that almost defeats the purpose of having the computer do the heavy lifting.

In other words, not only does understanding these diagrams assume a ton of knowledge in the problem domain, but the crude tools at hand for creating them (lines, words, symbols, shapes, colors) can be repurposed in so many ways by different people and different projects that I don't see how generic motion detection will be able to detect high level changes. Sure, detecting changed nodes and descriptions might be easy, and possibly useful, but I think there will never be a substitute for human comments like "removed XYZ because the boss said so" or "renamed foo to bar because of IRS regulation so-and-so."

[turtles3]

Having spent an unhealthy amount of time thinking about this, I think it's even worse than an abstraction _level_.

I suspect that the fundamental problem with visual languages is that you have to reify _something_ as the objects/symbols of the language. The most widely used text languages tend to be multi-paradigm languages which have significant flexibility in developing and integrating new abstractions over the lifetime of projects and library ecosystems.

It's not clear to me how this can be overcome in visual languages without losing the advantages, and instead ending up with a text language that is just more spread out.

[eternityforest]

I think the solution is just to stop trying to allow Real Programming in visual languages.

Make the abstractions purely high level, and let people write Python plugins for new blocks with an app store to share them.

Visual can easily provide enough flexibility for gluing blocks together.

IFTT, Excel, and lots of others do it perfectly well.

The issue is programmers like to program. Mostly they like "programming in circles", making little apps to help make more other little apps to explore ideas.

They see it mathematically, as a human centered activity all about understanding, while users see machines as a box you put stuff in to make it not your problem anymore.

They're always talking about empowering users to create their own fully custom ways of using computers... But.... I like apps that have a canned, consistent workflow that I don't have to fuss with or maintain or reinstall.

Software like Excel has the appropriate amount of power for working on a project that uses computers but isn't really related to programming or done by developers.

[hermitcrab]

>The challenge with visual programming from my perspective is how to get the abstraction level just right.

It is a big problem if you are trying to develop a genric visual programming language. But much less of a problem if you restrict the problem domain to something like data processing, signal processing or image processing.

[1ByteAttaTime]

Node-Red "Projects" feature has version control features that include a diffing tool (running on git). I've tried UML code generators in the past and was a skeptic of NR at first, but for headless applications subject to recurring change or needing high-level access to complex stacks (like video compression) its really impressive. Don't get me wrong, its still glorified NodeJs and not for every job but its worth a peek...

https://nodered.org/docs/user-guide/projects/

[DonaldFisk]

If functions are represented as directed graphs, it would be better and simpler to compare their graphs instead of how they look on a computer screen.

[sitkack]

Animation solves this with onion skinning and I can visualize a number of ways you could use onion skinning and similar to diff two or more graphs.

https://en.wikipedia.org/wiki/Onion_skinning

[eternityforest]

We already have a good way to do visual diffs: Just store the visual code as text and use Git.

Anything else breaks the ability to use Git, or requires adding plugins which you might have to compile yourself or something, and I'm a big fan of just using Git and having VCS be a solved problem.

If this then that rules map nicely to LISP-like expressions in JSON or YAML.

Freely positionable elements are a pretty bad idea for a lot of things. They make extra noise in the diffs and can't be automatically formatted in a fully satisfying way, short of making an AI for it, plus they can't be edited easily on a mobile device, and they can easily become a literal picture of some spaghetti.

[jarsin]

Unreal has visual diff. It's interactive so you can click on some node and it will take you to the diff in the other file.

I honestly never use it because I only use unreal alone, so can't say how good or bad it is in real world project.

[hinkley]

You know of a good demo video?

[jarsin]

High level overview with source control in unreal https://youtu.be/YKMDdtX-8gM?t=1025

Basic demo https://www.youtube.com/watch?v=XYZsvouytVQ

[limit499karma]

> (mechanical sympathy)

I get what you are trying to convey but that usage of the term is not helpful in the general case as it confuses what mechanical sympathy actually means.

Mechanical sympathy is simply this: abstractions that acknowledge the underlying embodying stratum of a dynamic construct. In code, that translates to software that attempts at harmonizing the software abstraction with the operational characteristics of the underlying computing device.

[terr-dav]

Another place where visual diffs would be indispensable is file-system organization. Each node in a file tree contains another graphable data structure: permissions! Especially on network shares where user groups are more common.

As long as there's some structured record of changes made to permissions and structure, those can be visualized.

[kagevf]

GitHub has had diff for images for years, and there's a web automation testing (think: Selenium) vendor called Aplitools that takes snapshots of web pages and diffs those too.

I don't know of any non-proprietary tools, but at least the tech is out there.

[geor9e]

The thing about visual programming, at least a lot of them, is they store the data as an ASCII version under the hood, but render and edit it visually. So for those, normal diff still works, and the renderer can highlight things accordingly.