Spreadsheet grids are marvelous for presenting many kinds of data relevant to business. Specifically, tabular numerical data (rows of tuples with well-characterized columns). Spreadsheets are great for condensing and summarizing the minute details and aggregates spread across huge numbers of rows, and for highlighting patterns and trends.
And there are other very effective ways to present data. Hypertext, Gantt charts, and pie-charts for example, which Excel also supports.
But we don't use spreadsheet-grids for general programming. Programs (as we write them) are concerned with dependencies and control-flow and semi-structured hierarchies and naming lots of things. Programs are organized as a hierarchy - directories containing files containing the nested-pieces of the program, as text. And some parts of a program (state-machines, data-schemas, GUI layouts, date/control flows) are visualized as boxes containing labels with lines and arrows between them (and more labels). I'm surprised we don't have generic tools for that yet. Attempts have been made.
This is not to mention geometric/photographic/aural data.
I don't think programs are necessarily a hierarchy, though that is a useful way to look at them. There are definitely mutually recursive elements, though these are admittedly limited in size of scope. However, most of the problems with looking at programs as hierarchies come from forcing elements to have a single parent containing element. Instead of a tree, you get a lot more flexibility by allowing elements to have multiple parents (so it is still a DAG, but not a tree since a path from root to the element is not necessarily unique).
For humans, hierarchies are easier to think about and easier to format. But you're right: sometimes you really want to express your structure in a more general graph. And format it more graphically.
For me the most obvious examples are: state-machines and entity-rln diagrams (and, for example, showing how your C-structs point to each other and how you're using std containers and ownership).
Thanks for pointing out that what I really want is a way to create/edit a graph.
You can argue that spreadsheet formulas in cells are also a type of programming, including all the hierarchy you mentioned. Only in this case the hierarchy is not just the functions nested in each other, but also the cells calculating data based on other calculations in other cells.
And while I see the OP explanation on how cells are a great way to arrange data, I would argue that the existing way of programming in Excel is pretty horrible.
Anyone who have ever tried doing something slightly complex with Excel functions soon realized that it is pretty impossible to do certain things without a lot of "magic" involved. Which is why MS added the whole VBScript thing, and even Google Sheets have their JS App Script (or whatever it is called) to provide additional options to program based on data beyond the basic formulas.
It would be great to see more visual programming languages tested in an Excel like data entry environment. Some of the PLC [1] languages come to mind, or even languages like MIT Scratch.
And there are other very effective ways to present data. Hypertext, Gantt charts, and pie-charts for example, which Excel also supports.
But we don't use spreadsheet-grids for general programming. Programs (as we write them) are concerned with dependencies and control-flow and semi-structured hierarchies and naming lots of things. Programs are organized as a hierarchy - directories containing files containing the nested-pieces of the program, as text. And some parts of a program (state-machines, data-schemas, GUI layouts, date/control flows) are visualized as boxes containing labels with lines and arrows between them (and more labels). I'm surprised we don't have generic tools for that yet. Attempts have been made.
This is not to mention geometric/photographic/aural data.