Agreed. It feels like the Max & Pd approach (that Luna seemingly expands upon) is a local maximum. This breaks my heart, because I see much greater potential in the space and it feels readily attainable, but I don’t see that happening anywhere. Worse, I see people dismissing the whole notion of non-textual programming because of how poor the current implementations are.
In all the node-based languages I’ve seen, what we have are essentially text-based languages where you weaken naming — because hey you can just draw an edge, better than introducing & using a name, yeah? So that ties one arm behind your back. Then you have to write your text in these little boxes, making it frustrating to read and write that text. To work with those boxes, you need to constantly jump back and forth between the mouse and the keyboard. And while we’re making the ergonomics worse, how about we render all that text monochrome. Yuck.
But wait — visual languages can have dynamic dispatch, subroutines, code-as-data, arbitrary data structures. Any construct you can put in a text-based language, you can put in a visual language. When you go visual, you’re not limiting yourself in terms of capability. But you might need to be very imaginative to find a way to make the visual/spatial character of your language represent or benefit a given construct. That’s where Max (etc) fall down.
So I don’t think that the complexity issue you described is essential. I think it’s self-imposed by current visual language designers. Perhaps that’s because the handful of visual languages that got traction (and thus the benefit of countless hours of design & development effort) are created for people who aren’t computer scientists. These languages only need to be sufficient for solving a domain problem, not for advancing the art of the visual PL.
If I were making a visual language, I’d lean far more heavily on the word “visual”. There are countless commonly-seen facilities in other non-programming GUI tools that could find a nice home in a visual programming environment:
- Layers, a la photoshop
- Color-with-meaning, a la labels/tags in Finder
- Shapes-with-meaning — eg: using simple shapes to represent types, making it easier to see how data changes as it flows through your system, or what sorts of data goes where
- Animation-with-meaning — Max allows you to enter a step debugger mode that shows when messages move from one node to another, but you could do so much more by (eg) continually animating the shape/texture of edges.
For any notion in elementary graphic design, you can attach meaning. Allowing the programmer to choose for themselves what meanings these notions represent is even more powerful — now we’re in Isomorƒ territory.
The fact that current visual languages are built of monochromatic text, a few box shapes, and a few colors of line, is a tremendous failure of imagination.
There are so many great visualizations of complex systems in films (BS-ness, notwithstanding), and so many great mechanisms for interacting with complex systems in video games (Sim City for goodness sakes, not to mention Zachtronics, Factorio, The Witness…). But I don’t see any visual languages borrowing from the visual language of these more imaginative sources.
Luna is pretty, but it looks like they’re just implementing more-capable primitives in a largely traditional node-language environment. Even the ability to view your code as either a graph or as text is something Max/Pd already did.
At minimum, I want to see people doing for visual languages what Light Table tried to do for Clojure. We can surely go a lot further, but even this would be a good start.