[zozbot234]

One of the unappreciated facets of visual languages is precisely the dichotomy between easy dataflow vs easy control flow. Everyone can agree that

  --> [A] --> [B] -->        ------>

represents (1) a simple pipeline (function composition) and (2) a sort of local no-op, but what about more complex representations? Does parallel composition of arrows and boxes represent multiple data inputs/outputs/computations occurring concurrently, or entry/exit points and alternative choices in a sequential process? Is there a natural "split" of flowlines to represent duplication of data, or instead a natural "merge" for converging control flows after a choice? Do looping diagrams represent variable unification and inference of a fixpoint, or the simpler case of a computation recursing on itself, with control jumping back to an earlier point in the program with updated data?

Either of these is a consistent choice in itself, but they don't play well together as part of the same diagram unless rigorously separated.

A different point is that some high-level abstractions do have a fairly natural visual representation. This even includes the "functors" and "monads" that are well-known in FP. In general, one should not be surprised if category-theoretical abstractions turn out to be representable in this way. (Many visual languages actually turn this into a source of confusion, by conflating operations on an atomic piece of data with operations on a stream or sequence of singular data points. A stream is a kind of functor, which is why it (with its peculiar operations) is endowed with a simple representation in dataflow. But there are other functors of interest.)

[pharke]

I've always thought that the best solution for disagreement is to simply try everything and then figure out after the fact what works and what doesn't. I don't think there should just be one visual language, we don't just have one programming language and if we did you could bet it would be something terrible. The biggest hurdle is the implementation of the UI, it's hard to make it usable and a lot harder than just putting characters on lines.

[zozbot234]

The implementation of the UI could be made generic. Make a UI that allows for playing with boxes and arrows in the usual visual-language-y way, and ultimately outputs a serialized, optimized representation that can be fed to a compiler-like pass. Then the semantics, and the pre-defined components to go with it, can be defined separately.