Today, I spent much of my time bouncing ideas of an LLM (Claude) and using the LLM as a foil. I'm interested in "language" design, hence, my line of thinking went down this path... The interesting corollary If the text-as-notation choice was driven by hardware weakness — keyboards and line printers being the available I/O — then the arrival of bitmap displays and pointing devices in the late 1970s and 1980s should have triggered a paradigm shift toward diagrammatic programming. It didn't, for exactly the tooling-gravity reason discussed earlier: by then, text-based languages had accumulated compilers, libraries, communities, and curricula. Smalltalk gestured toward something different. Sketchpad had already shown in 1963 what a diagrammatic computing medium could look like. But the gravity of text was already too strong. We may be at the first moment where that gravity is genuinely weakening — not because hardware changed again, but because LLMs make it possible to build the tooling layer for new notations without the decades of infrastructure investment that previously made it prohibitive.

Show, don't tell 🙂 If LLMs make a new tooling layer possible, let's see it. I think you have enough ideas, stop bouncing them around. Show one compiler or library or curriculum every week for this diagrammatic medium. I think you'll find that text has a lot more than fifty years of momentum. More like three thousand years. And it consists not of solutions but of evaluation. We spent years trying out alternatives before we settled on the current state. I don't think AI speeds up evaluation, even if we accept all the current hype. So you might be able to speed up three thousand years to a thousand at best.

Drawings have an even longer history than text. But drawings conveying precise information are very recent. I don't know about diagrams, but the person credited for having invented infographics is William Playfair, late 18th century. At that time, semi-formal textual notations were already in general use in science, and tables well established in accounting. https://en.wikipedia.org/wiki/William_Playfair

Text does have a little something something going for it. But maybe these LLM AIs speak to having flexible view-model that can then get rendered however you want.

Rendering, i.e. text -> graphics looks like the easy part. What @guitarvydas advocates for also requires graphics -> text.

I’d go even further. Graphics->text is easier than text->graphics. Semantics->less_semantics is easy, but, less_semantics->semantics is harder (e.g. trying to disassemble machine code is harder than converting assembler to machine code). Throwing away semantics and going to less_semantics is easier than trying to infer semantics back from a representation where the original semantics were discarded. I claim that a graphical notation can contain more semantics in a convenient form than just a purely textual representation. A very simple example is the use of variable names - you can draw two boxes of the same type on a diagram and “everyone knows” which is which. To say the same thing in only text, you need to start annotating the code with variable names. There are other less-simple examples (my favourite would be control flow - a diagram of how things need to be sequenced (esp. when more than one happy path is possible) makes more instant sense than a whack of text). [It would be wrong to infer that I favour using only graphics. Something like “a := b + c” is better left as text - we need a hybrid of both].

The comparison with circuit diagrams is interesting. As far as I know, that notation was made after their semantics were defined by hardware components. Circuit diagrams started out as maps of actual circuits. Notation made for pre-existing semantics. Programming with diagrams requires both this and its inverse: defining semantics in diagrams, to be turned into processor instructions later.

I'm quite sure that I don't understand your words, but I won't let that stop me from commenting :-). I didn't witness the birth of schematic notation nor the genesis of synchronous, sequential, function-based notation. I observe, though, that schematic notation works well with asynchronous "black box" components that obey the laws of physics (e.g. inputs and outputs characterized with timing diagrams), whereas synchronous / sequential notation doesn't do so well and complicates simple things like parallelism and concurrency. Drawing diagrams of asynchronous black box components is easy, whereas drawing diagrams of synchronous, tightly-coupled functions is not easy. Historically: to use text as programming notation, we cherry-picked a few words from the English language. To use diagrams as programming notation, we can simply do the same - cherry-pick a few figures. The secret to drawing diagrams is to ensure that components on the diagrams represent fully isolated components, and, not ones that are tightly coupled. Functional notation for components is not tightly coupled, nor bound by physics, when expressed on paper, but becomes tightly bound when mapped onto CPUs (call/block/return behaviours). Knowing this, it is easy to see how to fix the "problem" (queues, first class functions), which then opens the doors to a wider range of syntax (text + figures + wires). I attribute the existence of Moore's Law to the asynchronous "black box" approach used for expressing electronic circuits. I observe that there is no equivalent to Moore's Law in software. In my view, the giants of the 20th century were solving a different class of problems than the kinds of problems we face in the 21st century. Continuing to stand on the shoulders of 20th century software giants isn't productive and is essentially self-flagellation leading to unnecessary complexity, IMO.

You could do parts-based programming in plain text as well. Do you believe that using diagrams would encourage parts-based programming, via the circuit metaphor? Or maybe vice versa?

I agree. In fact, I recently built some bash doo-dads to make it completely textual. I naturally gravitate towards a visual representation, so maybe my opinion doesn't matter 🙂. Diagrams can express things that text makes clumsy (fan-out, feedback, parallelism). I find that text-based notation discourages these kinds of thoughts, but, I'm not sure if the "path" to PBP should be purely diagrammatic. [For example, UNIX processes had 16 ports, but bash only encouraged the use of 1 in and 2 outs. The text syntax for getting at the rest exists, but doesn't really encourage their use nor make it "obvious" what's going on.]. Maybe from the observation that I haven't managed to convince a lot of people by trying to explain this stuff in English (text) should indicate -- what???

Text laid out on a screen is also a species of diagram. The real limitation one runs into is that the conventions of our writing systems (inherited from Roman script) include a flow first from left to right, then from top to bottom, which works well for sequential structures — up to and including trees — but sucks once you have to encode a more complicated graph. And sadly, it turns out that many objects of interest in the world are best represented as more complicated graphs :/

to add: diagrams drawn using SVG editors, draw.io, Excalidraw, etc. have properties that text doesn’t conveniently encourage: resizing, overlapping, z-coord, closedness (easy-to-see grouping and scoping), fill colours … (these can be used as syntactic elements or just as syntactic sugar)

All of those attributes can be applied to text. Part of my point is that text is just glyphs made of vector drawings. It isn't the glyphs that are the problem but rather the structural characteristics of plain text layout.

Let me add to Jack's point (I say this every time it comes up) that actual 3D layout, in VR or physical models or whatever, can sometimes fit more complicated graphs surprisingly well. A trick is that the casual interactivity of looking and moving around plays into the mind's natural ability to map a space that isn't activated as well by flat layouts.