Die Durchschnittswerte schlagen

Möchten Sie ein Startup gründen? Lassen Sie sich von Y Combinator finanzieren.

---

April 2001, überarbeitet April 2003

(Dieser Artikel basiert auf einem Vortrag, der auf dem Franz Developer Symposium 2001 gehalten wurde.)

Im Sommer 1995 gründeten mein Freund Robert Morris und ich ein Startup namens Viaweb. Unser Plan war es, Software zu schreiben, mit der Endbenutzer Online-Shops erstellen konnten. Das Neue an dieser Software war damals, dass sie auf unserem Server lief und gewöhnliche Webseiten als Schnittstelle nutzte.

Viele Leute hätten diese Idee natürlich zur gleichen Zeit haben können, aber soweit ich weiß, war Viaweb die erste webbasierte Anwendung. Sie erschien uns als so neuartige Idee, dass wir das Unternehmen danach benannten: Viaweb, weil unsere Software über das Web funktionierte, anstatt auf Ihrem Desktop-Computer zu laufen.

Eine weitere Besonderheit dieser Software war, dass sie hauptsächlich in einer Programmiersprache namens Lisp geschrieben wurde. Es war eine der ersten großen Endbenutzeranwendungen, die in Lisp geschrieben wurde, das bis dahin hauptsächlich in Universitäten und Forschungslabors verwendet worden war.[1]

Die Geheimwaffe

Eric Raymond hat einen Aufsatz mit dem Titel „How to Become a Hacker“ geschrieben, und darin rät er unter anderem angehenden Hackern, welche Sprachen sie lernen sollten. Er schlägt vor, mit Python und Java zu beginnen, da sie leicht zu erlernen sind. Der ernsthafte Hacker wird auch C lernen wollen, um Unix zu hacken, und Perl für die Systemadministration und CGI-Skripte. Schließlich sollte der wirklich ernsthafte Hacker in Erwägung ziehen, Lisp zu lernen:

Lisp ist es wert, gelernt zu werden, wegen der tiefgreifenden Erleuchtungserfahrung, die Sie haben werden, wenn Sie es endlich verstehen; diese Erfahrung wird Sie für den Rest Ihres Lebens zu einem besseren Programmierer machen, selbst wenn Sie Lisp selbst nie viel nutzen.

Das ist das gleiche Argument, das man oft für das Erlernen von Latein hört. Es wird Ihnen keinen Job verschaffen, außer vielleicht als Professor für Klassische Philologie, aber es wird Ihren Geist verbessern und Sie zu einem besseren Schreiber in Sprachen machen, die Sie tatsächlich nutzen möchten, wie Englisch.

Aber Moment mal. Diese Metapher reicht nicht so weit. Der Grund, warum Latein Ihnen keinen Job verschafft, ist, dass es niemand spricht. Wenn Sie auf Latein schreiben, kann Sie niemand verstehen. Aber Lisp ist eine Computersprache, und Computer sprechen jede Sprache, die Sie, der Programmierer, ihnen befehlen.

Wenn Lisp Sie also zu einem besseren Programmierer macht, wie er sagt, warum sollten Sie es nicht benutzen? Wenn einem Maler eine Bürste angeboten würde, die ihn zu einem besseren Maler macht, würde er sie meiner Meinung nach bei all seinen Gemälden verwenden, oder? Ich versuche hier nicht, Eric Raymond auf die Schippe zu nehmen. Im Großen und Ganzen sind seine Ratschläge gut. Was er über Lisp sagt, ist ziemlich genau die konventionelle Weisheit. Aber es gibt einen Widerspruch in der konventionellen Weisheit: Lisp wird Sie zu einem besseren Programmierer machen, und doch werden Sie es nicht benutzen.

Warum nicht? Programmiersprachen sind schließlich nur Werkzeuge. Wenn Lisp wirklich bessere Programme liefert, sollten Sie es verwenden. Und wenn nicht, wer braucht es dann?

Das ist keine rein theoretische Frage. Software ist ein sehr wettbewerbsintensives Geschäft, das zu natürlichen Monopolen neigt. Ein Unternehmen, das Software schneller und besser schreibt, wird, wenn alle anderen Dinge gleich sind, seine Konkurrenten aus dem Geschäft drängen. Und wenn Sie ein Startup gründen, spüren Sie das sehr deutlich. Startups sind oft eine Alles-oder-Nichts-Angelegenheit. Entweder werden Sie reich oder Sie bekommen nichts. In einem Startup, wenn Sie auf die falsche Technologie setzen, werden Ihre Konkurrenten Sie zerquetschen.

Robert und ich kannten beide Lisp gut und sahen keinen Grund, unseren Instinkten nicht zu trauen und auf Lisp zu setzen. Wir wussten, dass alle anderen ihre Software in C++ oder Perl schrieben. Aber wir wussten auch, dass das nichts bedeutete. Wenn man Technologie auf diese Weise wählt, würde man Windows verwenden. Bei der Wahl der Technologie muss man ignorieren, was andere Leute tun, und nur berücksichtigen, was am besten funktioniert.

Das gilt besonders für ein Startup. In einem großen Unternehmen kann man tun, was alle anderen großen Unternehmen tun. Aber ein Startup kann nicht tun, was alle anderen Startups tun. Ich glaube nicht, dass viele Leute das erkennen, selbst in Startups.

Das durchschnittliche große Unternehmen wächst etwa zehn Prozent pro Jahr. Wenn Sie also ein großes Unternehmen leiten und alles so machen, wie es das durchschnittliche große Unternehmen tut, können Sie erwarten, genauso gut abzuschneiden wie das durchschnittliche große Unternehmen – das heißt, etwa zehn Prozent pro Jahr zu wachsen.

Das Gleiche wird natürlich auch passieren, wenn Sie ein Startup leiten. Wenn Sie alles so machen, wie es das durchschnittliche Startup tut, sollten Sie durchschnittliche Leistung erwarten. Das Problem hierbei ist, dass durchschnittliche Leistung bedeutet, dass Sie aus dem Geschäft ausscheiden werden. Die Überlebensrate für Startups liegt weit unter fünfzig Prozent. Wenn Sie also ein Startup leiten, sollten Sie besser etwas Ungewöhnliches tun. Wenn nicht, sind Sie in Schwierigkeiten.

Schon 1995 wussten wir etwas, das unsere Konkurrenten meiner Meinung nach nicht verstanden und das auch heute noch nur wenige verstehen: Wenn man Software schreibt, die nur auf den eigenen Servern laufen muss, kann man jede beliebige Sprache verwenden. Wenn man Desktop-Software schreibt, gibt es eine starke Tendenz, Anwendungen in der gleichen Sprache wie das Betriebssystem zu schreiben. Vor zehn Jahren bedeutete das Schreiben von Anwendungen, Anwendungen in C zu schreiben. Aber bei webbasierter Software, insbesondere wenn man den Quellcode sowohl der Sprache als auch des Betriebssystems hat, kann man jede beliebige Sprache verwenden.

Diese neue Freiheit ist jedoch ein zweischneidiges Schwert. Da man nun jede Sprache verwenden kann, muss man überlegen, welche man wählt. Unternehmen, die so tun, als ob sich nichts geändert hätte, riskieren, dass ihre Konkurrenten dies nicht tun.

Wenn man jede Sprache verwenden kann, welche wählt man dann? Wir wählten Lisp. Zum einen war es offensichtlich, dass schnelle Entwicklung in diesem Markt wichtig sein würde. Wir fingen alle bei Null an, daher hätte ein Unternehmen, das neue Funktionen schneller als seine Konkurrenten fertigstellen konnte, einen großen Vorteil. Wir wussten, dass Lisp eine wirklich gute Sprache für schnelles Schreiben von Software ist, und serverbasierte Anwendungen verstärken den Effekt der schnellen Entwicklung, da man Software in dem Moment veröffentlichen kann, in dem sie fertig ist.

Wenn andere Unternehmen Lisp nicht nutzen wollten, umso besser. Es könnte uns einen technologischen Vorteil verschaffen, und wir brauchten jede Hilfe, die wir bekommen konnten. Als wir Viaweb starteten, hatten wir keine Erfahrung im Geschäftsleben. Wir wussten nichts über Marketing, Leute einstellen, Geld beschaffen oder Kunden gewinnen. Keiner von uns hatte jemals etwas gehabt, das man als richtigen Job bezeichnen würde. Das Einzige, worin wir gut waren, war das Schreiben von Software. Wir hofften, dass uns das retten würde. Jeden Vorteil, den wir in der Softwareabteilung bekommen konnten, würden wir nutzen.

Man könnte also sagen, dass die Verwendung von Lisp ein Experiment war. Unsere Hypothese war, dass wir, wenn wir unsere Software in Lisp schreiben würden, Features schneller als unsere Konkurrenten fertigstellen und auch Dinge in unserer Software tun könnten, die sie nicht konnten. Und da Lisp so hochrangig war, bräuchten wir kein großes Entwicklungsteam, sodass unsere Kosten niedriger wären. Wenn dies zuträfe, könnten wir ein besseres Produkt für weniger Geld anbieten und trotzdem einen Gewinn erzielen. Wir würden am Ende alle Benutzer gewinnen und unsere Konkurrenten würden keine gewinnen und schließlich aus dem Geschäft ausscheiden. Das war es, was wir uns erhofften.

Was waren die Ergebnisse dieses Experiments? Überraschenderweise hat es funktioniert. Wir hatten schließlich viele Konkurrenten, etwa zwanzig bis dreißig an der Zahl, aber keine ihrer Softwares konnte mit unserer mithalten. Wir hatten einen WYSIWYG-Online-Shop-Builder, der auf dem Server lief und sich dennoch wie eine Desktop-Anwendung anfühlte. Unsere Konkurrenten hatten CGI-Skripte. Und wir waren ihnen bei den Funktionen immer weit voraus. Manchmal versuchten Konkurrenten in ihrer Verzweiflung, Funktionen einzuführen, die wir nicht hatten. Aber mit Lisp war unser Entwicklungszyklus so schnell, dass wir manchmal eine neue Funktion innerhalb eines Tages oder zweier Tage, nachdem ein Konkurrent sie in einer Pressemitteilung angekündigt hatte, duplizieren konnten. Bis die Journalisten, die über die Pressemitteilung berichteten, Zeit hatten, uns anzurufen, hatten wir die neue Funktion auch.

Für unsere Konkurrenten muss es so ausgesehen haben, als hätten wir eine Art Geheimwaffe – als würden wir ihren Enigma-Verkehr entschlüsseln oder so etwas. Tatsächlich hatten wir eine Geheimwaffe, aber sie war einfacher, als sie dachten. Niemand hat uns Neuigkeiten über ihre Funktionen zugespielt. Wir konnten Software einfach schneller entwickeln, als irgendjemand für möglich gehalten hätte.

Als ich etwa neun Jahre alt war, geriet ich zufällig in den Besitz einer Ausgabe von The Day of the Jackal von Frederick Forsyth. Die Hauptfigur ist ein Attentäter, der angeheuert wird, den Präsidenten von Frankreich zu töten. Der Attentäter muss an der Polizei vorbeikommen, um zu einer Wohnung zu gelangen, die den Weg des Präsidenten überblickt. Er geht direkt an ihnen vorbei, als alter Mann auf Krücken verkleidet, und sie ahnen nichts.

Unsere Geheimwaffe war ähnlich. Wir schrieben unsere Software in einer seltsamen KI-Sprache mit einer bizarren Syntax voller Klammern. Jahrelang ärgerte es mich, Lisp so beschrieben zu hören. Aber jetzt diente es unserem Vorteil. Im Geschäftsleben gibt es nichts Wertvolleres als einen technischen Vorteil, den Ihre Konkurrenten nicht verstehen. Im Geschäftsleben ist Überraschung, wie im Krieg, genauso viel wert wie Kraft.

Und so, ich bin ein wenig beschämt, das zu sagen, habe ich während unserer Arbeit an Viaweb nie öffentlich etwas über Lisp gesagt. Wir haben es der Presse nie erwähnt, und wenn Sie auf unserer Website nach Lisp gesucht hätten, hätten Sie nur die Titel von zwei Büchern in meiner Biografie gefunden. Das war kein Zufall. Ein Startup sollte seinen Konkurrenten so wenig Informationen wie möglich geben. Wenn sie nicht wüssten, in welcher Sprache unsere Software geschrieben war, oder sich nicht darum kümmerten, wollte ich das so beibehalten.[2]

Die Leute, die unsere Technologie am besten verstanden, waren die Kunden. Ihnen war es auch egal, in welcher Sprache Viaweb geschrieben war, aber sie bemerkten, dass es wirklich gut funktionierte. Es ermöglichte ihnen, in buchstäblich Minuten großartig aussehende Online-Shops zu erstellen. Und so bekamen wir, meist durch Mundpropaganda, immer mehr Benutzer. Ende 1996 hatten wir etwa 70 Geschäfte online. Ende 1997 hatten wir 500. Sechs Monate später, als Yahoo uns kaufte, hatten wir 1070 Benutzer. Heute, als Yahoo Store, dominiert diese Software weiterhin ihren Markt. Es ist eines der profitabelsten Teile von Yahoo, und die damit erstellten Geschäfte sind das Fundament von Yahoo Shopping. Ich habe Yahoo 1999 verlassen, daher weiß ich nicht genau, wie viele Benutzer sie jetzt haben, aber das letzte Mal, als ich hörte, waren es etwa 20.000.

Die Blub-Paradoxie

Was ist so großartig an Lisp? Und wenn Lisp so großartig ist, warum benutzt es nicht jeder? Das klingen wie rhetorische Fragen, aber tatsächlich haben sie einfache Antworten. Lisp ist so großartig nicht wegen irgendeiner magischen Eigenschaft, die nur Eingeweihte sehen, sondern weil es einfach die mächtigste verfügbare Sprache ist. Und der Grund, warum es nicht jeder benutzt, ist, dass Programmiersprachen nicht nur Technologien, sondern auch Denkweisen sind, und nichts ändert sich langsamer. Natürlich müssen beide Antworten erklärt werden.

Ich beginne mit einer schockierend kontroversen Aussage: Programmiersprachen unterscheiden sich in ihrer Leistungsfähigkeit.

Kaum jemand würde zumindest bestreiten, dass Hochsprachen mächtiger sind als Maschinensprache. Die meisten Programmierer würden heute zustimmen, dass man normalerweise nicht in Maschinensprache programmieren möchte. Stattdessen sollte man in einer Hochsprache programmieren und einen Compiler damit beauftragen, sie in Maschinensprache zu übersetzen. Diese Idee ist mittlerweile sogar in der Hardware verankert: Seit den 1980er Jahren sind Befehlssätze für Compiler und nicht für menschliche Programmierer konzipiert.

Jeder weiß, dass es ein Fehler ist, sein gesamtes Programm von Hand in Maschinensprache zu schreiben. Weniger verstanden wird oft das allgemeinere Prinzip: Wenn man die Wahl zwischen mehreren Sprachen hat, ist es bei sonst gleichen Bedingungen ein Fehler, in etwas anderem als der mächtigsten zu programmieren.[3]

Es gibt viele Ausnahmen von dieser Regel. Wenn Sie ein Programm schreiben, das sehr eng mit einem Programm in einer bestimmten Sprache zusammenarbeiten muss, kann es eine gute Idee sein, das neue Programm in der gleichen Sprache zu schreiben. Wenn Sie ein Programm schreiben, das nur etwas sehr Einfaches tun muss, wie Zahlenberechnungen oder Bitmanipulation, können Sie genauso gut eine weniger abstrakte Sprache verwenden, insbesondere da sie möglicherweise etwas schneller ist. Und wenn Sie ein kurzes, wegwerfbares Programm schreiben, sind Sie möglicherweise besser dran, einfach die Sprache mit den besten Bibliotheksfunktionen für die Aufgabe zu verwenden. Aber im Allgemeinen möchten Sie für Anwendungssoftware die mächtigste (vernünftigerweise effiziente) Sprache verwenden, die Sie bekommen können, und alles andere zu verwenden ist ein Fehler, genau derselbe, wenn auch möglicherweise in geringerem Maße, wie in Maschinensprache zu programmieren.

Sie können sehen, dass Maschinensprache sehr niedrigschwellig ist. Aber zumindest als eine Art soziale Konvention werden Hochsprachen oft als gleichwertig behandelt. Das sind sie nicht. Technisch gesehen bedeutet der Begriff „Hochsprache“ nichts sehr Definiertes. Es gibt keine Trennlinie mit Maschinensprachen auf der einen Seite und allen Hochsprachen auf der anderen. Sprachen fallen entlang eines Kontinuums [4] der Abstraktheit, von der mächtigsten bis hin zu Maschinensprachen, die selbst in ihrer Macht variieren.

Betrachten Sie Cobol. Cobol ist eine Hochsprache, in dem Sinne, dass sie in Maschinensprache kompiliert wird. Würde jemand ernsthaft argumentieren, dass Cobol in seiner Leistungsfähigkeit mit, sagen wir, Python gleichwertig ist? Es ist wahrscheinlich näher an der Maschinensprache als Python.

Oder wie wäre es mit Perl 4? Zwischen Perl 4 und Perl 5 wurden lexikalische Closures zur Sprache hinzugefügt. Die meisten Perl-Hacker würden zustimmen, dass Perl 5 mächtiger ist als Perl 4. Aber wenn Sie das erst einmal zugegeben haben, haben Sie zugegeben, dass eine Hochsprache mächtiger sein kann als eine andere. Und daraus folgt unweigerlich, dass Sie, außer in Sonderfällen, die mächtigste verwenden sollten, die Sie bekommen können.

Diese Idee wird jedoch selten zu Ende gedacht. Nach einem bestimmten Alter wechseln Programmierer nur noch selten freiwillig die Sprache. Welche Sprache Leute auch immer gewohnt sind, sie halten sie meist für gut genug.

Programmierer hängen sehr an ihren Lieblingssprachen, und ich möchte niemandes Gefühle verletzen, daher werde ich zur Erklärung dieses Punktes eine hypothetische Sprache namens Blub verwenden. Blub liegt genau in der Mitte des Abstraktheitskontinuums. Es ist nicht die mächtigste Sprache, aber sie ist mächtiger als Cobol oder Maschinensprache.

Und tatsächlich würde unser hypothetischer Blub-Programmierer keine von beiden verwenden. Natürlich würde er nicht in Maschinensprache programmieren. Dafür sind Compiler da. Und was Cobol angeht, er weiß nicht, wie irgendjemand damit etwas erledigen kann. Es hat nicht einmal x (Blub-Funktion Ihrer Wahl).

Solange unser hypothetischer Blub-Programmierer das Machtkontinuum hinunterblickt, weiß er, dass er hinunterblickt. Sprachen, die weniger mächtig als Blub sind, sind offensichtlich weniger mächtig, da ihnen eine Funktion fehlt, an die er gewöhnt ist. Aber wenn unser hypothetischer Blub-Programmierer in die andere Richtung blickt, nach oben im Machtkontinuum, erkennt er nicht, dass er nach oben blickt. Was er sieht, sind lediglich seltsame Sprachen. Er betrachtet sie wahrscheinlich als ungefähr gleichwertig in der Macht wie Blub, aber mit all dem anderen haarigen Zeug, das zusätzlich hineingeworfen wurde. Blub ist für ihn gut genug, weil er in Blub denkt.

Wenn wir jedoch zur Perspektive eines Programmierers wechseln, der eine der Sprachen weiter oben im Machtkontinuum verwendet, stellen wir fest, dass dieser wiederum auf Blub herabblickt. Wie kann man in Blub etwas erledigen? Es hat nicht einmal y.

Per Induktion sind die einzigen Programmierer, die in der Lage sind, alle Leistungsunterschiede zwischen den verschiedenen Sprachen zu erkennen, diejenigen, die die mächtigste verstehen. (Das ist wahrscheinlich, was Eric Raymond meinte, als er sagte, Lisp mache einen zu einem besseren Programmierer.) Man kann den Meinungen der anderen nicht trauen, wegen der Blub-Paradoxie: Sie sind mit jeder Sprache zufrieden, die sie zufällig verwenden, weil diese die Art und Weise diktiert, wie sie über Programme denken.

Ich weiß das aus eigener Erfahrung, als Teenager, der Programme in Basic schrieb. Diese Sprache unterstützte nicht einmal Rekursion. Es ist schwer vorstellbar, Programme ohne Rekursion zu schreiben, aber ich habe es damals nicht vermisst. Ich dachte in Basic. Und ich war ein Genie darin. Herrscher über alles, was ich überblickte.

Die fünf Sprachen, die Eric Raymond Hackern empfiehlt, liegen an verschiedenen Punkten des Machtkontinuums. Wo sie relativ zueinander liegen, ist ein heikles Thema. Was ich sagen werde, ist, dass ich Lisp für das Beste halte. Und um diese Behauptung zu untermauern, werde ich Ihnen eines der Dinge erzählen, die ich vermisse, wenn ich die anderen vier Sprachen betrachte. Wie kann man in ihnen etwas erledigen, denke ich, ohne Makros?[5]

Viele Sprachen haben etwas namens Makro. Aber Lisp-Makros sind einzigartig. Und ob Sie es glauben oder nicht, was sie tun, hängt mit den Klammern zusammen. Die Designer von Lisp haben diese ganzen Klammern nicht nur eingebaut, um anders zu sein. Für den Blub-Programmierer sieht Lisp-Code seltsam aus. Aber diese Klammern sind aus einem Grund da. Sie sind der äußere Beweis für einen grundlegenden Unterschied zwischen Lisp und anderen Sprachen.

Lisp-Code besteht aus Lisp-Datenobjekten. Und zwar nicht in dem trivialen Sinne, dass die Quelldateien Zeichen enthalten und Strings einer der von der Sprache unterstützten Datentypen sind. Lisp-Code besteht nach dem Einlesen durch den Parser aus Datenstrukturen, die Sie durchlaufen können.

Wenn Sie verstehen, wie Compiler funktionieren, dann ist das, was wirklich vor sich geht, nicht so sehr, dass Lisp eine seltsame Syntax hat, sondern dass Lisp keine Syntax hat. Sie schreiben Programme in den Parse-Trees, die innerhalb des Compilers generiert werden, wenn andere Sprachen geparvert werden. Aber diese Parse-Trees sind für Ihre Programme vollständig zugänglich. Sie können Programme schreiben, die sie manipulieren. In Lisp werden diese Programme Makros genannt. Sie sind Programme, die Programme schreiben.

Programme, die Programme schreiben? Wann würden Sie das jemals tun wollen? Nicht sehr oft, wenn Sie in Cobol denken. Die ganze Zeit, wenn Sie in Lisp denken. Es wäre hier praktisch, wenn ich ein Beispiel für ein mächtiges Makro geben und sagen könnte: Da! Was halten Sie davon? Aber wenn ich es täte, würde es für jemanden, der Lisp nicht kennt, nur wie Kauderwelsch aussehen; hier ist nicht genug Platz, um alles zu erklären, was Sie wissen müssten, um zu verstehen, was es bedeutet. In Ansi Common Lisp habe ich versucht, die Dinge so schnell wie möglich voranzutreiben, und selbst dann kam ich erst auf Seite 160 zu Makros.

Aber ich glaube, ich kann eine Art Argument liefern, das überzeugend sein könnte. Der Quellcode des Viaweb-Editors bestand wahrscheinlich zu 20-25 % aus Makros. Makros sind schwieriger zu schreiben als normale Lisp-Funktionen, und es gilt als schlechter Stil, sie zu verwenden, wenn sie nicht notwendig sind. Jedes Makro in diesem Code ist also vorhanden, weil es sein muss. Das bedeutet, dass mindestens 20-25 % des Codes in diesem Programm Dinge tun, die man in anderen Sprachen nicht einfach tun kann. Wie skeptisch der Blub-Programmierer auch über meine Behauptungen zu den mysteriösen Kräften von Lisp sein mag, dies sollte ihn neugierig machen. Wir schrieben diesen Code nicht zu unserer eigenen Belustigung. Wir waren ein winziges Startup, das so hart wie möglich programmierte, um technische Barrieren zwischen uns und unseren Konkurrenten zu errichten.

Eine misstrauische Person könnte sich fragen, ob es hier eine Korrelation gibt. Ein großer Teil unseres Codes tat Dinge, die in anderen Sprachen sehr schwer zu tun sind. Die daraus resultierende Software tat Dinge, die die Software unserer Konkurrenten nicht konnte. Vielleicht gab es eine Art Verbindung. Ich ermutige Sie, diesem Faden zu folgen. Es könnte mehr hinter diesem alten Mann stecken, der auf seinen Krücken humpelt, als man auf den ersten Blick sieht.

Aikido für Startups

Aber ich erwarte nicht, jemanden (über 25) zu überzeugen, Lisp zu lernen. Der Zweck dieses Artikels ist nicht, jemandes Meinung zu ändern, sondern Leute zu beruhigen, die bereits daran interessiert sind, Lisp zu verwenden – Leute, die wissen, dass Lisp eine mächtige Sprache ist, sich aber Sorgen machen, weil sie nicht weit verbreitet ist. In einer Wettbewerbssituation ist das ein Vorteil. Die Macht von Lisp wird dadurch vervielfacht, dass Ihre Konkurrenten sie nicht verstehen.

Wenn Sie die Verwendung von Lisp in einem Startup in Erwägung ziehen, sollten Sie sich keine Sorgen machen, dass es nicht allgemein verstanden wird. Sie sollten hoffen, dass es so bleibt. Und das wird es wahrscheinlich auch. Es liegt in der Natur von Programmiersprachen, die meisten Menschen mit dem zufrieden zu stellen, was sie gerade verwenden. Die Computerhardware ändert sich so viel schneller als persönliche Gewohnheiten, dass die Programmierpraxis normalerweise zehn bis zwanzig Jahre hinter dem Prozessor zurückbleibt. An Orten wie dem MIT schrieben sie in den frühen 1960er Jahren Programme in Hochsprachen, aber viele Unternehmen schrieben bis in die 1980er Jahre hinein Code in Maschinensprache. Ich wette, viele Leute schrieben weiterhin Maschinensprache, bis der Prozessor, wie ein Barkeeper, der schließen und nach Hause gehen möchte, sie schließlich durch den Wechsel zu einem RISC-Befehlssatz hinauswarf.

Normalerweise ändert sich die Technologie schnell. Aber Programmiersprachen sind anders: Programmiersprachen sind nicht nur Technologie, sondern auch das, worin Programmierer denken. Sie sind halb Technologie und halb Religion.[6] Und so bewegt sich die Median-Sprache, also die Sprache, die der Median-Programmierer verwendet, so langsam wie ein Eisberg. Garbage Collection, das Lisp um 1960 eingeführt hat, gilt heute weithin als gute Sache. Laufzeit-Typisierung, ebenfalls, gewinnt an Popularität. Lexikalische Closures, die Lisp in den frühen 1970er Jahren eingeführt hat, sind jetzt, gerade noch, auf dem Radar. Makros, die Lisp Mitte der 1960er Jahre eingeführt hat, sind immer noch Terra Incognita.

Offensichtlich hat die Median-Sprache eine enorme Trägheit. Ich schlage nicht vor, dass Sie diese mächtige Kraft bekämpfen können. Was ich vorschlage, ist genau das Gegenteil: dass Sie sie, wie ein Aikido-Praktizierender, gegen Ihre Gegner einsetzen können.

Wenn Sie für ein großes Unternehmen arbeiten, ist das vielleicht nicht einfach. Sie werden es schwer haben, den „pointy-haired boss“ davon zu überzeugen, Sie Dinge in Lisp bauen zu lassen, wenn er gerade in der Zeitung gelesen hat, dass eine andere Sprache, wie Ada vor zwanzig Jahren, im Begriff ist, die Welt zu erobern. Aber wenn Sie für ein Startup arbeiten, das noch keine „pointy-haired bosses“ hat, können Sie, wie wir es getan haben, die Blub-Paradoxie zu Ihrem Vorteil nutzen: Sie können Technologie einsetzen, die Ihre Konkurrenten, die unbeweglich an der Median-Sprache kleben, niemals erreichen werden.

Wenn Sie jemals für ein Startup arbeiten, hier ein nützlicher Tipp zur Bewertung von Konkurrenten. Lesen Sie deren Stellenanzeigen. Alles andere auf ihrer Website mag Stockfotos oder das entsprechende Prosa-Äquivalent sein, aber die Stellenanzeigen müssen spezifisch sein, was sie wollen, sonst bekommen sie die falschen Kandidaten.

Während der Jahre, in denen wir an Viaweb arbeiteten, las ich viele Stellenbeschreibungen. Alle paar Monate schien ein neuer Konkurrent aus dem Boden zu sprießen. Das Erste, was ich tat, nachdem ich geprüft hatte, ob sie eine Live-Online-Demo hatten, war, ihre Stellenanzeigen zu lesen. Nach ein paar Jahren konnte ich einschätzen, welche Unternehmen Anlass zur Sorge gaben und welche nicht. Je mehr IT-Geschmack die Stellenanzeigen hatten, desto ungefährlicher war das Unternehmen. Die sichersten waren diejenigen, die Oracle-Erfahrung suchten. Vor denen musste man sich nie fürchten. Man war auch sicher, wenn sie sagten, dass sie C++- oder Java-Entwickler suchten. Wenn sie Perl- oder Python-Programmierer suchten, wäre das ein wenig beängstigend – das klingt schon nach einem Unternehmen, bei dem die technische Seite zumindest von echten Hackern geführt wird. Wenn ich jemals eine Stellenausschreibung gesehen hätte, die nach Lisp-Hackern sucht, wäre ich wirklich besorgt gewesen.

Anmerkungen

[1] Viaweb hatte anfangs zwei Teile: den Editor, geschrieben in Lisp, den die Leute zum Erstellen ihrer Websites verwendeten, und das Bestellsystem, geschrieben in C, das Bestellungen bearbeitete. Die erste Version war größtenteils Lisp, da das Bestellsystem klein war. Später fügten wir zwei weitere Module hinzu, einen Bildgenerator, geschrieben in C, und einen Back-Office-Manager, größtenteils in Perl geschrieben.

Im Januar 2003 veröffentlichte Yahoo eine neue Version des Editors, geschrieben in C++ und Perl. Es ist jedoch schwer zu sagen, ob das Programm nicht mehr in Lisp geschrieben ist, denn um dieses Programm in C++ zu übersetzen, mussten sie buchstäblich einen Lisp-Interpreter schreiben: Die Quelldateien aller seiten generierenden Templates sind meines Wissens immer noch Lisp-Code. (Siehe Greenspun's Tenth Rule.)

[2] Robert Morris sagt, dass ich nicht heimlich sein musste, denn selbst wenn unsere Konkurrenten gewusst hätten, dass wir Lisp benutzen, hätten sie nicht verstanden, warum: „Wenn sie so schlau wären, würden sie bereits Lisp programmieren.“

[3] Alle Sprachen sind im Sinne der Turing-Äquivalenz gleich mächtig, aber das ist nicht die Bedeutung des Wortes, die Programmierer interessiert. (Niemand möchte eine Turing-Maschine programmieren.) Die Art von Macht, die Programmierer interessiert, ist möglicherweise nicht formal definierbar, aber eine Möglichkeit, sie zu erklären, wäre zu sagen, dass sie sich auf Funktionen bezieht, die man in der weniger mächtigen Sprache nur durch das Schreiben eines Interpreters für die mächtigere Sprache darin erhalten könnte. Wenn Sprache A einen Operator zum Entfernen von Leerzeichen aus Zeichenketten hat und Sprache B nicht, macht das A wahrscheinlich nicht mächtiger, da man wahrscheinlich eine Unterroutine schreiben kann, um dies in B zu tun. Aber wenn A beispielsweise Rekursion unterstützt und B nicht, ist das wahrscheinlich nichts, was man durch das Schreiben von Bibliotheksfunktionen beheben kann.

[4] Hinweis für Nerds: oder möglicherweise ein Verband, der sich nach oben verjüngt; es ist nicht die Form, die hier zählt, sondern die Idee, dass es mindestens eine partielle Ordnung gibt.

[5] Es ist etwas irreführend, Makros als separates Merkmal zu behandeln. In der Praxis wird ihre Nützlichkeit durch andere Lisp-Merkmale wie lexikalische Closures und Rest-Parameter erheblich verbessert.

[6] Infolgedessen nehmen Vergleiche von Programmiersprachen entweder die Form von Religionskriegen oder von Studienbuchkapiteln an, die so entschlossen neutral sind, dass sie eigentlich anthropologische Werke sind. Leute, die ihren Frieden schätzen oder eine Professur wollen, meiden das Thema. Aber die Frage ist nur halb religiös; es gibt etwas zu untersuchen, besonders wenn man neue Sprachen entwerfen möchte.