Carnap Ten Years Later: Lessons Learned and Next Steps

Imaginez que vous essayez d'enseigner la résolution de puzzles logiques à une classe de 45 000 étudiants. Vous voulez qu'ils s'exercent chaque jour, mais corriger des milliers de preuves manuscrites à la main est un cauchemar. Alors, vous construisez un robot professeur.

C'est exactement ce que Graham Leach-Krouse a fait avec Carnap, un outil basé sur le web qui a corrigé plus de quatre millions de problèmes de logique pour des étudiants du monde entier au cours de la dernière décennie. Mais après dix ans de fonctionnement de ce robot, l'auteur s'est rendu compte que le robot devenait un peu maladroit, et qu'il est temps de construire une toute nouvelle version, ultra-élégante.

Voici l'histoire de ce qui a bien fonctionné, de ce qui a mal tourné, et des nouveaux outils brillants en cours de construction pour y remédier.

Le robot original : Un génie un peu désordonné

Le Carnap original a été construit comme un immense couteau suisse tout-en-un. Il a été écrit dans un langage de programmation très sophistiqué appelé Haskell. L'auteur voulait qu'il soit gratuit (aucun coût pour les étudiants), basé sur le web (pas d'installations de logiciels ennuyeuses) et flexible (capable d'enseigner n'importe quel type de logique, de la mathématique simple à la philosophie complexe).

Ce qui a fonctionné :

• Le Web : Le mettre sur un site web a été une victoire majeure. Les étudiants n'avaient pas à lutter avec des écrans d'installation ; ils n'avaient qu'à cliquer sur un lien.
• La boucle de rétroaction : Le meilleur aspect était le « feedback instantané ». Pendant qu'un étudiant tapait une preuve, le robot la vérifiait ligne par ligne. S'il faisait une erreur, le robot disait immédiatement : « Non, réessaie ». Cela permettait aux étudiants de rester dans un « état de flow », où ils avaient l'impression de jouer à un jeu plutôt que de faire leurs devoirs.
• La Flexibilité : L'auteur a utilisé une astuce ingénieuse (appelée l'algorithme de Huet) pour permettre au robot de comprendre des dizaines de manuels de logique différents. C'était comme avoir un traducteur capable de parler instantanément tous les dialectes de la logique.

Ce qui n'a pas fonctionné :

• Le piège du « Tout-en-un » : L'auteur a essayé de tout faire dans un seul gros bloc de code. La partie qui dessinait les images, la partie qui vérifiait les mathématiques et la partie qui enregistrait les notes étaient toutes emmêlées. Si vous vouliez corriger un minuscule bug dans le vérificateur de mathématiques, vous pouviez accidentellement casser le système d'enregistrement des notes. C'était comme essayer de réparer le moteur d'une voiture pendant que les roues tournent encore.
• Le « Facteur Bus » : Parce que le code était si emmêlé et utilisait une configuration très spécifique et difficile à installer, il était presque impossible pour d'autres personnes d'aider. Si le constructeur principal se faisait renverser par un bus (une blague classique de programmeur concernant la perte de la seule personne qui comprend le fonctionnement du système), le projet risquait de mourir.
• Le problème de confiance : Les étudiants ont besoin de faire confiance au robot. Si le robot bugue, donne un message d'erreur déroutant ou agit bizarrement, les étudiants cessent de faire confiance à la logique elle-même. Ils commencent à penser : « Le robot est cassé », au lieu de « J'ai fait une erreur ». Le système original avait trop de petits bugs qui brisaient cette confiance.

Le diagnostic : Pourquoi le vieux robot doit prendre sa retraite

L'auteur a regardé l'ancien système et a réalisé qu'il était construit sur une architecture de « double monolithe ». Imaginez une maison où la cuisine, la chambre et la salle de bain sont une seule et même pièce géante sans murs. Vous ne pouvez pas rénover la cuisine sans abattre la salle de bain.

Le problème spécifique était la technologie utilisée pour l'exécuter dans le navigateur. L'auteur utilisait un outil appelé GHCJS pour transformer le code sophistiqué en code web. Mais cet outil est désormais « obsolète » (en gros, il a été retiré par ses créateurs). Essayer de mettre à jour l'ancien système reviendrait à essayer de remplacer le moteur d'une voiture avec une pièce qui ne correspond plus. Ce serait douloureux, coûteux et probablement voué à l'échec.

Le nouveau design : Le rêve « Modulaire »

Le papier propose une refonte complète, divisant le robot géant en trois petits robots spécialisés qui communiquent entre eux.

1. Le minuscule vérificateur (mm0-zig) : C'est le « cerveau » qui vérifie si une preuve est réellement correcte. Il est écrit dans un nouveau langage appelé Zig et est incroyablement petit — environ 4 500 lignes de code. Comme il est si petit, un humain peut lire l'ensemble et dire : « Oui, c'est digne de confiance ». Il est conçu pour vérifier les preuves en un clin d'œil (moins de 200 millisecondes pour une immense bibliothèque de mathématiques).
2. Le compilateur (Aufbau Bytecode Compiler ou abc) : C'est le « traducteur ». Il prend la manière désordonnée et complexe dont un étudiant tape sa preuve (peut-être en utilisant un éditeur visuel sophistiqué) et la transforme en un certificat binaire propre. Il ne se soucie pas de comment l'étudiant l'a écrit ; il s'assure simplement que le résultat final est valide.
3. Le Serveur : C'est simplement le « classeur ». Il stocke les devoirs et les notes. Il ne fait aucun travail intellectique lourd ; il gère simplement les données.

La magie du nouveau système :

• Plus de fils emmêlés : Si vous voulez ajouter un nouveau type de logique (comme un nouveau manuel), vous n'avez pas besoin de réécrire le cerveau ou le classeur. Il vous suffit de donner au compilateur un nouvel ensemble de règles.
• Digne de confiance : Le « cerveau » (mm0-zig) est si petit et simple qu'il peut être audité par une seule personne. Une fois vérifié, il n'a plus jamais besoin d'être modifié.
• Rapide : Le nouveau vérificateur est presque aussi rapide que l'original basé sur C, tournant à environ 7,1 millisecondes en moyenne pour un cas de test spécifique (contre 6,1 millisecondes pour l'ancien), ce qui est assez rapide pour paraître instantané pour un humain.

L'avenir : Et maintenant ?

L'auteur admet que le nouveau système n'est pas encore terminé. Pour l'instant, le « traducteur » (abc) fonctionne mieux avec un éditeur de texte, ce qui peut encore être intimidant pour un débutant dans son premier cours de logique. Le plan est de construire des interfaces visuelles plus riches (comme des arbres de preuve par glisser-déposer) qui communiquent avec le traducteur.

La grande leçon ici ne concerne pas seulement le code ; c'est une question de confiance. Que vous soyez étudiant, enseignant ou codeur, vous avez besoin de faire confiance à l'outil que vous utilisez. L'ancien Carnap était un héros qui a fait le travail, mais il était désordonné. Le nouveau Carnap est en train d'être construit pour être agile, efficace et transparent, afin que les étudiants puissent se concentrer sur la logique, et non sur la lutte contre le logiciel.

En bref : l'ancien robot était un génie brillant mais désordonné. Le nouveau robot est une équipe d'experts spécialisés et dignes de confiance, prêts à aider la prochaine génération de penseurs à échapper à la gravité de la confusion et à atteindre la « vitesse de libération » de leur propre raisonnement.