The evolution of a structural code editor

Original Article ↗ Hacker News Discussion ↗

Structural code editors that treat programs as abstract syntax trees rather than plain text are attracting renewed interest, with proponents arguing they can eliminate many syntax errors, enable richer refactoring and visualization, and make coding on phones or alternative interfaces more practical. Critics counter that plain text remains uniquely powerful for version control, tooling interoperability, teaching, and informal edits that pass through invalid states, and note that decades of work on Lisp tools, Smalltalk, and modern IDEs already exploit code structure without abandoning text. Many comments converge on hybrid approaches—structural operations layered on top of conventional source files, AST-aware diffing, and keyboard-driven “command languages” for the AST—as a more realistic path than fully replacing text-based workflows.

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.