De Gemiddelden Verslaan

Wil je een startup beginnen? Word gefinancierd door Y Combinator.

---

April 2001, rev. April 2003

(Dit artikel is gebaseerd op een lezing op het Franz Developer Symposium van 2001.)

In de zomer van 1995 begonnen mijn vriend Robert Morris en ik een startup genaamd Viaweb. Ons plan was om software te schrijven waarmee eindgebruikers online winkels konden bouwen. Wat destijds nieuw was aan deze software, was dat deze op onze server draaide, met gewone webpagina's als interface.

Veel mensen hadden tegelijkertijd dit idee kunnen hebben, natuurlijk, maar voor zover ik weet, was Viaweb de eerste webgebaseerde applicatie. Het leek ons zo'n nieuw idee dat we het bedrijf ernaar vernoemden: Viaweb, omdat onze software via het web werkte, in plaats van op je desktopcomputer te draaien.

Een ander ongebruikelijk ding aan deze software was dat het voornamelijk was geschreven in een programmeertaal genaamd Lisp. Het was een van de eerste grote eindgebruikersapplicaties die in Lisp was geschreven, dat tot dan toe voornamelijk in universiteiten en onderzoekslaboratoria werd gebruikt.[1]

Het Geheime Wapen

Eric Raymond heeft een essay geschreven genaamd "How to Become a Hacker", en daarin vertelt hij onder andere aan aspirant-hackers welke talen ze moeten leren. Hij stelt voor om te beginnen met Python en Java, omdat die gemakkelijk te leren zijn. De serieuze hacker zal ook C willen leren, om Unix te hacken, en Perl voor systeembeheer en cgi-scripts. Tenslotte moet de werkelijk serieuze hacker overwegen Lisp te leren:

Lisp is de moeite waard om te leren vanwege de diepgaande verhelderende ervaring die je zult hebben als je het eindelijk begrijpt; die ervaring zal je de rest van je dagen een betere programmeur maken, zelfs als je Lisp zelf nooit veel gebruikt.

Dit is hetzelfde argument dat je vaak hoort voor het leren van Latijn. Het zal je geen baan opleveren, behalve misschien als hoogleraar klassieke talen, maar het zal je geest verbeteren en je een betere schrijver maken in talen die je wel wilt gebruiken, zoals Nederlands.

Maar wacht eens even. Deze metafoor reikt niet zo ver. De reden dat Latijn je geen baan zal opleveren, is dat niemand het spreekt. Als je in het Latijn schrijft, kan niemand je begrijpen. Maar Lisp is een computertaal, en computers spreken elke taal die jij, de programmeur, hen vertelt te spreken.

Dus als Lisp je een betere programmeur maakt, zoals hij zegt, waarom zou je het dan niet willen gebruiken? Als een schilder een penseel werd aangeboden dat hem een betere schilder zou maken, zou hij het dan niet in al zijn schilderijen willen gebruiken? Ik probeer Eric Raymond hier niet belachelijk te maken. Over het algemeen is zijn advies goed. Wat hij over Lisp zegt, is grotendeels de conventionele wijsheid. Maar er zit een tegenstrijdigheid in de conventionele wijsheid: Lisp zal je een betere programmeur maken, en toch zul je het niet gebruiken.

Waarom niet? Programmeertalen zijn tenslotte slechts gereedschappen. Als Lisp echt betere programma's oplevert, moet je het gebruiken. En als dat niet zo is, wie heeft het dan nodig?

Dit is niet zomaar een theoretische vraag. Software is een zeer competitieve business, gevoelig voor natuurlijke monopolies. Een bedrijf dat software sneller en beter schrijft, zal, alle andere dingen gelijk blijvend, zijn concurrenten uit de markt drukken. En als je een startup begint, voel je dit heel sterk. Startups zijn vaak een alles-of-niets-situatie. Je wordt rijk, of je krijgt niets. In een startup, als je op de verkeerde technologie gokt, zullen je concurrenten je verpletteren.

Robert en ik kenden Lisp allebei goed, en we konden geen reden bedenken om onze instincten niet te vertrouwen en voor Lisp te gaan. We wisten dat iedereen zijn software in C++ of Perl schreef. Maar we wisten ook dat dat niets betekende. Als je technologie zo koos, zou je Windows draaien. Als je technologie kiest, moet je negeren wat andere mensen doen, en alleen overwegen wat het beste werkt.

Dit geldt vooral in een startup. In een groot bedrijf kun je doen wat alle andere grote bedrijven doen. Maar een startup kan niet doen wat alle andere startups doen. Ik denk niet dat veel mensen dit beseffen, zelfs niet in startups.

Het gemiddelde grote bedrijf groeit met ongeveer tien procent per jaar. Dus als je een groot bedrijf runt en je doet alles zoals het gemiddelde grote bedrijf het doet, kun je verwachten het net zo goed te doen als het gemiddelde grote bedrijf – dat wil zeggen, ongeveer tien procent per jaar groeien.

Hetzelfde zal gebeuren als je een startup runt, natuurlijk. Als je alles doet zoals de gemiddelde startup het doet, moet je gemiddelde prestaties verwachten. Het probleem hier is dat gemiddelde prestaties betekenen dat je failliet gaat. Het overlevingspercentage voor startups is veel minder dan vijftig procent. Dus als je een startup runt, kun je maar beter iets vreemds doen. Zo niet, dan heb je problemen.

In 1995 wisten we iets dat onze concurrenten naar mijn mening niet begrepen, en weinigen zelfs nu nog begrijpen: als je software schrijft die alleen op je eigen servers hoeft te draaien, kun je elke taal gebruiken die je wilt. Als je desktopsoftware schrijft, is er een sterke neiging om applicaties te schrijven in dezelfde taal als het besturingssysteem. Tien jaar geleden betekende het schrijven van applicaties het schrijven van applicaties in C. Maar met webgebaseerde software, vooral als je de broncode van zowel de taal als het besturingssysteem hebt, kun je elke taal gebruiken die je wilt.

Deze nieuwe vrijheid is echter een tweesnijdend zwaard. Nu je elke taal kunt gebruiken, moet je nadenken over welke je wilt gebruiken. Bedrijven die doen alsof er niets is veranderd, riskeren dat hun concurrenten dat niet doen.

Als je elke taal kunt gebruiken, welke gebruik je dan? Wij kozen Lisp. Ten eerste was het duidelijk dat snelle ontwikkeling belangrijk zou zijn in deze markt. We begonnen allemaal opnieuw, dus een bedrijf dat nieuwe functies sneller kon afronden dan zijn concurrenten, zou een groot voordeel hebben. We wisten dat Lisp een echt goede taal was om snel software te schrijven, en servergebaseerde applicaties vergroten het effect van snelle ontwikkeling, omdat je software kunt uitbrengen op het moment dat deze klaar is.

Als andere bedrijven Lisp niet wilden gebruiken, des te beter. Het zou ons een technologisch voordeel kunnen geven, en we hadden alle hulp nodig die we konden krijgen. Toen we Viaweb begonnen, hadden we geen ervaring in het bedrijfsleven. We wisten niets van marketing, of het aannemen van mensen, of het werven van geld, of het krijgen van klanten. Geen van ons had ooit gehad wat je een echte baan zou noemen. Het enige waar we goed in waren, was het schrijven van software. We hoopten dat dat ons zou redden. Elk voordeel dat we konden krijgen op het gebied van software, zouden we nemen.

Je zou dus kunnen zeggen dat het gebruik van Lisp een experiment was. Onze hypothese was dat als we onze software in Lisp zouden schrijven, we functies sneller zouden kunnen afronden dan onze concurrenten, en ook dingen in onze software zouden kunnen doen die zij niet konden. En omdat Lisp zo high-level was, zouden we geen groot ontwikkelingsteam nodig hebben, dus onze kosten zouden lager zijn. Als dit waar was, konden we een beter product aanbieden voor minder geld, en toch winst maken. We zouden uiteindelijk alle gebruikers krijgen, en onze concurrenten zouden geen krijgen en uiteindelijk failliet gaan. Dat was tenminste wat we hoopten.

Wat waren de resultaten van dit experiment? Verrassend genoeg werkte het. We hadden uiteindelijk veel concurrenten, in de orde van twintig tot dertig, maar geen van hun software kon concurreren met de onze. We hadden een wysiwyg online winkelbouwer die op de server draaide en toch aanvoelde als een desktopapplicatie. Onze concurrenten hadden cgi-scripts. En we waren ze altijd ver vooruit in functies. Soms, uit wanhoop, probeerden concurrenten functies te introduceren die wij niet hadden. Maar met Lisp was onze ontwikkelingscyclus zo snel dat we soms een nieuwe functie konden dupliceren binnen een dag of twee nadat een concurrent deze in een persbericht had aangekondigd. Tegen de tijd dat journalisten die het persbericht versloegen ons belden, hadden we de nieuwe functie ook.

Het moet onze concurrenten hebben geleken alsof we een soort geheim wapen hadden – dat we hun Enigma-verkeer aan het ontcijferen waren of zoiets. In feite hadden we een geheim wapen, maar het was eenvoudiger dan ze beseften. Niemand lekte nieuws over hun functies naar ons. We konden gewoon software sneller ontwikkelen dan iedereen dacht dat mogelijk was.

Toen ik ongeveer negen was, kreeg ik toevallig een exemplaar van The Day of the Jackal van Frederick Forsyth in handen. Het hoofdpersonage is een huurmoordenaar die is ingehuurd om de president van Frankrijk te vermoorden. De huurmoordenaar moet langs de politie komen om bij een appartement te komen dat uitkijkt op de route van de president. Hij loopt erlangs, gekleed als een oude man op krukken, en ze verdenken hem nooit.

Ons geheime wapen was vergelijkbaar. We schreven onze software in een vreemde AI-taal, met een bizarre syntax vol haakjes. Jarenlang had het me geïrriteerd om Lisp zo te horen beschrijven. Maar nu werkte het in ons voordeel. In het bedrijfsleven is er niets waardevoller dan een technisch voordeel dat je concurrenten niet begrijpen. In het bedrijfsleven, net als in oorlog, is verrassing net zo waardevol als kracht.

En dus, ik ben een beetje beschaamd om het te zeggen, heb ik nooit iets publiekelijk over Lisp gezegd terwijl we aan Viaweb werkten. We hebben het nooit aan de pers vermeld, en als je op onze website naar Lisp zocht, vond je alleen de titels van twee boeken in mijn biografie. Dit was geen toeval. Een startup moet zijn concurrenten zo min mogelijk informatie geven. Als ze niet wisten in welke taal onze software was geschreven, of het niet kon schelen, wilde ik dat zo houden.[2]

De mensen die onze technologie het beste begrepen, waren de klanten. Zij konden het ook niet schelen in welke taal Viaweb was geschreven, maar ze merkten wel dat het heel goed werkte. Het stelde hen in staat om letterlijk in minuten prachtige online winkels te bouwen. En dus, voornamelijk via mond-tot-mondreclame, kregen we steeds meer gebruikers. Eind 1996 hadden we ongeveer 70 winkels online. Eind 1997 hadden we er 500. Zes maanden later, toen Yahoo ons kocht, hadden we 1070 gebruikers. Vandaag de dag domineert deze software, als Yahoo Store, nog steeds zijn markt. Het is een van de winstgevendere onderdelen van Yahoo, en de winkels die ermee zijn gebouwd, vormen de basis van Yahoo Shopping. Ik verliet Yahoo in 1999, dus ik weet niet precies hoeveel gebruikers ze nu hebben, maar voor zover ik weet waren het er ongeveer 20.000.

De Blub Paradox

Wat is er zo geweldig aan Lisp? En als Lisp zo geweldig is, waarom gebruikt niet iedereen het? Dit klinkt als retorische vragen, maar eigenlijk hebben ze duidelijke antwoorden. Lisp is zo geweldig niet vanwege een of andere magische kwaliteit die alleen door aanhangers wordt gezien, maar omdat het simpelweg de krachtigste taal is die beschikbaar is. En de reden dat niet iedereen het gebruikt, is dat programmeertalen niet alleen technologieën zijn, maar ook gewoonten van denken, en niets verandert langzamer. Natuurlijk hebben beide antwoorden uitleg nodig.

Ik begin met een schokkend controversiële uitspraak: programmeertalen verschillen in kracht.

Weinig mensen zullen het er in ieder geval over oneens zijn dat high-level talen krachtiger zijn dan machinecode. De meeste programmeurs van vandaag zouden het ermee eens zijn dat je normaal gesproken niet in machinecode wilt programmeren. In plaats daarvan moet je programmeren in een high-level taal, en een compiler het voor jou laten vertalen naar machinecode. Dit idee is nu zelfs ingebouwd in de hardware: sinds de jaren 80 zijn instructiesets ontworpen voor compilers in plaats van voor menselijke programmeurs.

Iedereen weet dat het een vergissing is om je hele programma met de hand in machinecode te schrijven. Wat minder vaak wordt begrepen, is dat hier een algemener principe geldt: als je de keuze hebt uit verschillende talen, is het, alle andere dingen gelijk blijvend, een vergissing om in iets anders dan de krachtigste te programmeren.[3]

Er zijn veel uitzonderingen op deze regel. Als je een programma schrijft dat heel nauw moet samenwerken met een programma dat in een bepaalde taal is geschreven, kan het een goed idee zijn om het nieuwe programma in dezelfde taal te schrijven. Als je een programma schrijft dat slechts iets heel eenvoudigs hoeft te doen, zoals getallen kraken of bitmanipulatie, kun je net zo goed een minder abstracte taal gebruiken, vooral omdat deze misschien iets sneller is. En als je een kort, wegwerpprogramma schrijft, kun je beter gewoon de taal gebruiken die de beste bibliotheekfuncties voor de taak heeft. Maar over het algemeen wil je voor applicatiesoftware de krachtigste (redelijk efficiënte) taal gebruiken die je kunt krijgen, en iets anders gebruiken is een vergissing, van precies dezelfde soort, hoewel mogelijk in mindere mate, als programmeren in machinecode.

Je kunt zien dat machinecode erg low-level is. Maar, althans als een soort sociale conventie, worden high-level talen vaak als gelijkwaardig behandeld. Dat zijn ze niet. Technisch gezien betekent de term "high-level taal" niets heel definitiefs. Er is geen scheidingslijn met machinecodes aan de ene kant en alle high-level talen aan de andere kant. Talen vallen langs een continuüm [4] van abstractie, van de krachtigste tot machinecodes, die zelf in kracht variëren.

Beschouw Cobol. Cobol is een high-level taal, in de zin dat het wordt gecompileerd naar machinecode. Zou iemand serieus beweren dat Cobol gelijkwaardig is aan, zeg, Python? Het ligt waarschijnlijk dichter bij machinecode dan Python.

Of hoe zit het met Perl 4? Tussen Perl 4 en Perl 5 werden lexicale closures aan de taal toegevoegd. De meeste Perl-hackers zullen het ermee eens zijn dat Perl 5 krachtiger is dan Perl 4. Maar als je dat eenmaal hebt toegegeven, heb je toegegeven dat de ene high-level taal krachtiger kan zijn dan de andere. En daaruit volgt onvermijdelijk dat je, behalve in speciale gevallen, de krachtigste moet gebruiken die je kunt krijgen.

Dit idee wordt echter zelden tot zijn conclusie doorgevoerd. Na een bepaalde leeftijd wisselen programmeurs zelden vrijwillig van taal. Welke taal mensen ook gewend zijn, ze beschouwen die meestal als goed genoeg.

Programmeurs hechten zich erg aan hun favoriete talen, en ik wil niemand kwetsen, dus om dit punt uit te leggen, ga ik een hypothetische taal genaamd Blub gebruiken. Blub valt precies in het midden van het abstractiecontinuüm. Het is niet de krachtigste taal, maar het is krachtiger dan Cobol of machinecode.

En in feite zou onze hypothetische Blub-programmeur geen van beide gebruiken. Natuurlijk zou hij niet in machinecode programmeren. Daar zijn compilers voor. En wat Cobol betreft, hij weet niet hoe iemand daarmee iets gedaan krijgt. Het heeft niet eens x (Blub-functie naar keuze).

Zolang onze hypothetische Blub-programmeur langs het krachtcontinuüm naar beneden kijkt, weet hij dat hij naar beneden kijkt. Talen die minder krachtig zijn dan Blub, zijn duidelijk minder krachtig, omdat ze een functie missen die hij gewend is. Maar als onze hypothetische Blub-programmeur in de andere richting kijkt, omhoog langs het krachtcontinuüm, realiseert hij zich niet dat hij omhoog kijkt. Wat hij ziet, zijn slechts vreemde talen. Hij beschouwt ze waarschijnlijk als ongeveer gelijkwaardig aan Blub in kracht, maar met al dat andere harige spul erbij. Blub is goed genoeg voor hem, omdat hij in Blub denkt.

Wanneer we echter overschakelen naar het standpunt van een programmeur die een van de talen hoger in het krachtcontinuüm gebruikt, stellen we vast dat hij op zijn beurt neerbuigend kijkt naar Blub. Hoe kun je iets gedaan krijgen in Blub? Het heeft niet eens y.

Bij inductie zijn de enige programmeurs die in staat zijn alle verschillen in kracht tussen de verschillende talen te zien, degenen die de krachtigste begrijpen. (Dit is waarschijnlijk wat Eric Raymond bedoelde met Lisp dat je een betere programmeur maakt.) Je kunt de meningen van de anderen niet vertrouwen, vanwege de Blub-paradox: ze zijn tevreden met welke taal ze ook gebruiken, omdat die de manier dicteert waarop ze over programma's denken.

Ik weet dit uit eigen ervaring, als middelbare scholier die programma's schreef in Basic. Die taal ondersteunde niet eens recursie. Het is moeilijk voor te stellen hoe je programma's schrijft zonder recursie te gebruiken, maar ik miste het destijds niet. Ik dacht in Basic. En ik was er een kei in. Meester van alles wat ik zag.

De vijf talen die Eric Raymond aanbeveelt aan hackers bevinden zich op verschillende punten op het krachtcontinuüm. Waar ze zich ten opzichte van elkaar bevinden, is een gevoelig onderwerp. Wat ik zal zeggen is dat ik denk dat Lisp bovenaan staat. En om deze claim te ondersteunen, zal ik je vertellen over een van de dingen die ik mis als ik naar de andere vier talen kijk. Hoe kun je daar iets mee doen, denk ik, zonder macro's?[5]

Veel talen hebben iets dat een macro wordt genoemd. Maar Lisp-macro's zijn uniek. En geloof het of niet, wat ze doen, is gerelateerd aan de haakjes. De ontwerpers van Lisp hebben al die haakjes niet zomaar in de taal gezet om anders te zijn. Voor de Blub-programmeur ziet Lisp-code er vreemd uit. Maar die haakjes zijn er met een reden. Ze zijn het uiterlijke bewijs van een fundamenteel verschil tussen Lisp en andere talen.

Lisp-code is gemaakt van Lisp-dataobjecten. En niet in de triviale zin dat de bronbestanden karakters bevatten, en strings een van de gegevenstypen zijn die door de taal worden ondersteund. Lisp-code, nadat deze door de parser is gelezen, is gemaakt van datastructuren die je kunt doorlopen.

Als je begrijpt hoe compilers werken, is wat er werkelijk gebeurt niet zozeer dat Lisp een vreemde syntax heeft, maar dat Lisp geen syntax heeft. Je schrijft programma's in de parse trees die binnen de compiler worden gegenereerd wanneer andere talen worden geparsed. Maar deze parse trees zijn volledig toegankelijk voor je programma's. Je kunt programma's schrijven die ze manipuleren. In Lisp worden deze programma's macro's genoemd. Het zijn programma's die programma's schrijven.

Programma's die programma's schrijven? Wanneer zou je dat ooit willen doen? Niet erg vaak, als je in Cobol denkt. De hele tijd, als je in Lisp denkt. Het zou hier handig zijn als ik een voorbeeld van een krachtige macro kon geven, en zeggen: kijk! hoe zit het daarmee? Maar als ik dat deed, zou het er gewoon uitzien als onzin voor iemand die Lisp niet kende; er is hier niet genoeg ruimte om alles uit te leggen wat je zou moeten weten om te begrijpen wat het betekende. In Ansi Common Lisp probeerde ik dingen zo snel mogelijk te laten verlopen, en zelfs toen kwam ik pas bij macro's op pagina 160.

Maar ik denk dat ik een soort argument kan geven dat overtuigend kan zijn. De broncode van de Viaweb-editor was waarschijnlijk voor 20-25% macro's. Macro's zijn moeilijker te schrijven dan gewone Lisp-functies, en het wordt als slechte stijl beschouwd om ze te gebruiken als ze niet nodig zijn. Dus elke macro in die code is daar omdat het moet. Wat dat betekent, is dat minstens 20-25% van de code in dit programma dingen doet die je niet gemakkelijk in andere talen kunt doen. Hoe sceptisch de Blub-programmeur ook mag zijn over mijn beweringen over de mysterieuze krachten van Lisp, dit zou hem nieuwsgierig moeten maken. We schreven deze code niet voor ons eigen amusement. We waren een kleine startup, die zo hard mogelijk programmeerde om technische barrières tussen ons en onze concurrenten te creëren.

Een achterdochtig persoon zou zich kunnen afvragen of er enige correlatie was. Een groot deel van onze code deed dingen die erg moeilijk te doen zijn in andere talen. De resulterende software deed dingen die de software van onze concurrenten niet kon. Misschien was er een soort verband. Ik moedig je aan die draad te volgen. Er kan meer zijn aan die oude man die op zijn krukken strompelt dan op het eerste gezicht lijkt.

Aikido voor Startups

Maar ik verwacht niemand te overtuigen (ouder dan 25) om Lisp te gaan leren. Het doel van dit artikel is niet om iemands mening te veranderen, maar om mensen die al geïnteresseerd zijn in het gebruik van Lisp gerust te stellen – mensen die weten dat Lisp een krachtige taal is, maar zich zorgen maken omdat deze niet wijdverbreid wordt gebruikt. In een competitieve situatie is dat een voordeel. De kracht van Lisp wordt vermenigvuldigd met het feit dat je concurrenten het niet begrijpen.

Als je overweegt Lisp te gebruiken in een startup, moet je je geen zorgen maken dat het niet algemeen wordt begrepen. Je moet hopen dat het zo blijft. En dat zal waarschijnlijk ook zo blijven. Het is de aard van programmeertalen om de meeste mensen tevreden te stellen met wat ze momenteel gebruiken. Computerhardware verandert zoveel sneller dan persoonlijke gewoonten dat programmeerpraktijken meestal tien tot twintig jaar achterlopen op de processor. Op plekken als MIT schreven ze in de vroege jaren 60 programma's in high-level talen, maar veel bedrijven bleven code schrijven in machinecode tot ver in de jaren 80. Ik wed dat veel mensen machinecode bleven schrijven totdat de processor, als een barman die gretig wil sluiten en naar huis wil, hen er eindelijk uit schopte door over te schakelen op een risc-instructieset.

Normaal gesproken verandert technologie snel. Maar programmeertalen zijn anders: programmeertalen zijn niet alleen technologie, maar ook waar programmeurs in denken. Ze zijn half technologie en half religie.[6] En dus beweegt de mediane taal, wat de taal betekent die de mediane programmeur gebruikt, net zo langzaam als een ijsberg. Garbage collection, geïntroduceerd door Lisp rond 1960, wordt nu algemeen beschouwd als een goede zaak. Runtime typing, hetzelfde, wint aan populariteit. Lexicale closures, geïntroduceerd door Lisp in de vroege jaren 70, staan nu, net aan, op de radar. Macro's, geïntroduceerd door Lisp midden jaren 60, zijn nog steeds terra incognita.

Uiteraard heeft de mediane taal een enorme momentum. Ik stel niet voor dat je deze krachtige kracht kunt bestrijden. Wat ik voorstel is precies het tegenovergestelde: dat je, net als een beoefenaar van Aikido, het tegen je tegenstanders kunt gebruiken.

Als je voor een groot bedrijf werkt, is dit misschien niet gemakkelijk. Je zult het moeilijk hebben om de baas te overtuigen om je dingen in Lisp te laten bouwen, wanneer hij net in de krant heeft gelezen dat een andere taal, zoals Ada twintig jaar geleden, op het punt staat de wereld over te nemen. Maar als je voor een startup werkt die nog geen bazen heeft, kun je, zoals wij deden, de Blub-paradox in je voordeel gebruiken: je kunt technologie gebruiken die je concurrenten, onbeweeglijk vastgekleefd aan de mediane taal, nooit zullen kunnen evenaren.

Als je ooit voor een startup werkt, hier is een handige tip om concurrenten te evalueren. Lees hun vacatures. Al het andere op hun site kan stockfoto's of het proza-equivalent zijn, maar de vacatures moeten specifiek zijn over wat ze willen, anders krijgen ze de verkeerde kandidaten.

Tijdens de jaren dat we aan Viaweb werkten, las ik veel functiebeschrijvingen. Elke maand of zo leek er een nieuwe concurrent uit het niets te verschijnen. Het eerste wat ik deed, nadat ik had gecontroleerd of ze een live online demo hadden, was hun vacatures bekijken. Na een paar jaar kon ik vertellen voor welke bedrijven ik me zorgen moest maken en voor welke niet. Hoe meer IT-smaak de vacatures hadden, hoe minder gevaarlijk het bedrijf was. Het veiligst waren degenen die Oracle-ervaring wilden. Daar hoefde je je nooit zorgen over te maken. Je was ook veilig als ze zeiden dat ze C++- of Java-ontwikkelaars wilden. Als ze Perl- of Python-programmeurs wilden, zou dat een beetje beangstigend zijn – dat klinkt al als een bedrijf waar de technische kant, althans, wordt gerund door echte hackers. Als ik ooit een vacature had gezien waarin naar Lisp-hackers werd gezocht, zou ik echt bezorgd zijn geweest.

Noten

[1] Viaweb had aanvankelijk twee delen: de editor, geschreven in Lisp, die mensen gebruikten om hun sites te bouwen, en het bestelsysteem, geschreven in C, dat bestellingen afhandelde. De eerste versie was grotendeels Lisp, omdat het bestelsysteem klein was. Later voegden we nog twee modules toe, een beeldgenerator geschreven in C, en een back-office manager grotendeels geschreven in Perl.

In januari 2003 bracht Yahoo een nieuwe versie van de editor uit, geschreven in C++ en Perl. Het is echter moeilijk te zeggen of het programma niet langer in Lisp is geschreven, omdat ze om dit programma in C++ te vertalen letterlijk een Lisp-interpreter moesten schrijven: de bronbestanden van alle paginagenererende sjablonen zijn nog steeds, voor zover ik weet, Lisp-code. (Zie Greenspun's Tenth Rule.)

[2] Robert Morris zegt dat ik niet geheimzinnig hoefde te zijn, want zelfs als onze concurrenten hadden geweten dat we Lisp gebruikten, zouden ze niet hebben begrepen waarom: "Als ze zo slim waren, programmeerden ze al in Lisp."

[3] Alle talen zijn gelijkwaardig krachtig in de zin van Turing-equivalentie, maar dat is niet de betekenis van het woord waar programmeurs om geven. (Niemand wil een Turing-machine programmeren.) Het soort kracht waar programmeurs om geven, is misschien niet formeel definieerbaar, maar een manier om het uit te leggen zou zijn om te zeggen dat het verwijst naar functies die je in de minder krachtige taal alleen zou kunnen krijgen door er een interpreter voor de krachtigere taal in te schrijven. Als taal A een operator heeft voor het verwijderen van spaties uit strings en taal B niet, maakt dat A waarschijnlijk niet krachtiger, omdat je er waarschijnlijk een subroutine voor kunt schrijven in B. Maar als A bijvoorbeeld recursie ondersteunt, en B niet, is dat waarschijnlijk niet iets dat je kunt oplossen door bibliotheekfuncties te schrijven.

[4] Opmerking voor nerds: of mogelijk een rooster, dat naar boven toe versmalt; het is niet de vorm die hier telt, maar het idee dat er ten minste een partiële orde is.

[5] Het is een beetje misleidend om macro's als een aparte functie te behandelen. In de praktijk wordt hun bruikbaarheid sterk vergroot door andere Lisp-functies zoals lexicale closures en rest parameters.

[6] Als gevolg hiervan nemen vergelijkingen van programmeertalen de vorm aan van religieuze oorlogen of scriptieboeken voor beginners die zo vastberaden neutraal zijn dat ze eigenlijk antropologische werken zijn. Mensen die hun rust waarderen, of een vaste aanstelling willen, vermijden het onderwerp. Maar de vraag is slechts half religieus; er is iets dat de moeite waard is om te bestuderen, vooral als je nieuwe talen wilt ontwerpen.