There are good reasons it hasn't been done more, and I don't think it is just "text is good for troubleshooting."
At large, text wins because the job of a program text is to communicate the program to a user in a way that a computer can also be made to use. Things that help include that text can have multiple interpretations and meanings. This is why most variable names are nouns. You can literally "ascii art" parts of code to help convey some ideas.
The most important part of why "text" wins, though, is that it is all visible. Yes it implies some structure underneath that the computer is going to need. The text, though, is fully visible to users. People think they want the ability to "structurally edit," and you can sometimes make that work rather nicely. Most of the time, though, you are working with structures that are not complete. And worse, completing them will not be a process that goes in the same direction as the text. You will have to start a stack in how you are processing things to complete as you go.
I'm torn on the bots comment, as I just don't know. LLMs, arguably, are leaning in on the structure that has been embedded in our symbolic text over many years. The same structure has not necessarily been developed in computer programming texts?
(Also worth paying attention to how most of these goals were pursued with symbolic programming techniques back in the day. LISP, of course, but also term rewriting techniques that used to be rather magical.)
> Most of the time, though, you are working with structures that are not complete. And worse, completing them will not be a process that goes in the same direction as the text. You will have to start a stack in how you are processing things to complete as you go.
This is very insightful. A program that is being edited passes through all sorts of incomplete states. Non-structured editors will let you do things like paste mismatched braces .. which sometimes you definitely deliberately want to do!
At large, text wins because the job of a program text is to communicate the program to a user in a way that a computer can also be made to use. Things that help include that text can have multiple interpretations and meanings. This is why most variable names are nouns. You can literally "ascii art" parts of code to help convey some ideas.
The most important part of why "text" wins, though, is that it is all visible. Yes it implies some structure underneath that the computer is going to need. The text, though, is fully visible to users. People think they want the ability to "structurally edit," and you can sometimes make that work rather nicely. Most of the time, though, you are working with structures that are not complete. And worse, completing them will not be a process that goes in the same direction as the text. You will have to start a stack in how you are processing things to complete as you go.
I'm torn on the bots comment, as I just don't know. LLMs, arguably, are leaning in on the structure that has been embedded in our symbolic text over many years. The same structure has not necessarily been developed in computer programming texts?
(Also worth paying attention to how most of these goals were pursued with symbolic programming techniques back in the day. LISP, of course, but also term rewriting techniques that used to be rather magical.)