Carnap Ten Years Later: Lessons Learned and Next Steps

Stel je voor dat je een klas van 45.000 studenten probeert te leren hoe ze logische puzzels oplossen. Je wilt dat ze elke dag oefenen, maar het handmatig nakijken van duizenden handgeschreven bewijzen is een nachtmerrie. Dus bouw je een robotleraar.

Dat is precies wat Graham Leach-Krouse deed met Carnap, een webgebaseerde tool die de afgelopen tien jaar meer dan vier miljoen logica-problemen heeft nagekeken voor studenten wereldwijd. Maar na tien jaar draaien van deze robot realiseerde de auteur zich dat de robot een beetje onhandig werd, en is het tijd om een gloednieuwe, superstrakke versie te bouwen.

Dit is het verhaal van wat goed ging, wat misging, en de glimmende nieuwe tools die worden gebouwd om het op te lossen.

De Originele Robot: Een Beetje een Rommelige Genius

De originele Carnap werd gebouwd als een gigantisch, alles-in-één Zwitsers zakmes. Het was geschreven in een zeer chique programmeertaal genaamd Haskell. De auteur wilde dat het gratis was (geen kosten voor studenten), webgebaseerd (geen irritante software-installaties), en flexibel (in staat om elke soort logica te onderwijzen, van eenvoudige wiskunde tot complexe filosofie).

Wat werkte:

• Het Web: Het op een website plaatsen was een grote overwinning. Studenten hoefden niet te vechten met installatieschermen; ze hoefden alleen maar op een link te klikken.
• De Feedbackloop: Het beste deel was de "onmiddellijke feedback". Terwijl een student een bewijs typte, controleerde de robot dit regel voor regel. Als ze een fout maakten, zei het direct: "Nee, probeer het opnieuw". Dit hield studenten in een "flow-toestand", waarbij ze het gevoel hadden dat ze een spel speelden in plaats van huiswerk te maken.
• De Flexibiliteit: De auteur gebruikte een slimme truc (genaamd Huet's algoritme) om de robot tientallen verschillende logica-leerboeken te laten begrijpen. Het was alsoals een vertaler hebben die elke dialect van de logica direct kon spreken.

Wat niet werkte:

• De "Alles-in-één" Valstrik: De auteur probeerde alles in één groot blok code te doen. Het deel dat de plaatjes tekende, het deel dat de wiskunde controleerde, en het deel dat de cijfers opsloeg, waren allemaal met elkaar verstrengeld. Als je een kleine bug in de wiskundenchecker wilde repareren, kon je per ongeluk het systeem voor het opslaan van cijfers kapotmaken. Het was alsof je de motor van een auto probeert te repareren terwijl de wielen nog draaien.
• De "Bus Factor": Omdat de code zo verstrengeld was en een zeer specifieke, moeilijk te installeren opzet gebruikte, was het bijna onmogelijk voor anderen om te helpen. Als de hoofdgebruiker door een bus zou worden geraakt (een klassieke programmeursgrap over het verliezen van de enige persoon die weet hoe het systeem werkt), zou het project misschien gestorven zijn.
• Het Vertrouwensprobleem: Studenten moeten de robot vertrouwen. Als de robot een foutje maakt, een verwarrende foutmelding geeft of vreemd doet, stoppen studenten met het vertrouwen in de logica zelf. Ze gaan denken: "De robot is kapot," in plaats van "Ik heb een fout gemaakt." Het originele systeem had te veel kleine glitchjes die dit vertrouwen braken.

De Diagnose: Waarom de Oude Robot Pensioen Nodig Heeft

De auteur keek naar het oude systeem en realiseerde zich dat het gebouwd was op een "dual-monolith" architectuur. Denk aan een huis waar de keuken, de slaapkamer en de badkamer één grote kamer zijn zonder muren. Je kunt de keuken niet renoveren zonder de badkamer af te breken.

Het specifieke probleem was de technologie die werd gebruikt om het in de browser te draaien. De auteur gebruikte een tool genaamd GHCJS om de chique code om te zetten in webcode. Maar die tool is nu "deprecated" (basis: het is door de makers met pensioen gestuurd). Het proberen bijwerken van het oude systeem zou zijn alsof je de motor van een auto probeert te vervangen door een onderdeel dat niet past. Het zou pijnlijk, duur en waarschijnlijk kansloos zijn.

Het Nieuwe Ontwerp: De "Modulaire" Droom

Het paper stelt een volledige herontwerp voor, waarbij de gigantische robot wordt opgesplitst in drie gespecialiseerde, kleine robots die met elkaar communiceren.

1. De Kleine Verifier (mm0-zig): Dit is de "hersenen" die controleert of een bewijs daadwerkelijk correct is. Het is geschreven in een nieuwe taal genaamd Zig en is ongelooflijk klein—slechts ongeveer 4.500 regels code. Omdat het zo klein is, kan een mens het hele ding lezen en zeggen: "Ja, dit is betrouwbaar." Het is ontworpen om bewijzen in een flits te controleren (onder de 200 milliseconden voor een enorme bibliotheek aan wiskunde).
2. De Compiler (Aufbau Bytecode Compiler of abc): Dit is de "vertaler". Het neemt de rommelige, complexe manier waarop een student zijn bewijs typt (miss misschien met een chique visuele editor) en zet dit om in een schone, binaire certificering. Het geeft niet om hoe de student het schreef; het zorgt er alleen voor dat het eindresultaat geldig is.
3. De Server: Dit is slechts de "archiefkast". Het slaat de opdrachten en cijfers op. Het doet geen zwaar denkwerk; het beheert alleen de gegevens.

De Magie van het Nieuwe Systeem:

• Geen Verstrengelde Draden Meer: Als je een nieuw type logica wilt toevoegen (zoals een nieuw leerboek), hoef je niet de hersenen of de archiefkast te herschrijven. Je geeft de compiler gewoon een nieuwe set regels.
• Betrouwbaar: De "hersenen" (mm0-zig) zijn zo klein en simpel dat ze door één persoon gecontroleerd kunnen worden. Zodra dit gecontroleerd is, hoeven ze nooit meer te veranderen.
• Snel: De nieuwe verifier is bijna net zo snel als de originele C-gebaseerde versie, en draait gemiddeld op ongeveer 7,1 milliseconden voor een specifieke testcase (vergeleken met 6,1 milliseconden voor de oude versie), wat snel genoeg is om instant aan te voelen voor een mens.

De Toekomst: Wat Volgt Er?

De auteur geeft toe dat het nieuwe systeem nog niet af is. Op dit moment werkt de "vertaler" (abc) het beste met een tekstverwerker, wat voor een beginner in hun eerste logica-les misschien nog steeds te eng kan zijn. Het plan is om rijkere visuele interfaces te bouwen (zoals drag-and-drop bewijsstructuren) die met de vertaler communiceren.

De grote les hier gaat niet alleen over code; het gaat over vertrouwen. Of je nu een student, een docent of een programmeur bent, je moet het hulpmiddel vertrouwen dat je gebruikt. De originele Carnap was een held die de klus klaarde, maar het was rommelig. De nieuwe Carnap wordt gebouwd om slank, effectief en transparant te zijn, zodat studenten zich kunnen concentreren op de logica, en niet op het vechten tegen de software.

Kortom: de oude robot was een briljante maar rommelige genius. De nieuwe robot is een team van gespecialiseerde, betrouwbare experts, klaar om de volgende generatie denkers te helpen de zwaartekracht van verwarring te ontsnappen en "ontsnappingssnelheid" te bereiken in hun eigen redenering.