[sitkack]

Rich structured editors free one from text and are able to encode other information that is not currently recorded in text formats. Directly operating on structures would free languages from parsing, correctness checking and compiling could occur at every semantically correct operation.

With a rich structure editor that can do merges, the undo history of edit and refactor operations could be persisted and merged into the VCS. Currently this isn't possible. Text is a projection for the page and a lowest common format.

[icebraining]

Directly operating on structures would free languages from parsing, correctness checking and compiling could occur at every semantically correct operation.

Directly operating on structures would mean that you'd have to write an editor, which had to enforce correctness as well. And then you'd have to write a generator to save those structures in some kind of format that could be written to a file and passed around, and a parser to read such format. And check for correctness again, since who knows what generated that file.

As for constant compilation, that already exists, many IDEs have it. That's because parsing text is not actually hard, the other stages are.

With a rich structure editor that can do merges, the undo history of edit and refactor operations could be persisted and merged into the VCS. Currently this isn't possible.

Of course it is, you could write a plugin for any IDE that would record edits and refactor operations and save those in or alongside the text (much like they've have to be save alongside the AST). Of course, that doesn't help if the user does a manual refactor, but that's no different than they choosing a node in the rich editor, deleting it, then manually recreating it in its refactored form.

[shalabhc]

Instead of retrofitting a structured format on top of the current text centric world, can we imagine if a structure centric world would be better? A large number of tools would exist to operate semantically on the same structured format, including editors, versioning systems, grep, etc. Diffs and merges would work better. Languages would define the syntax in terms of a tree input instead of text input, and so on.

[icebraining]

We could, I'm just not convinced it would actually be better than text. Parsing is not a difficult problem.

[shalabhc]

It's not about parsing being difficult or easy (e.g. you would still have to parse an abstract structure into a syntax tree specific to your language semantics). It's about making a structured form be the canonical baseline (instead of the canonical being a 'sequence of lines' i.e. text).

Consider that every programming language and every config language first invents a new syntax to encode a tree like structure (typically using a combination of curly braces, other brackets, keywords, indentation etc.) but the code itself is saved as 'text'. This is a lossy encoding - all a generic reader such as `git` or `grep` can now infer is that the file contains a 'sequence of lines' and can then only offer line based operations (git diffs are line based, grep searches are line based, etc.), when in fact a more meaningful operation would be the tree structure based.

If a tree based format was the canonical baseline, diffs could display the location of the node added (e.g. 'Added <Class X> -> <Function Y>'), without having language specific parsing knowledge. Similarly, most editors could provide 'tree view' and 'jump-next', 'jump-up' etc based on context, again without knowing language specific details. Further, many internal representations of programs (e.g. intermediate representations in compilers) also use trees, and could potentially be exported into one of these forms, to make the plethora of tools work with them.

(BTW, I'm not saying a tree is the best generic structure to replace text, but just using it as an example to argue for advantages of a generalized extensible structure over plain text.)

[sitkack]

Given the number of security vulns that boil down to broken parsing, I don't think this is true. Maybe it isn't difficult _for you_. It is still a difficult problem. By moving to structured editors, many more dimensions of data can be encoded into a program than can be cleanly represented by text.

Why do you argue so vehemently against someone perusing an avenue of research?