The evolution of a structural code editor

Original Article ↗ Hacker News Discussion ↗

Enthusiasm for structural editors

  • Many commenters like the idea of treating programs as ASTs rather than raw text, with potential benefits:
    • Fewer or no syntax errors; “always-valid” code enabling continuous analysis.
    • Richer editing operations that work on meaningful constructs instead of characters.
    • Better fit for phones, touchscreens, and accessibility, where typing text is painful.
    • More powerful refactoring and visualization (control-flow graphs, node views, code-flow overlays).
    • Clearer structural diffs and renames if diffs operate on syntax trees.

Plain text vs structured representation

  • Strong defense of plain text:
    • Works with existing tools: git, diffs, grep, email, CLIs, teaching, documentation.
    • Stores “what keys were pressed,” enabling simple mental models, version control, and error recovery.
    • Text remains visible and flexible; whitespace, layout, and ordering often convey meaning.
  • Some argue the real win is structural tooling on top of textual formats; the AST must be serialized anyway.
  • Concern that non-text formats lock users into specific editors and break existing workflows.

UX and workflow concerns

  • Several report structural editors feeling clunky:
    • Editing requires navigating only through valid intermediate states, adding cognitive load.
    • Operations that are trivial text edits (e.g., wrapping a call in an if) can require multiple structural steps.
    • Need for temporary syntactically invalid states (pasting, block editing, “gobbledygook” transformations).
  • Preferences differ: some want mouse/touch UIs, others insist structural editing must be keyboard-first, akin to vim motions over ASTs.
  • Suggestions for an “escape hatch” raw-text mode, with reparsing afterward.

Diffing, typing, and analysis

  • Tree-based diffs could:
    • Ignore harmless reorderings.
    • Treat renames as single semantic changes instead of many textual ones.
  • Counterpoints:
    • Whitespace and ordering can be semantically or communicatively important.
    • Syntax-aware diffs and parsers can be added to existing tools without changing editors.
  • “Always-valid” syntax does not guarantee well-typed programs; type-error recovery is a property of the type system, not the editor.

Prior art and hybrid approaches

  • Many note long histories of structural editing (Lisp, paredit/parinfer, Smalltalk, mainframe editors, visual node systems, UI designers).
  • Some argue decades of attempts without mainstream adoption suggest hard, possibly fundamental trade-offs.
  • Popular view: best path is hybrid:
    • Keep a canonical textual representation.
    • Layer structural operations via plugins (Tree-sitter, LSP, refactoring engines, snippet-like structural commands).
    • Explore domain-specific structural editors (UIs, robotics, education) where benefits may outweigh costs.

Open questions / unclear

  • Whether a universal, simple AST format is desirable vs language-specific structures.
  • How far structural editing can scale beyond demos without sacrificing speed, flexibility, and interoperability.