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).
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).
Blur out "7±2", it's just a metaphor for "easy vs. hard" ...
📝 Crossing the Great Divide From Difficult to Easy
2025-12-17
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 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).
Mapping "visual" into TPLs lets us use existing tools and techniques (parsing, compilering, etc.). Kinda like the fact that early compilers simply mapped HLLs to ASM. Compilers still do that internally, but all of the ASM programmers who insisted on seeing the emitted code have retired. Now nobody cares to see how the sausage is made. Mapping from 2D to 1D is just a convenience, but, if you believe in brainstorming, this convenience can - incrementally - give you new ideas.
Shalabh Chaturvedi sounds like mechanism.ucsd.edu/bill/teaching/F12/cs200/Readings/larkin.whyadiagramissometimesworth.1987.pdf (“Why a Diagram is (Sometimes) Worth Ten Thousand Words”)
Need was a strong word - we dont need to map visual to text. But it is possible to map it and it can give us other perspectives into the same model.
What category are spreadsheets in? Clearly they cant benefit from git, grep or other plain text paraphernalia. OTOH, they don’t feel like a DPL – I don’t see diagrams when I open it. I feel there is a space here without a name.
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.
📝 Technical Dimensions of Programming Systems
Programming requires much more than just writing code in a programming language. It is usually done in the context of a stateful environment, by interacting with a system through a graphical user interface. Yet, this wide space of possibilities lacks a common structure for navigation. Work on programming systems fails to form a coherent body of research, making it hard to improve on past work and advance the state of the art. In computer science, much has been said and done to allow comparison of programming languages, yet no similar theory exists for programming systems; we believe that programming systems deserve a theory too. We present a framework of technical dimensions which capture the underlying characteristics of programming systems and provide a means for conceptualizing and comparing them. We identify technical dimensions by examining past influential programming systems and reviewing their design principles, technical capabilities, and styles of user interaction. Technical dimensions capture characteristics that may be studied, compared and advanced independently. This makes it possible to talk about programming systems in a way that can be shared and constructively debated rather than relying solely on personal impressions. Our framework is derived using a qualitative analysis of past programming systems. We outline two concrete ways of using our framework. First, we show how it can analyze a recently developed novel programming system. Then, we use it to identify an interesting unexplored point in the design space of programming systems. Much research effort focuses on building programming systems that are easier to use, accessible to non-experts, moldable and/or powerful, but such efforts are disconnected. They are informal, guided by the personal vision of their authors and thus are only evaluable and comparable on the basis of individual experience using them. By providing foundations for more systematic research, we can help programming systems researchers to stand, at last, on the shoulders of giants.
