John McCarthy, Lisp et les origines de la conception symbolique en IA

Pourquoi McCarthy et Lisp comptent encore

Il ne s’agit pas d’une visite de musée sur « l’IA d’antan ». C’est une leçon d’histoire pratique pour quiconque construit des logiciels — programmeurs, tech leads et responsables produit — parce que les idées de John McCarthy ont façonné notre manière de penser à l’utilité des langages de programmation.

Lisp n’était pas seulement une nouvelle syntaxe. C’était le pari que le logiciel pouvait manipuler des idées (pas seulement des nombres) et que des choix de conception de langage pouvaient accélérer la recherche, l’itération produit et tout un écosystème d’outils.

Une manière utile de lire l’héritage de McCarthy est de se poser la question qui reste pertinente aujourd’hui : jusqu’à quel point peut-on transformer une intention directement en système exécutable — sans se noyer dans le boilerplate, la friction ou la complexité accidentelle ? Cette question résonne du REPL de Lisp jusqu’aux flux modernes « chat→app ».

La grande idée de John McCarthy : rendre le raisonnement programmable

John McCarthy est connu non seulement pour avoir aidé à lancer l’IA comme domaine de recherche, mais pour avoir insisté sur un type spécifique d’IA : des systèmes capables de manipuler des idées, pas seulement de calculer des réponses. Au milieu des années 1950, il a organisé le Dartmouth Summer Research Project (où le terme « intelligence artificielle » a été proposé) et a influencé les travaux à MIT puis à Stanford. Sa contribution la plus durable peut être la question qu’il n’a cessé de poser : et si le raisonnement lui-même pouvait s’exprimer comme un programme ?

Des nombres aux symboles

Les premiers succès de l’informatique étaient surtout numériques : tables balistiques, simulations d’ingénierie, optimisation et statistiques. Ces problèmes se prêtent bien à l’arithmétique.

McCarthy visait autre chose. Le raisonnement humain travaille souvent avec des notions comme « si », « parce que », « appartient à », « est une sorte de », et « toutes les choses qui satisfont ces conditions ». Ce ne sont pas des choses qu’on représente naturellement par des flottants.

L’approche de McCarthy considérait le savoir comme des symboles (noms, relations, catégories) et le raisonnement comme des transformations basées sur des règles opérant sur ces symboles.

Une façon haute-niveau de l’imaginer : les approches numériques répondent « combien ? » tandis que les approches symboliques cherchent à répondre « qu’est-ce que c’est ? » et « qu’est-ce qui découle de ce que nous savons ? »

Lisp comme outil adapté

Si l’on croit que le raisonnement peut être rendu programmable, il faut un langage qui puisse représenter confortablement des expressions comme des règles, des énoncés logiques et des relations imbriquées — puis les traiter.

Lisp a été conçu pour cet objectif. Plutôt que d’imposer des structures de données rigides et préfabriquées, Lisp rendait naturel de représenter le code et le savoir sous une forme similaire. Ce choix n’était pas un élégant exercice académique : c’était un pont pratique entre décrire une pensée et exécuter une procédure, exactement le pont que McCarthy voulait voir l’IA franchir.

La pensée symbolique, en termes simples

Quand McCarthy et les premiers chercheurs en IA parlaient de « symbolique », ils ne parlaient pas de mathématiques mystérieuses. Un symbole est simplement une étiquette signifiante : un nom comme customer, un mot comme hungry, ou une balise comme IF et THEN. Les symboles comptent parce qu’ils permettent à un programme de travailler avec des idées (catégories, relations, règles) plutôt qu’uniquement avec des nombres bruts.

Une image simple : les tableurs sont excellents quand votre monde est fait de colonnes et d’arithmétique. Les systèmes symboliques sont meilleurs quand votre monde est fait de règles, de catégories, d’exceptions et de structure.

Les symboles : des noms porteurs d’intention

Dans beaucoup de programmes, la différence entre 42 et "age" n’est pas le type de données — c’est ce que la valeur représente. Un symbole vous donne quelque chose que vous pouvez comparer, stocker et combiner sans perdre le sens.

Cela rend naturel de représenter des assertions comme « Paris est une ville » ou « si la batterie est faible, trouve un chargeur ».

Les listes : la structure la plus simple pour « composé de parties »

Pour faire quelque chose d’utile avec des symboles, il faut de la structure. Lisp a popularisé une structure très simple : la liste. Une liste est juste un groupe ordonné d’éléments, et ces éléments peuvent eux-mêmes être des listes. Avec cette seule idée, on peut représenter des phrases, des formes et des connaissances en arbre.

Voici un minuscule exemple conceptuel (style Lisp) :

(sentence (subject robot) (verb needs) (object power))

Cela se lit presque comme de l’anglais : une phrase composée d’un sujet, d’un verbe et d’un objet. Parce que c’est structuré, un programme peut repérer (subject robot) ou remplacer (object power) par autre chose.

Des structures au raisonnement : règles, planification, recherche

Une fois l’information dans des structures symboliques, les tâches classiques de l’IA deviennent abordables :

• Règles : si un motif correspond, alors conclure quelque chose de nouveau.
• Planification : représenter buts et actions comme des listes, puis enchaîner des actions pour atteindre un but.
• Recherche : explorer différentes combinaisons symboliques possibles (états) pour trouver une solution.

Le changement clé est que le programme ne se contente pas de calculer : il manipule des morceaux de savoir signifiants sous une forme qu’il peut inspecter et transformer.

Pourquoi les choix de conception de langage résonnent pendant des décennies

Les décisions de conception de Lisp ne sont pas restées cantonnées à l’académie. Elles ont influencé la construction d’outils et la rapidité d’exploration des idées :

• Expressivité : Lisp facilitait la représentation de savoir structuré et sa transformation.
• Itération rapide : le développement interactif réduisait la boucle entre « penser » et « essayer ».
• Extensibilité : le langage encourageait la création de nouvelles abstractions plutôt que la répétition des mêmes motifs.

Ces traits produisent des écosystèmes où l’expérimentation coûte peu, où les prototypes deviennent des produits plus vite, et où les équipes peuvent s’adapter quand les besoins changent.

Les objectifs de conception derrière Lisp

Lisp est né d’un problème pratique : comment écrire des programmes qui travaillent avec des symboles aussi naturellement qu’ils travaillent avec des nombres ?

McCarthy ne cherchait pas à construire une « meilleure calculatrice ». Il voulait un langage où une expression comme (is (parent Alice Bob)) puisse être stockée, inspectée, transformée et raisonnée aussi facilement que (+ 2 3).

Un langage conçu pour les données symboliques

La priorité était de rendre l’information symbolique facile à représenter et à manipuler. Cela a conduit à un accent sur les listes et les structures arborescentes, car elles correspondent bien à ce que les humains utilisent déjà pour exprimer du sens : phrases, règles logiques, catégories imbriquées et relations.

La simplicité qui libère la flexibilité

Un autre objectif était de garder le noyau du langage petit et cohérent. Quand un langage a moins de « cas spéciaux », on passe moins de temps à mémoriser des règles et plus de temps à composer des idées. Lisp a misé sur un petit nombre de briques élémentaires pouvant se combiner en abstractions plus larges.

Programmes en forme de données

Une idée clé était que programmes et données peuvent partager la même structure. En clair : si vos données sont des listes imbriquées, votre programme peut aussi être une liste imbriquée.

Cela signifie que vous pouvez :

• générer un programme (comme des données structurées)
• le modifier (comme n’importe quelle autre donnée)
• puis exécuter le résultat

Un changement culturel dans la conception des langages

Lisp a aussi popularisé un état d’esprit : les langages n’ont pas à être universels et identiques pour tous les usages. Ils peuvent être conçus autour d’un domaine problème — comme le raisonnement, la recherche et la représentation du savoir — et avoir pourtant un impact durable sur la programmation générale.

S-expressions : une structure simple aux grandes conséquences

Les S-expressions (pour symbolic expressions) sont l’idée signature de Lisp : une façon unique et cohérente de représenter code et données comme des listes imbriquées.

En un coup d’œil, une S-expression est juste des parenthèses autour d’éléments — certains sont des atomes (noms et nombres), d’autres sont des listes. Cette règle « listes dans des listes » est tout l’enjeu.

Une forme unique pour tout

Parce que la structure est uniforme, les programmes Lisp sont construits à partir des mêmes briques jusqu’en bas. Un appel de fonction, un morceau de configuration et une structure de programme peuvent tous s’exprimer comme une liste.

Ce principe rapporte vite :

• Le parsing devient plus simple : le langage n’a pas besoin d’un grand bestiaire de cas spéciaux.
• Les transformations deviennent pratiques : il est plus facile de parcourir un arbre de listes et d’en réécrire des parties.
• L’évaluation est plus régulière : l’évaluateur peut traiter de nombreux constructeurs de façon cohérente, puisqu’ils partagent la même forme.

Même si vous n’écrivez jamais de Lisp, c’est une leçon importante : quand un système est bâti sur une ou deux formes prévisibles, on passe moins de temps à lutter contre les cas limites et plus de temps à construire.

Une composition perceptible

Les S-expressions favorisent la composition car des petites pièces lisibles se combinent naturellement en plus grandes. Quand votre programme est « juste des listes imbriquées », combiner des idées revient souvent à imbriquer une expression dans une autre ou à assembler des listes à partir de pièces réutilisables.

Cela incite à un style modulaire : écrire de petites opérations qui font une chose, puis les empiler pour exprimer une intention plus large.

Le compromis : les parenthèses

L’inconvénient évident est l’étrangeté. Pour beaucoup de débutants, une syntaxe chargée de parenthèses paraît étrange.

Mais l’avantage est la prévisibilité : une fois qu’on comprend les règles d’imbrication, on voit de façon fiable la structure d’un programme — et les outils aussi. Cette clarté explique en grande partie pourquoi les S-expressions ont eu des conséquences bien au-delà de Lisp lui-même.

Récursion et traitement de listes comme blocs de construction

La récursion se comprend aisément par une métaphore du quotidien : nettoyer une pièce en en faisant de plus petites « sous-pièces ». On ne tente pas de tout résoudre d’un coup. On prend un objet, on le remet à sa place, puis on répète la même action sur ce qui reste. Les étapes sont simples ; la puissance vient de leur répétition jusqu’à ce qu’il n’y ait plus rien à faire.

Lisp exploite cette idée parce qu’une grande partie de ses données est naturellement faite de listes : une liste a une « première chose » et « le reste ». Cette forme convient parfaitement à la pensée récursive.

Pour traiter une liste, on gère le premier élément, puis on applique la même logique au reste. Quand la liste est vide, on s’arrête — c’est le moment propre « plus rien à faire » qui rend la récursion bien définie plutôt que mystérieuse.

Mini-exemple conceptuel : sommer une liste

Imaginez que vous voulez la somme d’une liste de nombres.

• Si la liste est vide, la somme vaut 0.
• Sinon, la somme est le premier nombre plus la somme du reste.

C’est tout. La définition se lit comme de l’anglais, et la structure du programme reflète l’idée.

Penser « parcourir un arbre »

L’IA symbolique représente souvent des expressions comme des structures arborescentes (un opérateur avec des sous-expressions). La récursion est un moyen naturel de « parcourir » cet arbre : évaluer la partie gauche de la même façon que la partie droite, et continuer jusqu’à atteindre une valeur simple.

Ces patterns ont influencé la programmation fonctionnelle ultérieure : petites fonctions, cas de base clairs et transformations de données faciles à raisonner. Même hors Lisp, l’habitude de décomposer le travail en « faire une étape, puis répéter sur le reste » conduit à des programmes plus propres et moins d’effets de bord cachés.

Garbage collection : une fonctionnalité de productivité, pas un détail

Les premiers programmeurs devaient souvent gérer la mémoire à la main : allouer de l’espace, suivre qui en « est propriétaire » et se souvenir de le libérer au bon moment. Ce travail ne ralentit pas seulement le développement — il crée une catégorie de bugs difficilement reproductibles et faciles à expédier : fuites qui dégradent silencieusement les performances, et pointeurs pendants qui font crasher un programme bien après l’erreur initiale.

Ce que fait le garbage collection (en termes simples)

John McCarthy a introduit le ramassage des ordures pour Lisp comme moyen de permettre aux programmeurs de se concentrer sur le sens plutôt que sur la paperasserie.

De façon simple, la GC trouve automatiquement les zones mémoire qui ne sont plus accessibles depuis le programme en cours — des valeurs que rien ne peut plus utiliser — et récupère cet espace.

Au lieu de se demander « avons-nous libéré chaque objet exactement une fois ? », la GC repose la question sur « cet objet est-il encore accessible ? ». Si le programme ne peut pas l’atteindre, c’est de la poubelle.

Pourquoi c’est d’abord une histoire de productivité

Pour le travail en IA symbolique, les programmes Lisp créent fréquemment beaucoup de listes, d’arbres et de résultats intermédiaires éphémères. La gestion manuelle de la mémoire transformerait l’expérimentation en une lutte constante avec le nettoyage des ressources.

La GC change l’expérience quotidienne :

• Itération plus rapide : on peut prototyper librement sans concevoir d’abord une stratégie mémoire.
• Moins d’erreurs de crash : des catégories entières d’échecs liés aux pointeurs sont réduites ou éliminées.
• Code plus propre : les fonctions peuvent retourner de nouvelles structures sans contrats cachés sur la libération.

L’idée clé est qu’une caractéristique du langage peut être un multiplicateur d’équipe : moins d’heures passées à déboguer des corruptions mystérieuses signifie plus de temps pour améliorer la logique réelle.

Influence à long terme

Le choix de McCarthy n’est pas resté confiné à Lisp. Beaucoup de systèmes ultérieurs ont adopté la GC (et ses variantes) parce que le compromis paie souvent : Java, C#, Python, les runtimes JavaScript et Go s’appuient tous sur la collecte automatique pour rendre le développement à grande échelle plus sûr et plus rapide — même quand la performance est une priorité.

Évaluation et macros : étendre le langage de l’intérieur

Ce que signifie « évaluer » (sans jargon)

Dans Lisp, une expression est un morceau de code écrit sous une forme cohérente (souvent une liste). L’évaluation est simplement le processus qui décide ce que cette expression veut dire et ce qu’elle produit.

Par exemple, quand vous écrivez quelque chose comme « additionne ces nombres » ou « appelle cette fonction avec ces entrées », l’évaluateur suit un petit ensemble de règles pour tourner cette expression en résultat. Pensez-y comme à l’arbitre du langage : il décide quoi faire ensuite, dans quel ordre et quand s’arrêter.

Pourquoi un évaluateur petit et cohérent est une superpuissance

Le coup clé de McCarthy n’était pas seulement d’inventer une nouvelle syntaxe — c’était de garder le « moteur de sens » compact et régulier. Quand l’évaluateur est construit sur quelques règles claires, deux choses utiles suivent :

• Le langage est plus facile à raisonner, car vous ne jonglez pas avec des dizaines de cas spéciaux.
• Vous pouvez étendre le langage sans réécrire tout le système, parce que de nouvelles fonctionnalités peuvent s’exprimer en termes d’existantes.

Cette cohérence explique en partie pourquoi Lisp est devenu un terrain d’expérimentation pour l’IA symbolique : les chercheurs pouvaient essayer rapidement de nouvelles représentations et structures de contrôle, sans attendre qu’une équipe de compilation refonde le langage.

Macros : automatiser les formes de code

Les macros sont le moyen de Lisp d’automatiser des formes de code répétitives, pas seulement des valeurs répétitives. Là où une fonction vous évite de répéter des calculs, une macro vous évite de répéter des structures — des motifs courants comme « faire X, mais aussi logger », ou « définir un mini-langage pour des règles ».

L’effet pratique est que Lisp peut faire pousser de nouvelles commodités de l’intérieur. Beaucoup d’outils modernes reprennent cette idée — systèmes de templates, générateurs de code et métaprogrammation — parce qu’ils visent le même objectif : expérimentation plus rapide et expression d’intention plus claire.

Si vous voulez voir comment cet état d’esprit a influencé des workflows de développement quotidiens, voyez /blog/the-repl-and-fast-feedback-loops.

Le REPL et les boucles de rétroaction rapides

Une grande partie de l’attrait de Lisp ne venait pas seulement du langage — mais de la façon dont on travaillait avec lui. Lisp a popularisé le REPL : Read–Eval–Print Loop. En termes quotidiens, c’est comme avoir une conversation avec l’ordinateur. Vous tapez une expression, le système l’exécute immédiatement, affiche le résultat, et attend votre prochaine entrée.

Le flux de travail en clair

Au lieu d’écrire tout un programme, le compiler, l’exécuter, puis chercher ce qui a cassé, vous pouvez essayer des idées pas à pas. Vous définissez une fonction, la testez avec quelques entrées, l’ajustez, et testez de nouveau — tout cela en quelques secondes.

Ce rythme encourage l’expérimentation, ce qui comptait beaucoup pour le travail en IA où on ne connaît souvent pas la bonne approche d’emblée.

Pourquoi des boucles de rétroaction serrées changent les résultats

La rétroaction rapide transforme les « gros paris » en « petites vérifications ». Pour la recherche, elle facilite l’exploration d’hypothèses et l’inspection de résultats intermédiaires.

Pour le prototypage produit, elle réduit le coût de l’itération : vous pouvez valider le comportement avec des données réelles rapidement, repérer les cas limites plus tôt et affiner les fonctionnalités sans attendre de longs cycles de build.

C’est aussi pourquoi les outils de type vibe-coding sont séduisants : ils comprimment agressivement la boucle de rétroaction. Par exemple, Koder.ai utilise une interface par chat (avec une architecture agentée en coulisses) pour transformer l’intention produit en code web, backend ou mobile fonctionnel — faisant souvent de la boucle « essayer → ajuster → réessayer » quelque chose de proche d’un REPL plutôt que d’un pipeline traditionnel.

Équivalents modernes que vous connaissez peut-être

L’idée du REPL réapparaît aujourd’hui dans :

• les shells interactifs Python/Node
• Jupyter et autres notebooks
• les consoles des outils de développement du navigateur
• le « live reload » et le hot module replacement dans les apps web

Des outils différents, même principe : raccourcir la distance entre la pensée et la visualisation.

Quand le développement interactif aide le plus

Les équipes profitent le plus des workflows proches du REPL quand elles explorent des exigences incertaines, construisent des fonctionnalités data-heavy, conçoivent des API ou déboguent une logique délicate. Si le travail implique un apprentissage rapide — des utilisateurs, des données ou des cas limites — la rétroaction interactive n’est pas un luxe, c’est un multiplicateur.

Comment les idées de Lisp ont essaimé dans la programmation

Lisp n’a pas « gagné » en devenant la syntaxe quotidienne de tout le monde. Il a gagné en semant des idées qui sont devenues la norme dans de nombreux écosystèmes.

Patrons fonctionnels dans le code courant

Des concepts que Lisp considérait comme par défaut — fonctions comme valeurs, usage intensif d’opérations d’ordre supérieur, préférence pour la composition de petites parties — apparaissent désormais largement. Même des langages qui ne ressemblent pas à Lisp encouragent les transformations map/filter, les habitudes de données immutables et la pensée récursive (souvent via des itérateurs ou des folds).

Le changement mental clé est : traitez les transformations de données comme des pipelines, et le comportement comme quelque chose que vous pouvez passer.

Représentations symboliques : de l’IA aux compilateurs et outils

Lisp a rendu naturel de représenter les programmes comme des données. Cet état d’esprit se retrouve aujourd’hui dans la façon dont on manipule des AST (arbres de syntaxe abstraite) pour les compilateurs, formatters, linters et générateurs de code. Quand vous travaillez avec un AST, vous faites le proche cousin du « code comme données », même si les structures sont des objets JSON, des nœuds typés ou des graphes de bytecode.

La même approche symbolique alimente l’automatisation pratique : formats de configuration, systèmes de templates et pipelines de build s’appuient tous sur des représentations structurées que les outils peuvent inspecter, transformer et valider.

DSLs et extensibilité sans tout réécrire

Les langages de la famille Lisp (au sens large : Lisps contemporains et outils inspirés de Lisp) continuent d’influencer la conception des DSL internes — petits langages ciblés pour tests, déploiement, traitement de données ou UI.

Hors Lisp, les systèmes de macros, bibliothèques de métaprogrammation et frameworks de génération cherchent le même résultat : étendre le langage pour coller au problème.

Une conclusion pragmatique : les préférences de syntaxe changent, mais les idées durables — structure symbolique, fonctions composables et extensibilité — restent payantes à long terme.

Compromis et idées reçues sur Lisp

La réputation de Lisp oscille entre « brillant » et « illisible », souvent sur la base d’impressions de seconde main plutôt que d’expériences quotidiennes. La réalité est plus ordinaire : Lisp fait des choix puissants dans le bon contexte et gênants dans d’autres.

« Trop de parenthèses » (et la question de la lisibilité)

Pour les nouveaux venus, la syntaxe uniforme de Lisp donne l’impression d’examiner l’« intérieur » d’un programme plutôt que sa surface polie. Cette gêne est réelle, surtout si vous êtes habitué à des langages où la syntaxe sépare visuellement différents constructs.

Historiquement, cependant, la structure de Lisp est aussi son avantage : code et données partagent la même forme, ce qui rend les programmes plus faciles à transformer, générer et analyser. Avec un bon support d’éditeur (indentation, navigation structurelle), le code Lisp se lit souvent par sa forme plutôt que par le comptage des parenthèses.

Performances : mythe, histoire et réalité actuelle

Un stéréotype courant veut que Lisp soit lent. Historiquement, certaines implémentations souffraient face aux langages bas niveau, et les fonctionnalités dynamiques peuvent ajouter une overhead.

Mais il n’est pas exact de traiter « Lisp » comme un profil de performance unique. Beaucoup de systèmes Lisp ont depuis longtemps des compilateurs, des déclarations de types et des optimisations sérieuses. Le meilleur cadrage est : de combien de contrôle avez-vous besoin sur la disposition mémoire, la latence prévisible ou le débit brut — et votre implémentation Lisp cible-t-elle ces besoins ?

Écosystème et recrutement : contraintes pratiques

Une critique juste est l’adéquation de l’écosystème. Selon le dialecte et le domaine, les bibliothèques, outils et viviers de talents peuvent être plus restreints que les stacks grand public. Cela peut peser davantage que l’élégance du langage si vous devez livrer rapidement avec une large équipe.

Un bilan équilibré

Plutôt que de juger Lisp sur ses stéréotypes, évaluez ses idées sous-jacentes : structure uniforme, développement interactif et macros comme outil pour construire des abstractions spécifiques au domaine. Même si vous ne déployez jamais un système Lisp, ces concepts affinent votre réflexion sur la conception des langages et la manière d’écrire du code dans n’importe quel langage.

Enseignements pratiques pour la conception des langages et le code quotidien

McCarthy ne nous a pas seulement laissé un langage historique — il a laissé un ensemble d’habitudes qui rendent encore le logiciel plus facile à changer, expliquer et étendre.

6 leçons à emprunter

1. Préférez des noyaux simples plutôt que des surfaces futées. Un petit ensemble de briques orthogonales est plus facile à apprendre et plus robuste.
2. Uniformisez les formes de données. Quand beaucoup de choses partagent la même représentation (listes/arbres), les outils deviennent plus simples : imprimantes, débogueurs, sérialiseurs et transformeurs se réutilisent.
3. Traitez programmes comme données (et données comme programmes) quand c’est utile. Si vous pouvez inspecter et transformer des structures, vous pouvez construire des refactors, des migrations et des générateurs de code plus sûrs.
4. Automatisez le travail ennuyeux. Le GC est l’exemple classique, mais le point général est : investissez dans l’automatisation qui évite des classes entières d’erreurs.
5. Optimisez les boucles de rétroaction. L’évaluation interactive (style REPL) favorise de petites expériences, une vérification rapide et une meilleure intuition sur le comportement.
6. Faites de l’extension un objectif de conception prioritaire. Les macros Lisp en sont une réponse ; dans d’autres écosystèmes, cela peut être des plugins, templates, DSLs ou transformations à la compilation.

Un petit exercice (10 minutes)

Avant de choisir une bibliothèque ou une architecture, prenez une fonctionnalité réelle — disons « règles de réduction » ou « routage de tickets support » — et dessinez-la comme un arbre. Puis réécrivez cet arbre comme des listes imbriquées (ou du JSON). Demandez-vous : quels sont les nœuds, quelles sont les feuilles, et quelles transformations sont nécessaires ?

Intégrer les idées de Lisp dans n’importe quelle stack

Même sans Lisp, vous pouvez adopter l’état d’esprit : construisez des représentations de type AST, utilisez la génération de code pour lier des éléments répétitifs, et standardisez des pipelines data-first (parse → transform → evaluate). Beaucoup d’équipes en tirent profit simplement en rendant explicites leurs représentations intermédiaires.

Si le principe REPL vous séduit mais que vous livrez des features dans des stacks mainstream, vous pouvez emprunter l’esprit via des outils : boucles d’itération courtes, snapshots/rollback et planification explicite avant exécution. Koder.ai, par exemple, inclut un mode de planification plus des snapshots et rollback pour rendre l’itération rapide plus sûre — un écho opérationnel du principe Lisp « changer vite, mais garder le contrôle ».

L’influence durable de McCarthy est la suivante : la programmation devient plus puissante quand nous rendons le raisonnement lui-même programmable — et quand nous gardons le chemin de l’idée au système exécutable aussi direct que possible.