Structured editors, and the return of plain text

1970s and 1980sWhat they proposed

Edit the structure of the program rather than the characters that represent it. The editor manipulates a tree, so the thing on screen is a view of something that is correct by construction and cannot be syntactically wrong.

Whole categories of error disappear, formatting becomes a display choice rather than a source of argument, and every operation that a modern environment performs by parsing is available directly.

Why that is genuinely appealing

Most of what an environment does today involves reconstructing the tree from the text continuously and throwing it away. Renaming, extracting, moving and reformatting are all tree operations performed through a text interface.

Doing them on the tree directly is simpler, faster and cannot produce a broken intermediate state. On the merits of the operation itself the structured approach is straightforwardly better.

The state that has no tree

The difficulty is everything in between. A programmer types a condition and stops, deletes half a line to try something, leaves a clause unfinished while going to look something up, or pastes a fragment that is not valid anywhere yet.

None of those states corresponds to a tree, and they are not unfortunate exceptions. They are what editing consists of, minute by minute, and an editor that forbids them is fighting the activity rather than supporting it.

What text is good at that nobody wanted to give up

Comparison, merging and review, which the entry on version control explains. Searching with tools that know nothing about the language. Copying into a message, a document or a web page. Generating with another program. Reading with any editor on any machine written in the last forty years.

Each of those is available because the representation is a sequence of characters that everything understands, and none is available for a proprietary tree.

1990s onwardsWhere they won completely

Teaching. Environments where a program is assembled from blocks that only fit together in valid arrangements are the dominant way children are introduced to programming, worldwide.

The reason is exactly the one the original proposals gave: a learner should spend their attention on what the program does, not on a missing bracket. The argument was correct, and it was correct for beginners rather than for professionals.

2000s onwardsThe settlement

What actually happened is a compromise nobody designed. The tree is present continuously while the work is being done: parsed as you type, used for completion and refactoring, checked for errors before the file is saved.

And the storage stays text, with automatic formatters increasingly making that text a canonical rendering of the tree rather than something a person arranges. In effect the tree is the semantics, the text is the serialisation, and the argument was settled by having both rather than either.

2000s onwardsWhere the structured approach persists commercially

It survives where a domain has its own notation and a specialised audience: workbenches for building language-specific tooling, and editors for domains where the representation is not textual to begin with, such as diagrams, circuits or state machines.

In every one of those the tree is the natural artefact and the text would be an invention, which reverses the argument and settles it the other way.

The comparison problem, stated concretely

If the stored form is a tree in a private format, then two versions of it differ in whatever way the tool chose to serialise them, and a change of one identifier can rewrite the file.

Review, which is now the central social act of software development, becomes impossible without a tool that understands the format, and every such tool is specific to one product. Text is not better here because it is a better representation; it is better because it is neutral ground.

What the structured tools got right about errors

Reporting a syntax error is an admission that the tool watched somebody produce something invalid and said nothing until asked. Modern environments narrow that gap to a keystroke, which is most of the benefit without the constraint.

The residual difference is that the invalid state still exists and can be saved, committed and shipped, which happens more often than anybody would like to admit.

present dayWhere the tree is stored after all

The compiled artefacts of most modern languages carry a great deal of structure, and environments increasingly keep a persistent index of the parsed program alongside the text.

Which means the tree is stored, cached and shared; it is simply not the authoritative copy. The structured editors asked for the right artefact and the wrong custodian.

2010sWhat the formatters actually did

Worth noticing as a quiet victory for the losing side. A formatter with no options removes formatting from the set of things a person may decide, which means the characters on disk are determined by the structure.

At that point the text is a projection of the tree, which is the structured editor's core claim, implemented by deleting a freedom rather than by changing the tool.

What we cannot verify

The systems and their capabilities are documented, and some can still be run. Claims about why individual projects abandoned the approach are largely anecdotal. The dominance of block-based environments in education is well supported by usage figures published by their operators, which is a source with an interest in the answer.