Hi Rupert,
this is a very interesting point. This reply might go off topic, so if this is a problem somebody just let me know.
I’ve been working in language engineering for many years, both in research and in different industries, and it is a reoccuring question: textual vs. structural editing, what’s better?
As you might imagine, there is no wrong or right answer to that, in general. Both approaches have advantages and disadvantages, which is why I find the tree-sitter project so exciting. In this presentation, you can see how they are able to perform high-level operations on a text file, which are usually things you do in structural editors (starting around this time code).
When you interact directly on a tree (like the AST of a program), you can start manipulating a program more in terms of “expressing intentions”. Think of those like (fine-grained) refactorings. “Move this statement up/down”; “Extract that into a variable”; “duplicate this expression three times”; “substitute this expression with that expression”.
Such refactorings are available in many IDEs as well, but they become more second nature when you operate on the tree directly, I think.
I could list many reasons why I think structural editing should be superior to text, e.g. it allows you to not only represent information as a sequential stream of characters, but arbitrarily. The most famous presentation on that topic (in case you don’t know it, please watch it, I think it is a must-see), is Bret Victor’s Future of Programming. Despite all the points he makes there, we (programmers) still like our little text editors. And you are rightly pointing out some nice features of text, like its compact way of decribing code.
But to answer your question more specifically: yes, you can certainly work a structural editor without ever reaching for the mouse (even true for my prototype, although the selection still goes haywire often enough, but you can recover with the tyb key very reliably).
In many cases, especially if the structural editor looks a lot like a textual representation would look like, this makes a lot of sense. When you have a state machine as a diagram, like in my example, you want to use the mouse to move the nodes at some point.
Where the structural approach can really shine is for DSLs. I’ve been involved with a project at Siemens Healthineers, where we used MPS to build DSLs for physicists to formally descibe the runtime protocols of CT scanners. The data needed to be presented in a tabular notation, it was just the most natural way to yield it, yet the users also profited heavily from features we know and love from programming, like having type safety, static evaluation, scoping, model execution (aka running a program), etc. The lines between “code” and “models” are blurry, and I usually don’t distinguish between them. What does make sense, though, is to distinguish between user groups (programmers / non-programmers, for example) as well as use cases (manipulating data / reviewing data).
To emphasize this second distinction, take a look at the following screenshot. It shows the default editor for something very “Java-like” on the left in JetBrains MPS’s default editor, and the same code in a editor I’ve prototyped once for the main purpose of code reviews. It’s not perfect, but I guess you get the idea why the right side might be better to comprehend and discuss code in a review.
So I guess my bottom line is: yes, text is really the prefered way for the target group “programmers” and the use case “editing code”. For many other target groups and use cases, it might be very beneficial to have other editors/views.
