Chaque langage de programmation possède une grammaire formelle. Votre compilateur la lit, construit un arbre d’analyse et rejette tout ce qui ne correspond pas. Votre éditeur ignore entièrement la grammaire et vous laisse taper ce que vous voulez.

Cette déconnexion est la source d’une quantité surprenante de friction. L’autocomplétion suggère des identifiants qui n’ont aucun sens dans le contexte. La coloration syntaxique se casse en plein refactoring. Vous obtenez des erreurs “Unexpected token” pour des erreurs que l’éditeur vous a vues commettre. Nous traitons cela comme normal parce que les éditeurs de texte sont tout ce que nous avons eu pendant quarante ans.

Le texte est une représentation intermédiaire. Le compilateur le jette au moment où il parse. Alors pourquoi est-ce le texte que nous éditons ?

Ce que signifie réellement l’édition structurée

L’édition structurée signifie que la source de vérité est l’Abstract Syntax Tree, pas un character buffer. L’éditeur rend l’arbre sous forme de texte pour votre bénéfice, mais chaque opération manipule directement les nœuds. FunctionDeclaration. BinaryExpression. IfStatement. Ce sont les atomes.

Vous voulez ajouter un paramètre ? Vous ne positionnez pas votre curseur entre parenthèses et vous ne tapez pas. Vous invoquez une opération “add parameter” sur le nœud FunctionDeclaration. L’éditeur crée un nouveau nœud Parameter avec un espace réservé. Le texte rendu est mis à jour. Vous ne créez jamais de parenthèses déséquilibrées parce que les parenthèses ne sont pas des caractères que vous tapez. Ce sont des limites visuelles générées par le moteur de rendu.

Ce n’est pas de la science-fiction. Lisp fonctionne ainsi depuis les années 1960 parce que les S-expressions sont des arbres par définition. Smalltalk traitait les méthodes comme des objets sélectionnables dans un navigateur, et non comme des fichiers texte greppables. Plus récemment, le langage Unison stocke le code comme un Merkle tree de nœuds AST, et JetBrains MPS est un éditeur projectif où la grammaire définit à la fois le langage et l’expérience d’édition.

La garantie de sécurité structurelle

Voici ce qu’un éditeur d’arbre fait lorsque vous refactorisez. Ce script Python approxime la logique interne :

import ast

# The canonical representation is a tree, not text
tree = ast.parse("result = calculate(x, y)")

# Find the Call node and append a keyword argument
for node in ast.walk(tree):
    if isinstance(node, ast.Call):
        node.keywords.append(
            ast.keyword(arg='debug', value=ast.Constant(value=True))
        )

# Render to text only when needed (Python 3.9+)
print(ast.unparse(tree))
# result = calculate(x, y, debug=True)

L’opération est structurellement sûre. Vous ne pouvez pas accidentellement produire calculate(x, y debug=True) parce que keywords est une liste typée de nœuds keyword, pas un string buffer. Le moteur de rendu insère la virgule et le signe égal. L’arbre est toujours syntaxiquement valide.

C’est ainsi que fonctionnent la plupart des formateurs et des linters. Black, prettier et rustfmt parsent tous vers un AST, transforment l’arbre et impriment. La différence est qu’ils lisent du texte, transforment et écrivent du texte. Un éditeur d’arbre saute l’aller-retour texte.

Pourquoi personne n’utilise d’éditeurs d’arbres

Si c’est si bon, pourquoi chaque développeur professionnel utilise-t-il encore VS Code, Vim ou Emacs ?

La vitesse d’interaction est la première raison. L’édition de texte optimise une boucle serrée : vous pensez à un changement, vos doigts tapent des caractères, vos yeux vérifient. Chaque frappe est la même opération. Dans un éditeur d’arbre, “insert an if statement”, “rename a variable” et “extract a method” sont tous des gestes différents. Vous ne pouvez pas simplement marteler les touches. La charge cognitive s’accumule.

Le mur de l’écosystème est la deuxième raison. Chaque outil de votre pipeline suppose du texte. git diff, grep, la révision de code GitHub, la recherche de code, chaque tutoriel sur Internet. Des formats structurés existent, mais aucun n’a supplanté le texte brut comme code source. L’effet de réseau est absolu.

Le problème de rendu visuel est le troisième. Les programmeurs lisent du code comme du texte avec des décennies de convention typographique. Où va un commentaire quand il décrit la moitié d’un nœud ? Comment afficher un arbre en pleine opération lorsque l’utilisateur n’a pas fini de spécifier ce qu’il veut ? Rendre un arbre sous forme de texte lisible et éditable est plus difficile que de rendre du texte sous forme d’arbre.

Commandes structurelles dans les éditeurs de texte

Vous n’avez pas besoin de changer d’éditeur pour obtenir les avantages liés à l’arbre. Plusieurs outils opèrent déjà sur l’AST tout en présentant une interface texte.

Paredit et Smartparens pour les Lisps traitent les S-expressions comme des arbres. Vous “gloutonnez” une expression dans une portée parente ou vous la “vomissez”. Les parenthèses restent du texte, mais les commandes d’édition sont des opérations d’arbre. Vous déplacez des sous-arbres entiers sans jamais créer d’erreur de syntaxe.

Les refactorings modernes des IDEs parsent votre code, construisent un AST, déterminent quelles variables deviennent des paramètres et réécrivent l’arbre. Quand vous faites “extract method” dans IntelliJ, il ne fait pas de remplacement de texte. Il effectue une transformation structurelle et imprime le résultat.

Les language servers construisent en interne un AST pour chaque opération. Go-to-definition, rename et les inline hints traversent tous l’arbre. Le protocole communique des positions de texte pour la compatibilité, mais l’intelligence est structurelle.

Comment expérimenter sans changer d’éditeur

Si vous voulez combler l’écart entre la façon dont vous écrivez du code et la façon dont le compilateur le comprend, commencez ici :

  1. Utilisez le module ast de Python. Écrivez un script qui parse du code réel, parcourt l’arbre avec ast.walk et le transforme. La plupart des outils Python (flake8, mypy, Black) font exactement cela.

  2. Explorez Tree-sitter. Parsez un fichier dans le playground en ligne et inspectez le concrete syntax tree. Voyez ce que le parser voit réellement.

  3. Essayez l’édition structurée pour les Lisps. Si vous écrivez du Clojure ou de l’Emacs Lisp, installez Paredit. Forcez-vous à naviguer par expression plutôt que par caractère pendant une journée. La lenteur est éducative.

Le fichier texte ne va nulle part. Trop d’outillage, trop d’histoire, trop de mémoire musculaire. Mais l’écart entre l’édition de texte et la compréhension structurée est une véritable source de bugs, de friction et de charge cognitive. Vous n’avez pas besoin d’un éditeur d’arbre pour le résoudre. Vous devez arrêter de prétendre que le texte est la vraie chose.