Description et interprétation : le programme comme valeur

La distinction entre décrire un programme et l’exécuter constitue un changement de perspective fondamental en programmation fonctionnelle.

Dans l’approche impérative traditionnelle, écrire du code c’est donner des ordres immédiats : console.log("hello") effectue l’affichage, fs.readFile(path) lit le fichier maintenant. Le code est une séquence d’instructions que le runtime exécute au fur et à mesure qu’il les rencontre.

L’approche « program as value » inverse cette relation : on construit une description de ce que le programme devrait faire, une structure de données inerte qui représente les intentions, puis on confie cette description à un interpréteur qui décide comment et quand l’exécuter.

Le programme comme valeur de première classe

Cette séparation transforme les programmes en valeurs de première classe : on peut les stocker dans des variables, les passer en arguments, les retourner depuis des fonctions, les combiner avec d’autres programmes.

Un Effect<A> ou un IO<A> n’est pas un résultat mais la recette pour obtenir un résultat. On peut manipuler cette recette avant de la cuisiner :

• La transformer avec map
• La séquencer avec flatMap
• La combiner en parallèle
• La rejouer (retry) en cas d’échec

Le tout sans qu’aucun effet ne se produise. L’exécution reste suspendue, potentielle, jusqu’au moment explicite où l’on invoque l’interpréteur. Le programme devient une donnée comme une autre.

Avantages de la séparation

Les avantages de cette approche sont multiples :

• Testabilité : on peut inspecter la description sans l’exécuter, ou fournir un interpréteur de test qui simule les effets
• Composition : deux descriptions se combinent en une troisième description, sans effets de bord intermédiaires
• Raisonnement équationnel : substituer une expression par sa définition ne change pas le comportement, puisqu’aucun effet n’a lieu avant l’interprétation finale

On retrouve la transparence référentielle même en présence d’opérations effectuelles, car les effets sont décrits plutôt qu’exécutés.

Réinterprétation

Cette architecture permet également la réinterprétation. Une même description peut être interprétée différemment selon le contexte :

• En production, on exécute réellement les effets
• En test, on les simule
• En dry-run, on les journalise sans les effectuer

Les DSL métier tirent parti de cette propriété : on décrit des workflows, des règles, des transformations, puis on choisit un interpréteur adapté.

Le pattern Free Monad pousse cette idée à son terme : on définit une algèbre d’opérations comme un type de données, on construit des programmes comme des arbres de ces opérations, puis on fournit un interpréteur qui donne sens à chaque opération.

Frontière entre pur et impur

Cette distinction éclaire également la frontière entre code pur et impur :

• Le cœur fonctionnel du programme construit des descriptions : c’est du code pur, testable, composable
• La périphérie du programme interprète ces descriptions et produit les effets réels : c’est la couche impure, réduite au minimum

L’architecture hexagonale trouve ici une résonance naturelle : le domaine manipule des descriptions d’intentions, les adaptateurs les interprètent en termes d’infrastructure concrète.

Le programme comme valeur n’est pas qu’une curiosité théorique ; c’est un pattern architectural qui déplace la complexité des effets vers des points de contrôle explicites et isolés.