Further on node-based UIs, and actually looking for judgement for a change: does anyone else find themselves mainly frustrated by the layout problems, such as... • frequently needing to move sets of nodes around to make the layout more comprehensible/memorable • no easy way to add nodes in the middle of a flow without having to reorganise • zooming out far enough to get a good sense of the overall layout leaves you unable to read any labels ... and how often these UIs just leave these problems as exercises for the user, without any automated assistance? I love the idea of node-based code, but in practice I've yet to see systems like this that are as readable as well laid-out and formatted code. Don't get me wrong, I think most traditional textual code could be laid out and formatted much better too, but in general I find it easier to scan and understand the top-down flow of textual code than nodes. Maybe I just haven't seen the right tools which do this better? Or maybe I'm in a tiny minority? What do folks here think? (And please forgive me if this conversation has been done to death in this Slack already, I've not seen it.)

I don't know that I'd say I'm "mainly frustrated by layout problems"... but that's largely because I'm also frustrated by so many other things. 😅

Have you listened to @Ivan Reese’s hest podcast? He talks about all these kinds of problems https://ivanish.ca/hest-podcast/

@Jimmy Miller I haven't, thanks for the tip! Any particular episode, and is there a transcript?

There’s no transcript. I’d definitely recommend starting from the beginning personally. It is definitely a progression of Ivan exploring what he wants out of hest. But I’ll also let him reply since he is currently typing

@yoz I'll butt in — I don't remember which episodes contain which thoughts, and yeah there's no transcript, sorry. But this notion that the interfaces to existing visual programming tools are dreadfully lacklustre is a significant motivator of my work. In addition to the podcast, I've done some writing about these things, and would love to dig into this subject with you. One quick hit — you mentioned "these UIs just leave these problems as exercises for the user, without any automated assistance." I'm strongly of the opinion that, say, force-directed layout of nodes is directionally wrong. But I'm also in favor of assistance. Max/MSP has a couple of "clean up my layout for me" tools, for instance, which are fine on principal but (last I used them ~3 years ago) woefully underdeveloped. I long to see someone take the approach to a visual programming interface that, say, Steve Ruiz took with tldraw, or @Elliot took with his carrot editors — sweating every tiny detail of the interactions, trying to make something that feels so right it disappears.

In text you also frequently rearrange lines of text, split them to multiple lines extract a function, rename variables etc. All changes that have no effect, just to make it more pleasing, more readable. Arranging nodes is the same. It actually helps me to think and get into the flow. As for zooming out, even if I can't read any labels, I find it easier to read a graph, as I can quickly spot a "neighborhood" and be reminded what I've done there. While a text minimap is less distinct. But you do have to zoom out more often, as nodes are less compact.

I'm wary of going deeper into the issues I perceive with VPLs given my lack of experience with them. I'd love to see some examples of really good VPL code that shows the strengths of the format.

No it doesn't help with a graph I haven't seen. Different people may prefer different layouts even. Just like in textual code. To understand a graph, live coding is what helps the most. That is really the number one reason nodes and wires even exist and are so popular! Jump into every part of a program and see and edit the data. I take that over any inconveniences of nodes and wires. (for some domains?)

@yoz have you played with Max/MSP? It's one of the more polished node-wire GUIs out there. They've done some good work to support lots of different editing interactions.

I’m in the minority here, but, FWIW ... I conclude that VPLs are a much better way to program than using text-only programming languages. After all, text-only PLs are, but, 1950’s caveman IDEs for programming. I conclude that auto-layout is downright evil and counter-productive. ... my thoughts ... https://guitarvydas.github.io/2023/11/19/The-Meaning-of-Layout.html

I’m in the minority here, but, FWIW ...

I'm not sure about that. I even sympathize with a lot of this from a certain perspective, despite generally disagreeing with most of your conclusions. Not gonna nit-pick everything, but can't resist this one:

text-only PLs are, but, 1950’s caveman IDEs for programming

yeah, like scratching surfaces with pointy sticks is actual caveman's IDE for writing, yet I still do the same thing every day with a just slightly more advanced pointy stick, and it would still be a loss to leave it behind despite all the newer tools available. 😄 There's a lot of "horses for courses" in tool selection. On the overall point; like I said I think I at least understand the thought process when I look at it from the perspective of the art and craft of programming. I feel a lot of The Architect's pride in their craftsmanship coming through in that. But when I look at it from the perspective of the actual trade of writing software... giving the infinite flexibility of The Architect's powerful tools for daily work feels a bit like handing out 12 gauge shotguns to a classroom full of kindergartners to swat a fly. Will they kill it? Sure, but I wouldn't want to see the collateral damage that will come along with that.

zooming out from text code is pretty useful (eg: minimaps, or stuff like Makepad, or in some sense code folding)

🤔 You could imagine a few useful “zoom” levels in a text editor: • all text • fold everything that is multiply indented • keep only top-level stuff, current file only • keep top-level stuff, but show all files in directory • show full file hierarchy, with each file associated with its top-of-file comment (if any) Maybe you could even edit the sufficiently “zoomed out” documents to do file renames?

• observation: writing prose has a different purpose than writing equations • observation: writing equations has a different purpose from commanding electronic machines • observation: writing for the purposes of explaining the purpose of sequences of commands to other humans is different from the purpose of commanding electronic machines • opinion: electronic machines read and interpret sequential code, people shouldn’t have to • observation: making drawings on cave walls, using pointy sticks on clay tablets, and, using opaque dyes on papyrus were tried; dyes and papyrus won out due to the limitations of the other kinds of media • observation: writing equations became less expressive when the printing press was invented, writing programs became less expressive when EBCDIC and, then, ASCII became the media for expressing sequences of commands () • observation: before the advent of non-overlapping grids of small bitmaps called “characters” coupled with banks of switches called “QWERTY keyboards”, IDEs for commanding machines (aka “programming”) consisted of banks of toggle switches, and/or, soldering stations coupled with various kinds of meters and oscilloscopes ; “programming” - commanding electronics - was around well before the advent of textual programming languages, but, using soft-switches rather than hard-physical-switches turned out to be more convenient • opinion: “programming” consists of two activities, neither of which are the same as other kinds of activities (e.g. writing prose, and, e.g. analysis of phenomena using mathematical equations), i.e. 1. commanding machines, 2. communicating the purpose of the commands to other humans ... conflating the two activities leads to unnecessary hardship

I completely agree with your last point @guitarvydas. Programmers seem to be really quick to point out the "single responsibility principle" and SOLID. But fail to see that code serves two different purposes. Trying to make code readable, can be at best a Band-Aid.

@Ivan Reese I've never used Max/MSP but I've heard about it for years, usually in the same breath as PureData (though that seems to be less popular now). There's a lovely big animation of UI on the Max front page which has so much stuff that I don't see in most VPLs, and at this point I just need to pause for a

warning that I'm about to do a deeply uninformed yet loudly opinionated dive

based on the lightest of first impressions...

an attempt at answering some of the questions… https://guitarvydas.github.io/2023/11/20/Thoughts-on-Visual-Programming-Languages.html

@guitarvydas, since you mention using drawio for some of your stuff: Do you know of a good source of docs for the file format or an existing library for parsing/working with it? I happen to be dealing with it at work right now, and have just been trial & erroring it so far because nothing obvious came up and this is kind of throwaway code anyway... but would love to lean on something more robust if it exists

@abeyer Zac Nowicki is more expert at this than I am. He wrote the code for odin0d. (I can give you a github repo link, if you think that would help). Here is a paraphrased version of Zac’s comments: The general format is an XML encoding of mxGraph. You may be able to use that as key terms to find some resources. The format tends to be mostly straightforward to consume with any off the shelf XML parser, using xpaths, etc. My recommendation for iterating quickly / exploring the output is doing some edits then opening Extras -> Edit Diagram to view the XML for the current page only. drawio tends to stuff a lot of things you might be interested in in the “style” attribute on nodes. Check there if you don’t see a specific attribute.

Thanks, yeah, the mxgraph pointer was the trick, turned up some decent docs

@abeyer I don’t fully understand what this “weird inversion” is. If you can give me more detail (or a screenshot or something), then I will bounce it off of Zac and see if he has any comments…

I think I've got it sorted, but the thing I noticed was that normally in mxgraph you would set custom data properties on a vertex in the

mxcell

's

value

and if you haven't set any properties from drawio it includes

value

as an attribute, but as soon as you do it then removes the value attribute completely and wraps the cell in a parent object containing its label and properties