De auteur beargumenteert dat Common Lisp een betere keuze is voor AI-gestuurde codegeneratie ('vibe coding') dan populaire talen zoals Python of Java. De belangrijkste redenen hiervoor zijn:
- Expertise en Abstractie: Diepgaande kennis van de taal stelt de menselijke architect in staat om AI effectiever aan te sturen, terwijl Lisp zich richt op hoogwaardige abstracties in plaats van boilerplate-code.
- Technische Voordelen: Door homoiconiciteit kan een LLM direct op het niveau van de Abstract Syntax Tree (AST) opereren. Daarnaast maken macro's contextcompressie mogelijk, waardoor er minder tokens worden verbruikt binnen het geheugenvenster van het model.
- Interactieve Workflow: Het gebruik van een REPL maakt live-introspectie en razendsnelle iteraties mogelijk zonder dat het programma volledig herstart hoeft te worden.
- Foutafhandeling: Dankzij het condition system kan de AI fouten interactief debuggen op het punt waar ze ontstaan, in plaats van simpelweg te crashen.
Waarom 'vibe coden' in Lisp?
Waarom niet kiezen voor Python, TypeScript of Java? Dit zijn mainstream talen met enorme trainingssets, waardoor modellen code in deze talen met een hoge statistische nauwkeurigheid kunnen genereren. Waarom dan toch kiezen voor een nichetaal zoals Common Lisp als doeltaal voor codegeneratie?
Er zijn veel redenen voor, maar ze komen allemaal neer op dezelfde oude vraag: waarom zou je Lisp gebruiken als je ook een populairdere taal kunt gebruiken? Het antwoord is dat de populariteit van een taal een slechte graadmeter is voor het nut en de expressiviteit ervan. De Lisp-gemeenschap weet dit allang; dat is precies waarom we in eerste instantie voor Lisp kozen. Selecteren op basis van populariteit is wat middenmanagers doen om er zeker van te zijn dat ze altijd wel iemand kunnen vinden om de code te onderhouden. Dat is niet hoe elite hackers te werk gaan.
De basis van expertise
Ten eerste programmeer ik al decennia in Common Lisp. Ik ken de taal door en door. Vibe coding vereist een menselijke architect die de machine begeleidt. Wanneer ik naar de door het model gegenereerde code kijk, kan ik in een fractie van een seconde zien of het goed is, of dat het model een doodlopend spoor hallucineert. Je kunt een AI niet succesvol aansturen in een taal die je niet diepgaand begrijpt.
Abstractie boven implementatie
De meeste moderne talen dwingen je om exact te beschrijven hoe een machine bits moet verschuiven. Lisp is ontworpen als een taal voor het uitdrukken van abstracties op hoog niveau, in plaats van het uitwerken van saaie implementatiedetails. Wanneer ik de AI aanstuur, wil ik dat deze architecturale logica genereert en niet worstelt met boilerplate-code om simpelweg basisstatus te beheren.
Ontworpen voor de elite
Laten we eerlijk zijn: Lisp is een taal die door en voor elite hackers is ontworpen, niet voor de massa. Het houdt je hand niet vast en speelt niet in op de patronen van programmeer-bootcamps voor de laagste gemene deler. Wanneer je het als doeltaal gebruikt, opereer je in een omgeving die is gebouwd voor maximale expressiviteit.
Homoiconiciteit en de AST
Dit is wellicht het grootste technische voordeel. Lisp is homoiconisch: de code is gestructureerd als de data die het manipuleert. Wanneer een LLM Python of Java genereert, moet het de oppervlaktesyntaxis voorspellen: witregels, haken, puntkomma's en rigide klassenstructuren. Wanneer een LLM Lisp genereert, opereert het direct op het niveau van de Abstract Syntax Tree (AST). Het voorspelt pure structuur. Het wegnemen van deze syntactische wrijving is een enorm voordeel voor AI-codegeneratie.
Macro's als contextcompressie
Bij vibe coding is het contextvenster van het LLM je kostbaarste bezit. Het macrosysteem van Lisp maakt een zeer effectieve vorm van contextcompressie mogelijk. In plaats van dat de AI herhaaldelijk uitgebreide boilerplate-code genereert, kun je die boilerplate verbergen achter een macro. De AI leert de macro, gebruikt deze en bespaart zo duizenden tokens. Hierdoor kun je enorme architecturen onderhouden binnen de geheugenbeperkingen van het model.
Introspectie in de REPL
Ik gebruik het LLM niet in een steriele teksteditor, maar vanuit een Lisp REPL. Dit steltHet LLM in staat om het programma te inspecteren terwijl het in ontwikkeling is. Als we de status van een specifiek object of een functie moeten weten, kan het model de live-omgeving bevragen. Je schrijft geen dode tekst; je voert een gesprek met een levend systeem.
Superieure foutafhandeling
Wanneer de AI slechte code schrijft (en dat zal gebeuren), biedt het condition system van Lisp superieure mogelijkheden voor foutafhandeling en debugging. In plaats van een harde crash die een volledige herstart vereist, wordt de fout opgevangen. Het LLM kan vervolgens de stack trace analyseren en de gegenereerde code interactief debuggen, precies op het punt waar het misging.
Geen 'ab initio' herstarts
Het gebruik van de REPL betekent dat je je programma niet elke keer ab initio (vanaf het begin) hoeft op te starten om een wijziging te testen. In een gecompileerde mainstream taal vereist een AI-fix van één regel vaak een volledige rebuild en een reset van de status. In Lisp herdefinieer je simpelweg de specifieke functie en test je deze direct in de REPL, terwijl de rest van de status van de applicatie perfect intact blijft. De iteratiesnelheid is ongeëvenaard.
Je geeft een elite hacker geen 'code-monkey' taal. Ik wil dat mijn AI een elite hacker is, niet simpelweg een code-monkey. Als ik verwacht dat mijn AI op een elite niveau presteert, moet ik het voorzien van elite instrumenten, en niet van een taal voor code-monkeys.
Waarom 'vibe coden' in Lisp?
Waarom niet kiezen voor Python, TypeScript of Java? Dit zijn mainstream talen met enorme trainingssets, waardoor modellen code in deze talen met een hoge statistische nauwkeurigheid kunnen genereren. Waarom dan toch kiezen voor een nichetaal zoals Common Lisp als doeltaal voor codegeneratie?
Er zijn veel redenen voor, maar ze komen allemaal neer op dezelfde oude vraag: waarom zou je Lisp gebruiken als je ook een populairdere taal kunt gebruiken? Het antwoord is dat de populariteit van een taal een slechte graadmeter is voor het nut en de expressiviteit ervan. De Lisp-gemeenschap weet dit allang; dat is precies waarom we in eerste instantie voor Lisp kozen. Selecteren op basis van populariteit is wat middenmanagers doen om er zeker van te zijn dat ze altijd wel iemand kunnen vinden om de code te onderhouden. Dat is niet hoe elite hackers te werk gaan.
De basis van expertise
Ten eerste programmeer ik al decennia in Common Lisp. Ik ken de taal door en door. Vibe coding vereist een menselijke architect die de machine begeleidt. Wanneer ik naar de door het model gegenereerde code kijk, kan ik in een fractie van een seconde zien of het goed is, of dat het model een doodlopend spoor hallucineert. Je kunt een AI niet succesvol aansturen in een taal die je niet diepgaand begrijpt.
Abstractie boven implementatie
De meeste moderne talen dwingen je om exact te beschrijven hoe een machine bits moet verschuiven. Lisp is ontworpen als een taal voor het uitdrukken van abstracties op hoog niveau, in plaats van het uitwerken van saaie implementatiedetails. Wanneer ik de AI aanstuur, wil ik dat deze architecturale logica genereert en niet worstelt met boilerplate-code om simpelweg basisstatus te beheren.
Ontworpen voor de elite
Laten we eerlijk zijn: Lisp is een taal die door en voor elite hackers is ontworpen, niet voor de massa. Het houdt je hand niet vast en speelt niet in op de patronen van programmeer-bootcamps voor de laagste gemene deler. Wanneer je het als doeltaal gebruikt, opereer je in een omgeving die is gebouwd voor maximale expressiviteit.
Homoiconiciteit en de AST
Dit is wellicht het grootste technische voordeel. Lisp is homoiconisch: de code is gestructureerd als de data die het manipuleert. Wanneer een LLM Python of Java genereert, moet het de oppervlaktesyntaxis voorspellen: witregels, haken, puntkomma's en rigide klassenstructuren. Wanneer een LLM Lisp genereert, opereert het direct op het niveau van de Abstract Syntax Tree (AST). Het voorspelt pure structuur. Het wegnemen van deze syntactische wrijving is een enorm voordeel voor AI-codegeneratie.
Macro's als contextcompressie
Bij vibe coding is het contextvenster van het LLM je kostbaarste bezit. Het macrosysteem van Lisp maakt een zeer effectieve vorm van contextcompressie mogelijk. In plaats van dat de AI herhaaldelijk uitgebreide boilerplate-code genereert, kun je die boilerplate verbergen achter een macro. De AI leert de macro, gebruikt deze en bespaart zo duizenden tokens. Hierdoor kun je enorme architecturen onderhouden binnen de geheugenbeperkingen van het model.
Introspectie in de REPL
Ik gebruik het LLM niet in een steriele teksteditor, maar vanuit een Lisp REPL. Dit steltHet LLM in staat om het programma te inspecteren terwijl het in ontwikkeling is. Als we de status van een specifiek object of een functie moeten weten, kan het model de live-omgeving bevragen. Je schrijft geen dode tekst; je voert een gesprek met een levend systeem.
Superieure foutafhandeling
Wanneer de AI slechte code schrijft (en dat zal gebeuren), biedt het condition system van Lisp superieure mogelijkheden voor foutafhandeling en debugging. In plaats van een harde crash die een volledige herstart vereist, wordt de fout opgevangen. Het LLM kan vervolgens de stack trace analyseren en de gegenereerde code interactief debuggen, precies op het punt waar het misging.
Geen 'ab initio' herstarts
Het gebruik van de REPL betekent dat je je programma niet elke keer ab initio (vanaf het begin) hoeft op te starten om een wijziging te testen. In een gecompileerde mainstream taal vereist een AI-fix van één regel vaak een volledige rebuild en een reset van de status. In Lisp herdefinieer je simpelweg de specifieke functie en test je deze direct in de REPL, terwijl de rest van de status van de applicatie perfect intact blijft. De iteratiesnelheid is ongeëvenaard.
Je geeft een elite hacker geen 'code-monkey' taal. Ik wil dat mijn AI een elite hacker is, niet simpelweg een code-monkey. Als ik verwacht dat mijn AI op een elite niveau presteert, moet ik het voorzien van elite instrumenten, en niet van een taal voor code-monkeys.
Groetjes,