I’m curious “where” people think of visual in visu...
# thinking-together
i
I’m curious “where” people think of visual in visual programming being. For context, I spend a lot of time in tools like Houdini, Solidworks, Cavalry, and After Effects. Some of them have more access to computation than others, but the biggest difference between those and Processing or threejs is a large “standard library” of functions. On the other hand, building a website with live feedback or scripting in a REPL seem like a very different experience from just writing the same code in notepad. I wonder if visual programming is all just “debug views” rather than the specific presence of a GUI. And if so, what does that mean for generalized visual languages or environments?
g
interesting.. I think I understand what you're referring to Not sure it's just about "debug views" as you can achieve visual debug views using conventional coding with external tooling - such as https://appmap.io For me, the fact the "building" phase being visual has big advantages too Need to ponder over it a bit more 🙃
j
I think part of what you're pointing to is what many would call "liveness" in the programming environment, which is orthogonal to whether the notation would be considered "visual" (itself a vague thing, usually meaning "not exclusively text based").
e
I don’t think the question of liveness, as Jack frames it, has a 1-size-fits-all kinda answer. For me, the draw of programming systems that offer more than the normal REPL loop, or compile cycle, is that they empower novel, or deeper understandings of how a program functions. This can take on so many different forms, and varies depending on the goal and the audience. I think different sorts of liveliness in a programming system can help to promote different sorts/scales of understanding. • do you need folks to understand your program from top to bottom? • are you using the program to communicate data external to the program itself? • does the program facilitate the creation or processing of something? Is there a representation of the thing being worked on that is more intuitive than whatever the default mode is (JSON, binary data, etc.)
Another way to frame it is through point of contact — as the person using a programming system, am I manipulating the live interface, or am I just viewing it? Both?
g
not just that - people approach manipulation (and viewing, but lets focus on manipulation) with different intents and as part of different workflows. Whether my intent is • to hunt down and fix a bug that happens a small proportion of the time • track through and identify the source of an error that happens all the time • perform a complex refactoring to improve maintainability • read-by-refactoring • add tests after-the-fact • write tests beforehand • or just plain fix up a few things that are annoying me personally under the radar Each of these could merit completely different - and individually personalizable - views onto the same system
i
Points of contact might be what I was thinking about. Maybe I used “debug” too broadly. (Sorry to keep giving 3D examples) In Houdini you have: • Output display: a viewport (destructive edits) and attributes pane (read only) • Multiple timelines for changes by speed or value • nodes and boxes (similar to a dependency tree or control flow) You can choose what visualizations to use, but most manipulation happens in an additional Properties pane. But they all still work while writing VEX (C/C++ inspired scripting), which is what set of the “its all debug view” idea.
a
I've never encountered the term "visual programming" as meaning anything other than the code itself being in a visual format. That's quite distinct, at least in principle, from representing the output or internal runtime state visually, which seems closer to your examples, and from the general concept of "debug views". (You could presumably define a language so its code and runtime state can be expressed with the same visual notation, but absolutely don't have to)
i
So visual, not liveness, would be something like Scratch or Piet?
a
Piet is not usually the first example that comes to mind, but definitely Scratch, at least in my understanding of the term. :D (For anyone who hasn't encountered it: https://esolangs.org/wiki/Piet)
j
@Ibro Your "points of contact" examples make me think of projective editors that can show the same thing (code/state/whatever) multiple ways 🤔
i
Oh 👀 have you got any links?
j
enso.org for example
j
@Ibro a bunch of stuff around this topic starting at ~35:00 minutes into the talk I gave at StrangeLoop last year: https://jackrusher.com/strange-loop-2022/
u
Reallt good ideas in this thread. Just wanted to add that visual programming in the tools you mentioned is also about discovery - a lot of nodes have a bunch of parameters and it invites you to tweak them to see what happens.
i
@Ulysses Popple That’s a good point. It translates well to text programming too. Arguably, I’d even say Typescript + a live server is more similar to the Houdini example than what happens with just a single view fullscreened