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