DIE DURCHSCHNITTSWERTE SCHLAGEN

April 2001, rev. 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 Besondere an dieser Software war damals, dass sie auf unserem Server lief und normale Webseiten als Schnittstelle verwendete.

Natürlich hätten viele Leute gleichzeitig auf diese Idee kommen können, aber meines Wissens war Viaweb die erste Web-basierte Anwendung. Es schien uns eine so neuartige Idee zu sein, dass wir das Unternehmen danach benannten: Viaweb, weil unsere Software über das Web funktionierte, anstatt auf Ihrem Desktop-Computer zu laufen.

Etwas Ungewöhnliches war auch, dass die Software 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 Forschungslaboren eingesetzt wurde. [1]

Die Geheimwaffe

Eric Raymond hat einen Essay mit dem Titel "Wie man ein Hacker wird" geschrieben, und darin erzählt er angehenden Hackern unter anderem, welche Sprachen sie lernen sollten. Er schlägt vor, mit Python und Java zu beginnen, da sie einfach zu lernen sind. Der ernsthafte Hacker wird auch C lernen wollen, um Unix zu hacken, und Perl für die Systemverwaltung und CGI-Skripte. Schließlich sollte der wirklich ernsthafte Hacker in Betracht ziehen, Lisp zu lernen:

Lisp ist es wert, gelernt zu werden, wegen der tiefgreifenden Erleuchtungserfahrung, die Sie haben werden, wenn Sie es endlich verstanden haben; diese Erfahrung wird Sie zum besseren Programmierer machen für den Rest Ihrer Tage, selbst wenn Sie Lisp selbst nie wirklich viel verwenden.

Das ist das gleiche Argument, das man für das Lernen von Latein hört. Es bringt Ihnen keinen Job, außer vielleicht als Professor für Klassische Sprachen, aber es wird Ihren Geist schärfen und Sie zu einem besseren Schreiber in Sprachen machen, die Sie verwenden möchten, wie zum Beispiel Englisch.

Aber Moment mal. Diese Metapher reicht nicht so weit. Der Grund, warum Latein Ihnen keinen Job bringt, 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 vorgeben.

Wenn Lisp Sie also zu einem besseren Programmierer macht, wie er sagt, warum sollten Sie es dann nicht verwenden? Wenn einem Maler ein Pinsel angeboten würde, der ihn zu einem besseren Maler machen würde, würde er ihn wohl in allen seinen Bildern verwenden wollen, oder? Ich will hier nicht über Eric Raymond lustig machen. Im Großen und Ganzen ist sein Rat gut. Was er über Lisp sagt, ist im Wesentlichen die konventionelle Weisheit. Aber es gibt einen Widerspruch in der konventionellen Weisheit: Lisp macht Sie zu einem besseren Programmierer, und trotzdem werden Sie es nicht verwenden.

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

Dies ist nicht nur eine theoretische Frage. Software ist ein sehr wettbewerbsintensives Geschäft, das anfällig für natürliche Monopole ist. Ein Unternehmen, das Software schneller und besser schreiben kann, wird, unter sonst gleichen Bedingungen, seine Konkurrenten aus dem Geschäft drängen. Und wenn man ein Startup gründet, spürt man das sehr deutlich. Startups sind in der Regel eine Alles-oder-Nichts-Sache. Entweder man wird reich, oder man bekommt nichts. Wenn man in einem Startup auf die falsche Technologie setzt, werden die Konkurrenten einen vernichten.

Robert und ich kannten Lisp beide gut, und wir sahen keinen Grund, unseren Instinkten nicht zu vertrauen und mit Lisp zu arbeiten. Wir wussten, dass alle anderen ihre Software in C++ oder Perl schrieben. Aber wir wussten auch, dass das nichts bedeutete. Wenn man sich für Technologie auf diese Weise entscheiden würde, würde man Windows benutzen. Wenn man sich für Technologie entscheidet, muss man ignorieren, was andere Leute tun, und nur das berücksichtigen, was am besten funktioniert.

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

Das durchschnittliche große Unternehmen wächst mit etwa zehn Prozent pro Jahr. Wenn man also ein großes Unternehmen leitet und alles so macht, wie es das durchschnittliche große Unternehmen macht, kann man 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 passieren, wenn man ein Startup leitet. Wenn man alles so macht, wie es das durchschnittliche Startup macht, sollte man mit durchschnittlicher Leistung rechnen. Das Problem dabei ist, dass durchschnittliche Leistung bedeutet, dass man pleite geht. Die Überlebensrate für Startups liegt deutlich unter fünfzig Prozent. Wenn man also ein Startup leitet, sollte man besser etwas Besonderes tun. Wenn nicht, ist man in Schwierigkeiten.

Zurück im Jahr 1995 wussten wir etwas, das unsere Konkurrenten, glaube ich, nicht verstanden haben, und das auch heute noch nur wenige verstehen: Wenn man Software schreibt, die nur auf seinen eigenen Servern laufen muss, kann man jede Sprache verwenden, die man möchte. 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 mit Web-basierter Software, besonders wenn man den Quellcode sowohl der Sprache als auch des Betriebssystems hat, kann man jede Sprache verwenden, die man möchte.

Diese neue Freiheit ist jedoch ein zweischneidiges Schwert. Jetzt, wo man jede Sprache verwenden kann, muss man sich überlegen, welche man verwenden möchte. Unternehmen, die versuchen, so zu tun, als ob sich nichts geändert hätte, riskieren, dass ihre Konkurrenten das nicht tun.

Welche Sprache verwendet man, wenn man jede Sprache verwenden kann? Wir haben uns für Lisp entschieden. Zum einen war es klar, dass die schnelle Entwicklung in diesem Markt wichtig sein würde. Wir waren alle am Anfang, also ein Unternehmen, das neue Features vor seinen Konkurrenten fertigstellen konnte, hätte einen großen Vorteil. Wir wussten, dass Lisp eine wirklich gute Sprache war, um Software schnell zu schreiben, und serverbasierte Anwendungen verstärken den Effekt der schnellen Entwicklung, weil man Software in dem Moment veröffentlichen kann, wo sie fertig ist.

Wenn andere Unternehmen Lisp nicht verwenden wollten, umso besser. Es könnte uns einen technologischen Vorsprung verschaffen, und wir brauchten jede Hilfe, die wir bekommen konnten. Als wir Viaweb gründeten, hatten wir keine Erfahrung im Geschäft. Wir wussten nichts über Marketing, über das Einstellen von Mitarbeitern, über die Beschaffung von Geld oder über die Gewinnung von Kunden. Keiner von uns hatte jemals auch nur einen richtigen Job gehabt. Das Einzige, was wir gut konnten, war, Software zu schreiben. Wir hofften, dass uns das retten würde. Jeden Vorteil, den wir in der Softwareabteilung bekommen konnten, würden wir annehmen.

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, in der Lage sein würden, Features schneller zu entwickeln als unsere Konkurrenten und auch Dinge in unserer Software zu tun, die sie nicht konnten. Und weil Lisp so hochwertig war, würden wir kein großes Entwicklungsteam brauchen, so dass unsere Kosten niedriger wären. Wenn das so wäre, könnten wir ein besseres Produkt zu einem günstigeren Preis anbieten und trotzdem Gewinn machen. Wir würden am Ende alle Benutzer bekommen, und unsere Konkurrenten würden keinen bekommen und schließlich pleite gehen. Das war es, was wir uns jedenfalls erhofft hatten.

Was waren die Ergebnisse dieses Experiments? Etwas überraschend, es funktionierte. Wir hatten schließlich viele Konkurrenten, in der Größenordnung von zwanzig bis dreißig, aber keiner ihrer Software 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 in Sachen Features immer weit voraus. Manchmal versuchten die Konkurrenten in ihrer Verzweiflung, Features einzuführen, die wir nicht hatten. Aber mit Lisp war unser Entwicklungszyklus so schnell, dass wir manchmal ein neues Feature innerhalb eines oder zwei Tagen nach der Ankündigung durch einen Konkurrenten in einer Pressemitteilung duplizieren konnten. Bis die Journalisten, die über die Pressemitteilung berichteten, uns anriefen, hätten wir das neue Feature auch.

Es muss unseren Konkurrenten so vorgekommen sein, als ob wir eine Art Geheimwaffe hätten - als ob wir ihren Enigma-Verkehr entschlüsseln würden oder so. Tatsächlich hatten wir eine Geheimwaffe, aber sie war einfacher, als sie dachten. Niemand hat uns Neuigkeiten über ihre Features verraten. Wir waren einfach in der Lage, Software schneller zu entwickeln, als irgendjemand für möglich hielt.

Als ich etwa neun Jahre alt war, bekam ich zufällig eine Ausgabe von The Day of the Jackal, von Frederick Forsyth, in die Hände. Die Hauptfigur ist ein Attentäter, der beauftragt wird, den französischen Präsidenten zu töten. Der Attentäter muss an der Polizei vorbeikommen, um zu einem Appartement zu gelangen, das die Route des Präsidenten überblickt. Er geht direkt an ihnen vorbei, verkleidet als alter Mann auf Krücken, und sie verdächtigen ihn nie.

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

Und so muss ich ein wenig beschämt sagen, dass ich während unserer Arbeit an Viaweb nie öffentlich etwas über Lisp gesagt habe. Wir haben es nie der Presse erwähnt, und wenn man auf unserer Website nach Lisp suchte, fand man nur die Titel von zwei Büchern in meiner Biografie. Das war kein Zufall. Ein Startup sollte seinen Konkurrenten so wenig Informationen wie möglich geben. Wenn sie nicht wussten, in welcher Sprache unsere Software geschrieben wurde, oder sich nicht dafür interessierten, wollte ich das so beibehalten. [2]

Die Leute, die unsere Technologie am besten verstanden haben, waren die Kunden. Sie kümmerten sich auch nicht darum, in welcher Sprache Viaweb geschrieben wurde, aber sie merkten, dass es wirklich gut funktionierte. Es ermöglichte ihnen, großartige aussehende Online-Shops im wahrsten Sinne des Wortes in Minuten zu erstellen. Und so bekamen wir, vor allem durch Mundpropaganda, immer mehr Nutzer. Ende 1996 hatten wir etwa 70 Shops online. Ende 1997 waren es 500. Sechs Monate später, als Yahoo uns kaufte, hatten wir 1070 Nutzer. Heute, als Yahoo Store, dominiert diese Software weiterhin ihren Markt. Es ist eines der profitabelsten Produkte von Yahoo, und die mit ihr erstellten Shops sind das Fundament von Yahoo Shopping. Ich habe Yahoo im Jahr 1999 verlassen, daher weiß ich nicht genau, wie viele Nutzer sie jetzt haben, aber das letzte Mal, als ich hörte, waren es etwa 20.000.

Das Blub-Paradoxon

Was ist so toll an Lisp? Und wenn Lisp so toll ist, warum verwendet es dann nicht jeder? Das klingt nach rhetorischen Fragen, aber tatsächlich haben sie einfache Antworten. Lisp ist so toll nicht wegen einer magischen Eigenschaft, die nur für Anhänger sichtbar ist, sondern weil es einfach die leistungsstärkste verfügbare Sprache ist. Und der Grund, warum nicht jeder sie verwendet, ist, dass Programmiersprachen nicht nur Technologien, sondern auch Denkgewohnheiten 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.

Nur wenige würden bestreiten, zumindest, dass High-Level-Sprachen leistungsstärker sind als Maschinensprache. Die meisten Programmierer würden heute zustimmen, dass man normalerweise nicht in Maschinensprache programmieren möchte. Stattdessen sollte man in einer High-Level-Sprache programmieren und einen Compiler sie in Maschinensprache übersetzen lassen. Diese Idee ist heute sogar in die Hardware eingebaut: Seit den 1980er Jahren werden Befehlssätze für Compiler und nicht für menschliche Programmierer entworfen.

Jeder weiß, dass es ein Fehler ist, das gesamte Programm von Hand in Maschinensprache zu schreiben. Weniger verstanden wird, dass es hier ein allgemeineres Prinzip gibt: Wenn man die Wahl zwischen mehreren Sprachen hat, ist es, unter sonst gleichen Bedingungen, ein Fehler, in etwas anderem als der leistungsstärksten zu programmieren. [3]

Es gibt viele Ausnahmen von dieser Regel. Wenn man ein Programm schreibt, das sehr eng mit einem Programm zusammenarbeiten muss, das in einer bestimmten Sprache geschrieben ist, könnte es eine gute Idee sein, das neue Programm in der gleichen Sprache zu schreiben. Wenn man ein Programm schreibt, das nur etwas sehr Einfaches tun soll, wie zum Beispiel Zahlenverarbeitung oder Bitmanipulation, kann man genauso gut eine weniger abstrakte Sprache verwenden, insbesondere da sie möglicherweise etwas schneller ist. Und wenn man ein kurzes, wegwerfbares Programm schreibt, ist man möglicherweise besser dran, einfach die Sprache zu verwenden, die die besten Bibliotheksfunktionen für die Aufgabe hat. Im Allgemeinen möchte man aber für Anwendungssoftware die leistungsstärkste (vernünftig effiziente) Sprache verwenden, die man bekommen kann, und alles andere zu verwenden, ist ein Fehler, der genau der gleiche ist, wenn auch möglicherweise in einem geringeren Maße, wie das Programmieren in Maschinensprache.

Man sieht, dass Maschinensprache sehr niedrigstufig ist. Aber, zumindest als eine Art soziale Konvention, werden High-Level-Sprachen oft alle als gleichwertig behandelt. Das sind sie nicht. Technisch gesehen bedeutet der Begriff "High-Level-Sprache" nicht etwas sehr Definitives. Es gibt keine Trennlinie zwischen Maschinensprachen auf der einen Seite und allen High-Level-Sprachen auf der anderen Seite. Sprachen fallen auf ein Kontinuum [4] der Abstraktheit, von der leistungsstärksten bis hin zu Maschinensprachen, die ihrerseits in ihrer Leistungsfähigkeit variieren.

Nehmen Sie Cobol. Cobol ist eine High-Level-Sprache, in dem Sinne, dass sie in Maschinensprache kompiliert wird. Würde jemand ernsthaft behaupten, dass Cobol in seiner Leistungsfähigkeit mit, sagen wir, Python vergleichbar ist? Es ist wahrscheinlich näher an 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 leistungsfähiger ist als Perl 4. Aber sobald man das zugibt, hat man zugestanden, dass eine High-Level-Sprache leistungsfähiger sein kann als eine andere. Und daraus folgt unweigerlich, dass man, außer in besonderen Fällen, die leistungsstärkste verwenden sollte, die man bekommen kann.

Diese Idee wird jedoch selten bis zu ihrer Schlussfolgerung verfolgt. Nach einem bestimmten Alter wechseln Programmierer selten freiwillig die Sprache. Welche Sprache die Leute gerade benutzen, die halten sie in der Regel 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 leistungsstärkste Sprache, aber es ist leistungsstärker als Cobol oder Maschinensprache.

Und tatsächlich würde unser hypothetischer Blub-Programmierer keine der beiden verwenden. Natürlich würde er nicht in Maschinensprache programmieren. Dafür gibt es Compiler. Und was Cobol betrifft, so weiß er nicht, wie jemand mit dieser Sprache etwas erreichen kann. Sie hat nicht einmal x (Blub-Feature Ihrer Wahl).

Solange unser hypothetischer Blub-Programmierer den Leistungskontinuum abwärts betrachtet, weiß er, dass er nach unten blickt. Sprachen, die weniger leistungsfähig sind als Blub, sind offensichtlich weniger leistungsfähig, weil ihnen ein Feature fehlt, an das er gewöhnt ist. Aber wenn unser hypothetischer Blub-Programmierer in die andere Richtung schaut, auf das Leistungskontinuum hinauf, merkt er nicht, dass er nach oben schaut. Was er sieht, sind nur seltsame Sprachen. Wahrscheinlich hält er sie für etwa gleichwertig in ihrer Leistungsfähigkeit wie Blub, aber mit all dem anderen haarigen Zeug, das auch noch dazukommt. Blub ist gut genug für ihn, weil er in Blub denkt.

Wenn wir jedoch auf den Standpunkt eines Programmierers wechseln, der eine der Sprachen weiter oben im Leistungskontinuum verwendet, stellen wir fest, dass er wiederum auf Blub herabblickt. Wie kann man in Blub überhaupt etwas erreichen? Es hat nicht einmal y.

Induktiv gesehen sind die einzigen Programmierer, die in der Lage sind, alle Leistungsunterschiede zwischen den verschiedenen Sprachen zu erkennen, diejenigen, die die leistungsstärkste verstehen. (Das ist wahrscheinlich, was Eric Raymond mit Lisp meinte, das Sie zu einem besseren Programmierer macht.) Sie können den Meinungen der anderen nicht trauen, wegen des Blub-Paradoxons: sie sind mit jeder Sprache zufrieden, die sie gerade benutzen, weil sie die Art und Weise bestimmt, wie sie über Programme denken.

Ich weiß das aus eigener Erfahrung, als ich als High-School-Schüler Programme in Basic schrieb. Diese Sprache unterstützte nicht einmal Rekursion. Es ist schwer vorstellbar, Programme zu schreiben, ohne Rekursion zu verwenden, aber ich habe es damals nicht vermisst. Ich habe in Basic gedacht. Und ich war ein Wunderkind. Herrscher über alles, was ich überblickte.

Die fünf Sprachen, die Eric Raymond Hackern empfiehlt, fallen an verschiedenen Stellen auf dem Leistungskontinuum. Wo sie relativ zueinander fallen, ist ein heikles Thema. Was ich sagen werde, ist, dass ich denke, dass Lisp ganz oben steht. Und um diese Behauptung zu untermauern, werde ich Ihnen von einer der Dinge erzählen, die ich vermisse, wenn ich die anderen vier Sprachen betrachte. Wie kann man in ihnen überhaupt etwas erreichen, denke ich, ohne Makros? [5]

Viele Sprachen haben etwas, das man Makro nennt. Aber Lisp-Makros sind einzigartig. Und ob Sie es glauben oder nicht, was sie tun, hängt mit den Klammern zusammen. Die Entwickler von Lisp haben nicht einfach so all diese Klammern in die Sprache eingebaut, nur 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 das nicht in dem trivialen Sinne, dass die Quelldateien Zeichen enthalten und Strings einer der Datentypen sind, die von der Sprache unterstützt werden. Lisp-Code, nachdem er vom Parser gelesen wurde, besteht aus Datenstrukturen, die man durchlaufen kann.

Wenn Sie verstehen, wie Compiler funktionieren, ist es eigentlich nicht so sehr, dass Lisp eine seltsame Syntax hat, sondern dass Lisp keine Syntax hat. Sie schreiben Programme in den Parsebäumen, die innerhalb des Compilers generiert werden, wenn andere Sprachen geparst werden. Aber diese Parsebäume sind für Ihre Programme vollständig zugänglich. Sie können Programme schreiben, die sie manipulieren. In Lisp werden diese Programme Makros genannt. Es sind Programme, die Programme schreiben.

Programme, die Programme schreiben? Wann möchte man das überhaupt tun? Nicht sehr oft, wenn man in Cobol denkt. Die ganze Zeit, wenn man in Lisp denkt. Es wäre hier bequem, wenn ich ein Beispiel für ein leistungsstarkes Makro geben könnte, und sagen könnte: da! wie ist das? Aber wenn ich das täte, würde es für jemanden, der Lisp nicht kennt, nur wie Kauderwelsch aussehen; es ist hier nicht genug Platz, um alles zu erklären, was man wissen müsste, um zu verstehen, was es bedeutet. In Ansi Common Lisp habe ich versucht, die Dinge so schnell wie möglich voranzutreiben, und trotzdem bin ich erst auf Seite 160 zu den Makros gekommen.

Aber ich glaube, ich kann eine Art Argument liefern, das vielleicht überzeugend ist. Der Quellcode des Viaweb-Editors war wahrscheinlich zu etwa 20-25% aus Makros zusammengesetzt. Makros sind schwieriger zu schreiben als gewöhnliche Lisp-Funktionen, und es gilt als schlechter Stil, sie zu verwenden, wenn sie nicht notwendig sind. Jedes Makro in diesem Code ist also deshalb vorhanden, weil es sein muss. Das bedeutet, dass mindestens 20-25% des Codes in diesem Programm Dinge tun, die man in keiner anderen Sprache so einfach machen kann. Wie skeptisch der Blub-Programmierer gegenüber meinen Behauptungen über die geheimnisvollen Kräfte von Lisp auch sein mag, das sollte ihn neugierig machen. Wir haben diesen Code nicht zu unserem eigenen Vergnügen geschrieben. Wir waren ein winziges Startup, das so fleißig programmierte wie möglich, um technische Barrieren zwischen uns und unseren Konkurrenten aufzubauen.

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

Aikido für Startups

Aber ich erwarte nicht, dass ich jemanden (über 25) überzeugen kann, Lisp zu lernen. Der Zweck dieses Artikels ist nicht, jemandes Meinung zu ändern, sondern um Leute zu beruhigen, die sich bereits für die Verwendung von Lisp interessieren - Leute, die wissen, dass Lisp eine leistungsstarke Sprache ist, aber sich Sorgen machen, weil sie nicht weit verbreitet ist. In einer Wettbewerbssituation ist das ein Vorteil. Lisps Leistungsfähigkeit wird durch die Tatsache verstärkt, dass Ihre Konkurrenten sie nicht verstehen.

Wenn Sie darüber nachdenken, Lisp in einem Startup zu verwenden, sollten Sie sich keine Sorgen machen, dass es nicht allgemein verstanden wird. Sie sollten hoffen, dass das so bleibt. Und das ist wahrscheinlich. Es liegt in der Natur von Programmiersprachen, die meisten Menschen mit dem zufrieden zu stellen, was sie gerade benutzen. Computerhardware verändert sich viel schneller als persönliche Gewohnheiten, so dass die Programmierpraxis in der Regel zehn bis zwanzig Jahre hinter dem Prozessor zurückliegt. An Orten wie dem MIT schrieben sie bereits in den frühen 1960er Jahren Programme in High-Level-Sprachen, aber viele Unternehmen schrieben bis weit in die 1980er Jahre Code in Maschinensprache. Ich wette, viele Leute haben weiterhin in Maschinensprache geschrieben, bis der Prozessor, wie ein Barkeeper, der unbedingt schließen und nach Hause gehen wollte, sie schließlich rausgeschmissen hat, indem er auf einen RISC-Befehlssatz umgestellt hat.

Normalerweise verändert sich Technologie schnell. Aber Programmiersprachen sind anders: Programmiersprachen sind nicht nur Technologie, sondern auch, woran Programmierer denken. Sie sind zur Hälfte Technologie und zur Hälfte Religion. [6] Und so bewegt sich die mittlere Sprache, das heißt, die Sprache, die der mittlere Programmierer verwendet, so langsam wie ein Eisberg. Garbage Collection, die um 1960 von Lisp eingeführt wurde, wird heute weithin als eine gute Sache angesehen. Runtime-Typing, ditto, wird immer beliebter. Lexikalische Closures, die von Lisp in den frühen 1970er Jahren eingeführt wurden, sind jetzt, gerade so, auf dem Radar. Makros, die von Lisp Mitte der 1960er Jahre eingeführt wurden, sind immer noch Terra incognita.

Offensichtlich hat die mittlere Sprache eine enorme Dynamik. Ich schlage nicht vor, dass man diese mächtige Kraft bekämpfen kann. Was ich vorschlage, ist genau das Gegenteil: dass man, wie ein Aikido-Praktizierender, sie gegen seine Gegner verwenden kann.

Wenn Sie für ein großes Unternehmen arbeiten, ist das vielleicht nicht einfach. Sie werden es schwer haben, den spitzbärtigen Chef davon zu überzeugen, dass Sie Dinge in Lisp bauen sollen, wenn er gerade in der Zeitung gelesen hat, dass eine andere Sprache, wie Ada vor zwanzig Jahren, bereit ist, die Welt zu erobern. Aber wenn Sie für ein Startup arbeiten, das noch keine spitzbärtigen Chefs hat, können Sie, wie wir es getan haben, das Blub-Paradoxon zu Ihrem Vorteil nutzen: Sie können Technologie verwenden, die Ihre Konkurrenten, die untrennbar an der mittleren Sprache festhalten, niemals erreichen können.

Wenn Sie jemals für ein Startup arbeiten, hier ein nützlicher Tipp, um Konkurrenten zu beurteilen. Lesen Sie ihre Stellenangebote. Alles andere auf ihrer Website kann Stockfotos oder das literarische Gegenstück sein, aber die Stellenangebote müssen genau angeben, was sie wollen, sonst bekommen sie die falschen Kandidaten.

In den Jahren, in denen wir an Viaweb gearbeitet haben, habe ich viele Stellenbeschreibungen gelesen. Jeden Monat schien ein neuer Konkurrent aus dem Nichts aufzutauchen. Das erste, was ich tat, nachdem ich überprüft hatte, ob sie eine Live-Online-Demo hatten, war, mir ihre Stellenangebote anzusehen. Nach ein paar Jahren konnte ich sagen, welche Unternehmen mir Sorgen machten und welche nicht. Je mehr IT-Geschmack die Stellenbeschreibungen hatten, desto weniger gefährlich war das Unternehmen. Die sichersten waren die, die Oracle-Erfahrung wollten. Um die musste man sich nie Sorgen machen. Man war auch sicher, wenn sie sagten, dass sie C++ oder Java-Entwickler wollten. Wenn sie Perl oder Python-Programmierer wollten, wäre das schon etwas beängstigend - das klingt schon nach einem Unternehmen, wo die technische Seite, zumindest, von echten Hackern geleitet wird. Wenn ich jemals eine Stellenanzeige für Lisp-Hacker gesehen hätte, wäre ich wirklich besorgt gewesen.

Anmerkung

[1] Viaweb hatte zunächst zwei Teile: den Editor, der in Lisp geschrieben wurde, den die Leute nutzten, um ihre Websites zu erstellen, und das Bestellsystem, das in C geschrieben wurde und Bestellungen abwickelte. Die erste Version war hauptsächlich in Lisp geschrieben, weil das Bestellsystem klein war. Später fügten wir zwei weitere Module hinzu, einen Bildgenerator, der in C geschrieben wurde, und einen Back-Office-Manager, der hauptsächlich in Perl geschrieben wurde.

Im Januar 2003 veröffentlichte Yahoo eine neue Version des Editors, der in C++ und Perl geschrieben wurde. 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 seitenerstellenden Vorlagen sind, soweit ich weiß, immer noch Lisp-Code. (Siehe Greenspuns Zehnte Regel).

[2] Robert Morris sagt, dass ich nicht geheimnisvoll sein musste, weil auch wenn unsere Konkurrenten gewusst hätten, dass wir Lisp verwenden, hätten sie nicht verstanden, warum: "Wenn sie so schlau wären, würden sie schon in Lisp programmieren."

[3] Alle Sprachen sind gleich leistungsstark im Sinne der Turing-Äquivalenz, aber das ist nicht der Sinn des Wortes, der Programmierer interessiert. (Niemand möchte eine Turing-Maschine programmieren.) Die Art von Leistung, die Programmierer interessiert, ist vielleicht nicht formal definierbar, aber eine Möglichkeit, sie zu erklären, wäre zu sagen, dass sie sich auf Features bezieht, die man in der weniger leistungsstarken Sprache nur durch das Schreiben eines Interpreters für die leistungsstärkere Sprache in ihr erhalten könnte. Wenn Sprache A einen Operator zum Entfernen von Leerzeichen aus Zeichenketten hat und Sprache B dies nicht hat, macht das A wahrscheinlich nicht leistungsfähiger, weil man wahrscheinlich eine Subroutine schreiben kann, um dies in B zu tun. Aber wenn A, sagen wir, Rekursion unterstützt, und B nicht, ist es nicht wahrscheinlich, dass man das beheben kann, indem man Bibliotheksfunktionen schreibt.

[4] Hinweis für Nerds: oder möglicherweise ein Gitter, das sich nach oben hin verengt; es ist nicht die Form, die hier wichtig ist, sondern die Idee, dass es zumindest eine partielle Ordnung gibt.

[5] Es ist ein bisschen irreführend, Makros als separates Feature zu behandeln. In der Praxis wird ihre Nützlichkeit durch andere Lisp-Features wie lexikalische Closures und Restparameter erheblich verstärkt.

[6] Daher haben Vergleiche von Programmiersprachen entweder die Form von Religionskriegen oder von Lehrbüchern für Studenten, die so entschlossen neutral sind, dass sie eigentlich anthropologische Werke sind. Menschen, die ihren Frieden schätzen oder eine feste Anstellung wünschen, meiden das Thema. Aber die Frage ist nur zur Hälfte eine religiöse Frage; es gibt etwas, das es wert ist, studiert zu werden, besonders wenn man neue Sprachen entwerfen möchte.