One can appreaciate striving for simplicity (a programming language that can be taught and explained with pen and paper), but one must also consider that computers are meta-devices.

Before computers, we could write things only on paper, either with our hands or a typewriter. So, naturally, when computers came about, the way of thinking about programming was very text-driven, with an emphasis on what a typewriter could represent.

But then, code could be written directly with computers, opening up more typesetting possibilities thanks to keyboards not being bound anymore by the mechanical limitations of typewriters. You could add keys and combinations to your heart's desire, and they would be natively digital and unlimited.

Now, with graphics, both 2D and 3D, and a myriad or other HIDs, shouldn't we try to make another cognitive jump?

It's very strange to see handwriting lumped in with typewriting, to be described as limited relative to screens! Iverson notation was a 2D format (both in handwriting and typeset publications) making use of superscripts, subscripts, and vertical stacking like mathematics. It was linearized to allow for computer execution, but the designers described this as making the language more general rather than less:

> The practical objective of linearizing the typography also led to increased uniformity and generality. It led to the present bracketed form of indexing, which removes the rank limitation on arrays imposed by use of superscripts and subscripts.

(https://www.jsoftware.com/papers/APLDesign.htm)

I think this is more true than they realized at that time. The paper describes the outer product, which in Iverson notation was written as a function with a superscript ∘ and in APL became ∘. followed by the function. In both cases only primitive functions were allowed, that is, single glyphs. However, APL's notation easily extends to any function used in an outer product, no matter how long. But Iverson notation would have you write it in the lower half of the line, which would quickly start to look bad.

I've long been fascinated by this question, probably spurred on by having read Hermann Hesse's _The Glass Bead Game_ (originally published as _Magister Ludi_) when I was impressionably young.

The problem of course is: ``What does an algorithm look like?''

Depicting one usually directs one into flowchart territory, and interestingly efforts at that style of programming often strive for simplicity, e.g., the straight-down preference from Raptor or Drakon --- systems which do not implement that often become a visual metaphor for ``spaghetti code'':

https://blueprintsfromhell.tumblr.com/

https://scriptsofanotherdimension.tumblr.com/

As a person who uses: https://www.blockscad3d.com/editor/ and https://github.com/derkork/openscad-graph-editor a fair bit, and needs to get Ryven up-and-running again (or to fix the OpenSCAD layer in his current project or try https://www.nodebox.net/ again), this is something I'd really like to see someone be successful with, but the most successful exemplar would be Scratch, which I've never seen described as innovatively expressive --- I'd love to see such a tool which could make a traditional graphical application.

All those things can be specified in text. Fortress was a language that had the facility to use mathematical notation. Turned out to be not so compelling iirc.

https://en.wikipedia.org/wiki/Fortress_(programming_language...

We do have syntax highlighting these days. And our editors work like hypertext, where I can go to definitions, find usages, get inheritance hierarchies etc. Quite a ways from your suggestion, but also a few steps removed from a type writer.

I think any such leap would have to be a really big one to catch on though, due to inertia. Colorforth is not exactly popular, and I can't think of any other examples.

We already did, it's natural language. Talk to your computer and get code, aka vibe coding.