Waarom Common Lisp nu de beste programmeertaal is

Zou je het ermee eens zijn dat sommige programmeertalen beter zijn dan andere? Zo ja, dan moet er één de beste zijn. En dat is eigenlijk Common Lisp, vooral nu LLM's (Large Language Models) code kunnen schrijven.

LLM's schrijven code erg snel, en dat verandert veel, omdat het schrijven van code vroeger het langzame gedeelte was. Nu is het langzame gedeelte het uitzoeken of je programma daadwerkelijk werkt, en voordat je dat kunt doen moet je het opnieuw opbouwen, wat enkele minuten kan duren.

Wanneer mensen de code schreven, maakte dit niet veel uit, omdat schrijven veel langer duurde dan wachten tot het gecompileerd was en begon te draaien. Maar nu maakt het wel uit, dus de duur van je feedbackloop bepaalt hoe snel je kunt bouwen.

In Common Lisp bestaat die loop bijna niet, omdat er geen echt onderscheid is tussen read-time, compile-time en runtime (Graham). Common Lisp is image-gebaseerd, wat betekent dat je programma een live image in het geheugen is; een nieuwe versie van een functie vervangt de oude direct, zonder dat er iets herstart hoeft te worden.

Daarnaast zal in de meeste talen een fout je programma laten crashen. Als je code schrijft met een LLM, moet deze de crashlogs lezen om wijzigingen aan te brengen en je programma opnieuw uit te voeren. In Common Lisp zal je programma niet crashen; het stopt en opent een debugger met de volledige stack en alle variabelen. Je kunt je LLM simpelweg naar de debugger laten kijken, waarna deze de fout herstelt en het programma hervat.

Voor zover ik weet is Common Lisp de enige mainstream taal die dit alles doet.

Lisp als lijstverwerking

Lisp staat voor "List Processing". In Common Lisp wordt code geschreven als lijsten. Bijvoorbeeld: (+ 1 2) is een programma dat twee getallen optelt, maar het is ook gewoon een lijst van drie dingen: het symbool + en de getallen 1 en 2.

Wat interessant is, is dat dit hetzelfde soort lijst is dat Common Lisp gebruikt om data op te slaan. Aangezien de taal is gebouwd rond het verwerken van lijsten, werken al zijn tools voor het werken met data ook op code. Een programma kan dus een ander programma nemen en wijzigen; het kan bijvoorbeeld (+ 1 2) veranderen in (* 1 2) en het resultaat direct uitvoeren.

Dit is wat macros mogelijk maakt. Een macro is een functie die je code neemt en nieuwe code op die plek teruggeeft, wat betekent dat je nieuwe constructies aan de taal zelf kunt toevoegen.

Zodra je aan de taal kunt toevoegen, kun je deze afstemmen op jouw probleem. In Lisp schrijf je dus niet alleen een programma, maar schrijf je een taal voor jouw domein en schrijf je vervolgens het programma in die taal.

De waarde van domeinspecifieke talen en LLM's

Dit is nu veel belangrijker, omdat wat een programma waardevol maakt, de visies (opinions) zijn die erachter zitten. We gaan naar een wereld waarin softwarebedrijven hun gebruikers toestaan het product zelf aan te passen, aangezien dat met een LLM eenvoudig is. Als een bedrijf een goede, opiniematige domeintaal voor zijn product bouwt, zal alles wat gebruikers daarop bouwen veel beter zijn, omdat ze vertrekken vanuit de visies van het bedrijf en niet vanaf nul.

Neem een ERP-systeem. Elk bedrijf werkt net iets anders, dus bijna iedereen moet het uiteindelijk aanpassen. Maar als het ERP is geschreven in een eigen domeintaal, kun je een LLM simpelweg vragen de wijziging in die taal aan te brengen. De wijziging zal natuurlijk de onderliggende visies van de domeintaal volgen, waardoor het in het product past in plaats van het te breken.

Bovendien is het niet alleen beter, maar ook goedkoper. Lisp-programma's zijn vaak veel beknopter omdat macros je in staat stellen om terugkerende patronen te abstraheren en ze onderdeel te maken van de taal zelf. Hoe groter het programma wordt, hoe groter het verschil. Uit mijn eigen ervaring blijkt dat de apps die ik in Common Lisp heb gebouwd, ongeveer zes tot zeven keer korter zijn dan de Python-versies.

Voor LLM's betekent minder code minder tokens, en tokens zijn waar je voor betaalt, dus je geeft minder uit aan ontwikkeling.

Het betekent ook dat een groter deel van je programma in het contextvenster van de LLM past. Als de LLM je volledige programma in zijn contextvenster heeft, heeft hij een compleet beeld van je bedoeling, wat leidt tot betere beslissingen. In mijn ervaring komen veel LLM-bugs voort uit het feit dat er één deel van mijn programma wordt gewijzigd zonder de rest te zien. Met Common Lisp gebeurt dat minder vaak.

Stabiliteit en bibliotheken

Common Lisp is een ANSI-standaard en is sinds 1994 niet meer bijgewerkt. Ik houd van deze eigenschap. Teruggaand naar het ERP-voorbeeld: als je gebruikers het product zelf aanpassen, is dit precies wat je wilt, aangezien de taal eronder nooit verschuift en niets wat ze erop bouwen ooit kapot gaat.

Wanneer je een programma schrijft in Common Lisp, zul je vaak merken dat je de bibliotheek die je nodig hebt niet kunt vinden. Quicklisp, de belangrijkste pakketbeheerder voor Common Lisp, heeft een paar duizend projecten, terwijl npm er miljoenen heeft.

Maar ik denk niet dat dit meer een probleem is. De meeste programma's van tegenwoordig zijn afhankelijk van miljoenen regels code uit pakketten die steeds vaker gecompromitteerd worden. Dat wil je niet in jouw project. Bovendien kun je met een LLM gewoon het deel dat je nodig hebt zelf schrijven of de hele bibliotheek porten — en LLM's lijken erg goed te zijn in het porten van code.

Technische personeelsbezetting

Ten slotte merk ik dat veel mensen nu programmeren in de hoop een bedrijf op te bouwen. Een voor de hand liggende bezwaar tegen het bouwen van producten in Common Lisp is dat je het moeilijk zult hebben om engineers te vinden, aangezien zo weinig mensen weten hoe ze erin moeten programmeren.

Maar ik denk niet dat dat nu echt uitmaakt. Als je een succesvol bedrijf wilt bouwen, wil je de beste technische mensen aannemen: zij die echt goed zijn in het leren van nieuwe dingen. Laat ze in je sollicitatiegesprekken dus gewoon Common Lisp leren, en voilà. Je zult zien hoe snel mensen dingen oppikken, en degenen die het goed doen, zullen waarschijnlijk blijven leren en er echt goed in worden.

Concluderend: de volgende keer dat je een programma wilt schrijven, gebruik dan Common Lisp.

Bronvermelding

Graham, Paul. "What Made Lisp Different." Paul Graham, mei 2002, paulgraham.com/diff.html. Geraadpleegd op 5 okt. 2026.