Lovely little article about HyperCard, including some historical context I'd not previously seen, and a general plea to do more weird stuff like this. (And yes, article, node-wire spaghetti is my idea of no-code Nirvana). -> HyperCard on the Macintosh

Since this article brought up using AppleScript in Photoshop, a good while back I've seen somebody share a very complex Photoshop macro which created a procedurally generated landscape, or something of the sort. They sheepishly said that they didn't know how to code, but they made this thing with macros. They didn't even realize that they did, in fact, know how to code. That + a couple of recent HyperCard articles (especially that Decker one that calls this out directly) made me think about the visual aspect of coding. Or it just vanishing entirely. Interface designer tools replaced by XML-ish markup. Text rules everything around me. Scratch is just arranging text. The node-wire spaghetti at its worst just being a slightly more spatial representation of textual code. And of course the elephant in the room is LLMs, which turn text into more text. Are we throwing text at the problem of too much text? But then there's also the interesting aspect of coding in the same space as the output. You do that with the Excels, but mainstream programming is spending all this time at the backstage and never seeing the actual performance. Can we direct from the audience seat? What would a programming environment that ditches text look like? HyperCard? LittleBigPlanet? And can the backstage-audience metaphor apply to a textual programming environment? What would that look like? Excel?

Yes! I agree emphatically with all your thoughts and share your yearnings!

Q: What's wrong with that manifestation of node-wire spaghetti? A: (IMO) There are more than 7±2 items of importance on the diagram. IMO, the diagram should be composed of multiple layers, with no layer containing more than 7±2 items. IMO, nodes need to be recursive, i.e. nodes can contain compositions of nodes, with each node possibly containing other compositions. All the way down. "Infinite canvases" will fail to satisfy in a similar manner. An "elephant in the room" is that we need recursive nodes with well-defined input and output ports .

I think the 7+2 wisdom is overstated. Books aren't limited to 9 words on a page. Sudoku has 81 spaces. Chess has 32 pieces. It's about the experience of processing the input. In Go there are 361 board positions, but your brain learns to process them as groups, regions, etc. It's more about whether the interface allows you to reduce the number of concepts you need to process simultaneously to around 7. If it does, humans will just use it that way. But I do think nesting is a very strong and underutilized way of facilitating that. I do worry that not everything helpful to navigate fits nicely into a tree, though. Have been experimenting recently at work with UIs that allow people to navigate directed graphs in a way that feels like navigating a hierarchy for filtering purposes, except that there is sometimes more than one way back "up" the graph. The results have been interesting, but most people have no experience with DAGs as a data structures, so it's hard to gauge if there is value there. I would like a more general concept of zoom, where you are able to choose a node as a target, and change the display to show or hide dimensions of information about that target, with dimensions being more varied than the "contains" relation.

Saying "the 7+2 wisdom is overstated" is understated! :) 7±2 is Miller's Law, which was found by studying "the longest list of items (e.g., digits, letters, words) that a person can repeat back in the correct order on 50% of trials immediately after the presentation." It's about temporary memorization of lists! That's it. This finding, and the other findings from Miller's paper, have effectively zero bearing on node-wire (absolutely, but also relative to text).

We need a language to talk about relationships represented in visual diagrams, eg “node a feeds into node b”. Once we have a language we can represent the same diagram as text. Any projection, zooming or modification of the diagram can also be done in the language oriented text version. So the question is: what does the visual diagram give us? (this is not a counterpoint but rather a request for further examination)

Why do we need to map the visual into language? The whole reason I want to explore visual programming is to see what it might express that language would struggle with.

a) Some drawing editors already give us the "node a feeds into node b" info in some kind of XML. I use

<http://draw.io|draw.io>

and transmogrify it's graphML into JSON while removing the graphical sugar (x,y,geometry stuff - something like 90% of the .drawio file - much more readable when boiled down). Then, I read the JSON into a "kernel" program (now Python, used to be Odin) and run it. [I have posted references to this stuff and am currently editing yet another short video on how to use

pbp-kit

]. b) DPLs (Diagrammatic Programming Languages) give us huge amounts of flexibility that have been discarded in the rush to functional-ize code. I use both, DPLs and current programming languages (Python, JS, lisp, Odin, etc., etc.). I recommend using hybrids, not only Text PLs and not only DPLs. DPLs can express things that traditional PLs can't, while, traditional PLs can express things (like

a = b + c

) that are cumbersome and wasteful to express in DPLs. DPLs can express pure, asynchronous message passing (functions don't do this by default). DPLs can express concurrency more easily than TPLs can. DPLs can express queue-based feedback loops (FP expresses stack-based recursion which ain't the same thing as queue-based feedback). DPLs can express fan-out and fan-in better than TPLs can. DPLs can express isolation and (recursive) nesting - our current TPLs don't. There's a wealth of info that Gutenbergian syntax simply ignores or makes more difficult than necessary. DPLs can express communicating state machines - incredibly useful when you want to use more than one computer, e.g. blockchain, IoT, internet, robotics, etc... (one will note that the BFT solution is just a simple state machine. Harel used diagrammatic StateCharts to power the Israeli air force (iiuc). Atari Pong was originally built with no TPL code and only with a diagram) TPLs force us to think of "programs" as gearboxes full of tightly coupled functions and "computers" as FP-machines. That's only like 10% of what can be accomplished with these things (n.b. the "10%" number is pure hand-waving, but indicative of the imbalance, IMO).

@shalabh sounds like https://mechanism.ucsd.edu/bill/teaching/F12/cs200/Readings/larkin.whyadiagramissometimesworth.1987.pdf (“Why a Diagram is (Sometimes) Worth Ten Thousand Words”)

Excellent link, thanks Joshua.

We need to separate the human interface from the machine representation. I’m perfectly happy with a text or binary machine representation. But for the human interface, there are many things for which it is impossible to map them cleanly into text. You could use text to describe them, but that would be lossy.

Agree about the separation. I’m more interested in the human interface. Unfortunately there is often a different abstraction for interop across tools and so internal representation leaks out. Also I just remembered Technical Dimensions of Programing Systems is a good model for categorization to answer my own question.

When you're back in present-day, wondering why a 20GB application can't afford the same flexibility as this 1MB dynamo, then you'll understand. "Why can't I change this? Why can't I make it mine?" Such questions will cut you in a dozen small ways every day, until you're nothing but scar tissue. Then you'll understand.

This is beautiful