DEN DURCHSCHNITT SCHLAGEN

April 2001, rev. April 2003

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

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

Natürlich könnten viele Leute gleichzeitig auf diese Idee gekommen sein, aber soweit ich weiß, war Viaweb die erste webbasierte Anwendung. Die Idee erschien uns so neuartig, dass wir das Unternehmen danach benannten: Viaweb, weil unsere Software über das Web funktionierte und nicht auf Ihrem Desktop-Computer lief.

Ein weiteres ungewöhnliches Merkmal 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 wurden, das bis dahin hauptsächlich an Universitäten und in Forschungslabors verwendet wurde. [1]

Die Geheimwaffe

Eric Raymond hat einen Aufsatz mit dem Titel „Wie werde ich ein Hacker“ geschrieben, in dem er angehenden Hackern unter anderem erklärt, welche Sprachen sie lernen sollten. Er schlägt vor, mit Python und Java zu beginnen, da diese leicht zu erlernen sind. Der ernsthafte Hacker sollte auch C lernen, 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:

Das Erlernen von Lisp lohnt sich schon wegen des tiefen Erleuchtungserlebnisses, das Sie haben werden, wenn Sie es endlich beherrschen; diese Erfahrung wird Sie für den Rest Ihres Lebens zu einem besseren Programmierer machen, selbst wenn Sie Lisp selbst nie wirklich oft verwenden.

Dies ist das gleiche Argument, das Sie häufig hören, wenn es um das Erlernen von Latein geht. Sie werden damit zwar keinen Job bekommen, außer vielleicht als Professor für klassische Altertumswissenschaften, aber Sie werden dadurch Ihr geistiges Vermögen verbessern und in den Sprachen, die Sie verwenden möchten, wie Englisch, besser schreiben können.

Aber warten Sie mal. So weit reicht diese Metapher nicht. Der Grund, warum Sie mit Latein keinen Job bekommen, 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 sagen.

Wenn Sie also durch Lisp, wie er sagt, zu einem besseren Programmierer werden, warum sollten Sie es dann nicht verwenden wollen? Wenn man einem Maler einen Pinsel anbieten würde, der ihn zu einem besseren Maler machen würde, würde er ihn meiner Meinung nach in all seinen Gemälden verwenden wollen, nicht wahr? Ich möchte mich hier nicht über Eric Raymond lustig machen. Im Großen und Ganzen ist sein Rat gut. Was er über Lisp sagt, entspricht im Wesentlichen der gängigen Meinung. Aber in der gängigen Meinung steckt ein Widerspruch: Lisp wird Sie zu einem besseren Programmierer machen, und trotzdem werden Sie es nicht verwenden.

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?

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 schneller und besser Software schreibt, wird, wenn alle anderen Bedingungen gleich bleiben, seine Konkurrenten aus dem Geschäft drängen. Und wenn Sie ein Startup gründen, spüren Sie dies besonders deutlich. Startups sind in der Regel ein Alles-oder-Nichts-Geschäft. Entweder Sie werden reich, oder Sie bekommen nichts. Wenn Sie in einem Startup auf die falsche Technologie setzen, werden Ihre Konkurrenten Sie vernichten.

Robert und ich kannten Lisp beide gut und sahen keinen Grund, nicht unserem Instinkt zu vertrauen und uns für Lisp zu entscheiden. Wir wussten, dass alle anderen ihre Software in C++ oder Perl schrieben. Aber wir wussten auch, dass das nichts zu bedeuten hatte. Wenn man sich für eine Technologie auf diese Weise entschied, würde man Windows verwenden. Wenn man sich für eine Technologie entscheidet, muss man ignorieren, was andere Leute tun, und nur das in Betracht ziehen, was am besten funktioniert.

Das gilt insbesondere 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, viele Leute sind sich dessen nicht bewusst, selbst in Startups nicht.

Ein durchschnittliches Großunternehmen wächst jährlich um etwa zehn Prozent. Wenn Sie also ein Großunternehmen leiten und alles so machen, wie es ein durchschnittliches Großunternehmen macht, können Sie davon ausgehen, dass Sie genauso gut abschneiden wie ein durchschnittliches Großunternehmen – das heißt, dass Sie jährlich um etwa zehn Prozent wachsen.

Das Gleiche passiert natürlich auch, wenn Sie ein Startup leiten. Wenn Sie alles so machen, wie es ein durchschnittliches Startup macht, können Sie mit durchschnittlicher Leistung rechnen. Das Problem dabei ist, dass durchschnittliche Leistung bedeutet, dass Sie Ihr Geschäft aufgeben. Die Überlebensrate von Startups liegt weit unter fünfzig Prozent. Wenn Sie also ein Startup leiten, sollten Sie besser etwas Ungewöhnliches tun. Wenn nicht, stecken Sie in Schwierigkeiten.

1995 wussten wir etwas, was unsere Konkurrenten meiner Meinung nach nicht verstanden haben und was auch heute noch nur wenige verstehen: Wenn Sie Software schreiben, die nur auf Ihren eigenen Servern laufen muss, können Sie jede beliebige Sprache verwenden. Beim Schreiben von Desktop-Software tendiert man stark dazu, Anwendungen in derselben Sprache wie das Betriebssystem zu schreiben. Vor zehn Jahren bedeutete das Schreiben von Anwendungen, Anwendungen in C zu schreiben. Aber bei webbasierter Software können Sie jede beliebige Sprache verwenden, insbesondere wenn Sie den Quellcode sowohl der Sprache als auch des Betriebssystems haben.

Diese neue Freiheit ist jedoch ein zweischneidiges Schwert. Jetzt, wo man jede beliebige Sprache verwenden kann, muss man sich überlegen, welche man verwendet. Unternehmen, die so tun, als hätte sich nichts geändert, laufen Gefahr, festzustellen, dass sich bei ihren Konkurrenten nichts geändert hat.

Wenn Sie jede beliebige Sprache verwenden können, welche würden Sie verwenden? Wir haben uns für Lisp entschieden. Zunächst einmal war es offensichtlich, dass eine schnelle Entwicklung in diesem Markt wichtig sein würde. Wir fingen alle bei Null an, daher wäre ein Unternehmen, das neue Funktionen vor der Konkurrenz fertigstellen konnte, ein großer Vorteil. Wir wussten, dass Lisp eine wirklich gute Sprache zum schnellen Schreiben von Software ist, und serverbasierte Anwendungen verstärken den Effekt der schnellen Entwicklung, da man die Software sofort veröffentlichen kann, wenn 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 keinerlei Geschäftserfahrung. Wir wussten nichts über Marketing, Personaleinstellung, Geldbeschaffung oder Kundengewinnung. Keiner von uns hatte jemals einen richtigen Job gehabt. Das Einzige, worin wir gut waren, war das Schreiben von Software. Wir hofften, das würde uns retten. Wir nutzten jeden Vorteil, den wir in der Softwareabteilung bekommen konnten.

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, Funktionen schneller fertigstellen könnten als unsere Konkurrenten und auch Dinge in unserer Software tun könnten, die sie nicht tun könnten. Und weil Lisp so hochentwickelt war, bräuchten wir kein großes Entwicklungsteam, sodass unsere Kosten niedriger wären. Wenn das so wäre, könnten wir ein besseres Produkt für weniger Geld anbieten und trotzdem Gewinn machen. Wir würden am Ende alle Benutzer bekommen und unsere Konkurrenten würden keinen einzigen bekommen und irgendwann ihr Geschäft aufgeben. Das war jedenfalls das, was wir hofften.

Was waren die Ergebnisse dieses Experiments? Etwas überraschend, es funktionierte. Wir hatten schließlich viele Konkurrenten, etwa zwanzig bis dreißig, aber keine ihrer Software konnte mit unserer konkurrieren. Wir hatten einen WYSIWYG-Onlineshop-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 Bezug auf 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 von ein oder zwei Tagen nach der Ankündigung eines Konkurrenten in einer Pressemitteilung duplizieren konnten. Bis die Journalisten, die über die Pressemitteilung berichteten, uns anriefen, hatten wir die neue Funktion auch.

Unsere Konkurrenten müssen geglaubt haben, wir hätten 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 verriet uns Neuigkeiten über ihre Funktionen. Wir konnten einfach schneller Software entwickeln, als irgendjemand es für möglich gehalten hätte.

Als ich etwa neun war, bekam ich zufällig ein Exemplar von Der Schakal von Frederick Forsyth in die Hände. Die Hauptfigur ist ein Auftragsmörder, der den französischen Präsidenten töten soll. Der Mörder muss an der Polizei vorbei, um zu einer Wohnung zu gelangen, die auf die Route des Präsidenten hinausgeht. Er geht direkt an ihnen vorbei, verkleidet als alter Mann auf Krücken, und sie schöpfen keinen Verdacht gegen ihn.

Unsere Geheimwaffe war ähnlich. Wir schrieben unsere Software in einer seltsamen KI-Sprache mit einer bizarren Syntax voller Klammern. Jahrelang hatte es mich geärgert, wenn Lisp so beschrieben wurde. Aber jetzt war es zu unserem Vorteil. Im Geschäftsleben gibt es nichts Wertvolleres als einen technischen Vorteil, den die Konkurrenz nicht versteht. Im Geschäftsleben wie im Krieg ist Überraschung genauso viel wert wie Gewalt.

Und so muss ich, es ist mir ein wenig peinlich, sagen, dass ich während der Arbeit an Viaweb nie öffentlich etwas über Lisp gesagt habe. Wir haben es der Presse gegenüber nie erwähnt, und wenn man auf unserer Website nach Lisp suchte, fand man in meiner Biografie nur die Titel zweier Bücher. 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 war, oder es ihnen egal war, wollte ich das auch 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 merkten, dass es wirklich gut funktionierte. Sie konnten damit buchstäblich in wenigen Minuten gut aussehende Online-Shops erstellen. Und so gewannen wir, hauptsächlich durch Mundpropaganda, immer mehr Benutzer. Ende 1996 hatten wir etwa 70 Online-Shops. Ende 1997 waren es 500. Sechs Monate später, als Yahoo uns kaufte, hatten wir 1070 Benutzer. Heute dominiert diese Software als Yahoo Store weiterhin ihren Markt. Sie ist einer der profitableren Teile von Yahoo, und die damit erstellten Shops bilden die Grundlage von Yahoo Shopping. Ich habe Yahoo 1999 verlassen, also weiß ich nicht genau, wie viele Benutzer sie jetzt haben, aber das letzte, was ich hörte, waren 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 wie eine rhetorische Frage, aber eigentlich gibt es ganz einfache Antworten. Lisp ist nicht wegen einer magischen Eigenschaft so toll, die nur Anhängern auffallen würde, sondern weil es einfach die leistungsfähigste Sprache ist, die es gibt. Und der Grund, warum es nicht jeder verwendet, ist, dass Programmiersprachen nicht nur Technologien sind, sondern auch Denkgewohnheiten, und nichts ändert sich langsamer. Natürlich müssen beide Antworten erklärt werden.

Ich beginne mit einer erschreckend kontroversen Aussage: Die Leistungsfähigkeit von Programmiersprachen ist unterschiedlich.

Wenige würden zumindest bestreiten, dass höhere Programmiersprachen leistungsfähiger sind als Maschinensprachen. Die meisten Programmierer würden heute zustimmen, dass man normalerweise nicht in Maschinensprache programmieren möchte. Stattdessen sollte man in einer höheren Programmiersprache programmieren und diese von einem Compiler in Maschinensprache übersetzen lassen. Diese Idee ist heute sogar in die Hardware integriert: Seit den 1980er Jahren werden Befehlssätze für Compiler und nicht für menschliche Programmierer entwickelt.

Jeder weiß, dass es ein Fehler ist, das ganze Programm von Hand in Maschinensprache zu schreiben. Was weniger verstanden wird, ist, dass es hier ein allgemeineres Prinzip gibt: Wenn Sie die Wahl zwischen mehreren Sprachen haben, ist es, wenn alle anderen Bedingungen gleich sind, ein Fehler, in einer anderen Sprache als der leistungsfähigsten zu programmieren. [3]

Von dieser Regel gibt es viele Ausnahmen. Wenn Sie ein Programm schreiben, das sehr eng mit einem Programm in einer bestimmten Sprache zusammenarbeiten muss, ist es möglicherweise eine gute Idee, das neue Programm in derselben Sprache zu schreiben. Wenn Sie ein Programm schreiben, das nur etwas sehr Einfaches tun muss, wie Zahlen verarbeiten oder Bitmanipulation, können Sie auch eine weniger abstrakte Sprache verwenden, insbesondere, da diese möglicherweise etwas schneller ist. Und wenn Sie ein kurzes, wegwerfbares Programm schreiben, sind Sie möglicherweise besser dran, wenn Sie einfach die Sprache verwenden, die die besten Bibliotheksfunktionen für die Aufgabe hat. Aber im Allgemeinen möchten Sie für Anwendungssoftware die leistungsstärkste (und einigermaßen effiziente) Sprache verwenden, die Sie bekommen können, und alles andere zu verwenden ist ein Fehler, genau der gleichen Art, wenn auch möglicherweise in geringerem Ausmaß, wie das Programmieren in Maschinensprache.

Sie sehen, dass Maschinensprachen sehr einfach aufgebaut sind. 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 Bestimmtes. Es gibt keine Trennlinie zwischen Maschinensprachen auf der einen Seite und allen Hochsprachen auf der anderen. Sprachen fallen auf ein Kontinuum [4] der Abstraktheit, von den mächtigsten bis hinunter zu Maschinensprachen, die selbst in ihrer Leistung variieren.

Betrachten wir Cobol. Cobol ist eine Hochsprache, da es in Maschinensprache kompiliert wird. Würde jemand ernsthaft behaupten, dass Cobol in seiner Leistungsfähigkeit mit Python vergleichbar ist? Es ist wahrscheinlich näher an der Maschinensprache als an Python.

Oder wie wäre es mit Perl 4? Zwischen Perl 4 und Perl 5 wurden der Sprache lexikalische Closures hinzugefügt. Die meisten Perl-Hacker würden zustimmen, dass Perl 5 leistungsfähiger ist als Perl 4. Aber wenn man das einmal zugegeben hat, hat man auch zugegeben, dass eine höhere Programmiersprache leistungsfähiger sein kann als eine andere. Und daraus folgt unweigerlich, dass man, außer in Sonderfällen, die leistungsfähigste Sprache verwenden sollte, die man bekommen kann.

Allerdings wird diese Idee selten bis zum Ende verfolgt. Ab einem gewissen Alter wechseln Programmierer selten freiwillig die Sprache. Egal, an welche Sprache die Leute gewöhnt sind, sie halten sie für gerade gut genug.

Programmierer hängen sehr an ihren Lieblingssprachen und ich möchte niemandes Gefühle verletzen. Um diesen Punkt zu erklären, werde ich eine hypothetische Sprache namens Blub verwenden. Blub liegt genau in der Mitte des Abstraktheitskontinuums. Es ist nicht die leistungsstärkste Sprache, aber sie ist leistungsfähiger als Cobol oder Maschinensprachen.

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

Solange unser hypothetischer Blub-Programmierer das Leistungsspektrum nach unten betrachtet, weiß er, dass er nach unten schaut. Sprachen, die weniger leistungsstark sind als Blub, sind offensichtlich weniger leistungsstark, weil ihnen eine Funktion fehlt, an die er gewöhnt ist. Aber wenn unser hypothetischer Blub-Programmierer in die andere Richtung schaut, nach oben, merkt er nicht, dass er nach oben schaut. Was er sieht, sind bloß seltsame Sprachen. Wahrscheinlich hält er sie für etwa gleich leistungsstark 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 die Perspektive eines Programmierers einnehmen, der eine der Sprachen verwendet, die auf der Leistungsskala höher angesiedelt sind, sehen wir, dass dieser wiederum auf Blub herabblickt. Wie kann man in Blub überhaupt etwas erreichen? Es hat nicht einmal y.

Durch Induktion sind die einzigen Programmierer, die alle Leistungsunterschiede zwischen den verschiedenen Sprachen erkennen können, diejenigen, die die leistungsstärkste Sprache verstehen. (Das ist wahrscheinlich, was Eric Raymond meinte, als er sagte, dass Lisp Sie zu einem besseren Programmierer macht.) Sie können den Meinungen der anderen nicht trauen, und zwar aufgrund des Blub-Paradoxons: Sie sind mit der Sprache zufrieden, die sie gerade verwenden, weil sie ihnen die Art und Weise vorschreibt, wie sie über Programme denken.

Ich weiß das aus eigener Erfahrung, als ich als Highschool-Schüler 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 Ass darin. Meister in allem, was ich überblickte.

Die fünf Sprachen, die Eric Raymond Hackern empfiehlt, liegen an verschiedenen Punkten des Leistungsspektrums. Wo sie im Verhältnis zueinander stehen, ist ein heikles Thema. Ich möchte sagen, dass ich Lisp an der Spitze sehe. Und um diese Behauptung zu untermauern, möchte ich Ihnen etwas über die Dinge erzählen, die ich vermisse, wenn ich mir die anderen vier Sprachen ansehe. Wie kann man in ihnen, glaube ich, etwas erreichen, ohne Makros? [5]

Viele Sprachen haben etwas, das Makro genannt wird. 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 all diese Klammern nicht nur in die Sprache eingefügt, um anders zu sein. Für den Blub-Programmierer sieht Lisp-Code seltsam aus. Aber diese Klammern sind aus einem bestimmten 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 im trivialen Sinne, dass die Quelldateien Zeichen enthalten und Zeichenfolgen einer der von der Sprache unterstützten Datentypen sind. Lisp-Code besteht, nachdem er vom Parser gelesen wurde, aus Datenstrukturen, die Sie durchlaufen können.

Wenn Sie verstehen, wie Compiler funktionieren, liegt das Problem nicht so sehr darin, dass Lisp eine seltsame Syntax hat, sondern vielmehr darin, dass Lisp keine Syntax hat. Sie schreiben Programme in den Parsebäumen, die im Compiler 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. 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. Immer, wenn Sie in Lisp denken. Es wäre praktisch, wenn ich hier ein Beispiel für ein leistungsstarkes Makro geben und sagen könnte: „Na, wie wäre es damit?“ Aber wenn ich das täte, würde es für jemanden, der Lisp nicht kennt, einfach wie Kauderwelsch aussehen; hier ist nicht genug Platz, um alles zu erklären, was Sie wissen müssen, 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 Makros gekommen.

Aber ich glaube, ich kann ein Argument vorbringen, 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 da, weil es da sein muss. Das bedeutet, dass mindestens 20-25 % des Codes in diesem Programm Dinge tun, die man in keiner anderen Sprache so einfach tun kann. So skeptisch der Blub-Programmierer meinen Behauptungen über die mysteriösen Kräfte von Lisp auch gegenüberstehen mag, dies sollte ihn neugierig machen. Wir haben diesen Code nicht zu unserem eigenen Vergnügen geschrieben. Wir waren ein kleines Startup, das so viel programmierte wie möglich, um technische Barrieren zwischen uns und unseren Konkurrenten aufzubauen.

Ein misstrauischer Mensch könnte sich fragen, ob hier ein Zusammenhang besteht. Ein großer Teil unseres Codes machte Dinge, die in anderen Sprachen nur sehr schwer möglich sind. Die daraus resultierende Software konnte Dinge, die die Software unserer Konkurrenten nicht konnte. Vielleicht gab es da irgendeine Verbindung. Ich ermutige Sie, diesem Thread zu folgen. Es könnte mehr hinter dem alten Mann stecken, der auf seinen Krücken herumhumpelt, als man auf den ersten Blick sieht.

Aikido für Startups

Aber ich erwarte nicht, dass ich irgendjemanden ( über 25 ) davon überzeugen kann, Lisp zu lernen. Der Zweck dieses Artikels ist nicht, irgendjemanden umzustimmen, sondern Leute zu beruhigen, die bereits an Lisp interessiert sind - Leute, die wissen, dass Lisp eine mächtige Sprache ist, aber beunruhigt sind, weil sie nicht weit verbreitet ist. In einer Wettbewerbssituation ist das ein Vorteil. Lisps Macht wird durch die Tatsache vervielfacht, dass Ihre Konkurrenten es nicht verstehen.

Wenn Sie in einem Startup daran denken, Lisp zu verwenden, 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 der Programmiersprachen, dass die meisten Leute mit der Sprache zufrieden sind, die sie gerade verwenden. Computerhardware ändert sich so viel schneller als persönliche Gewohnheiten, dass die Programmierpraxis dem Prozessor normalerweise zehn bis zwanzig Jahre hinterherhinkt. An Einrichtungen wie dem MIT schrieben sie in den frühen 1960er Jahren Programme in höheren Programmiersprachen, aber viele Unternehmen schrieben noch bis weit in die 1980er Jahre hinein Code in Maschinensprache. Ich wette, viele Leute schrieben weiterhin Maschinensprache, bis der Prozessor sie schließlich, wie ein Barkeeper, der es kaum erwarten kann, zu schließen und nach Hause zu gehen, hinauswarf, indem er auf einen RISC-Befehlssatz umstellte.

Normalerweise ändert sich die Technologie schnell. Aber Programmiersprachen sind anders: Programmiersprachen sind nicht nur Technologie, sondern das, woran Programmierer denken. Sie sind halb Technologie und halb Religion.[6] Und so bewegt sich die durchschnittliche Sprache, also die Sprache, die der durchschnittliche Programmierer verwendet, so langsam wie ein Eisberg. Die Garbage Collection, die von Lisp um 1960 eingeführt wurde, wird heute allgemein als eine gute Sache angesehen. Das Gleiche gilt für die Laufzeittypisierung, die immer beliebter wird. Lexikalische Closures, die von Lisp in den frühen 1970er Jahren eingeführt wurden, sind jetzt gerade so auf dem Radarschirm. Makros, die von Lisp Mitte der 1960er Jahre eingeführt wurden, sind immer noch Terra incognita.

Offensichtlich hat die mediale Sprache eine enorme Dynamik. Ich behaupte nicht, dass man diese mächtige Kraft bekämpfen kann. Ich behaupte genau das Gegenteil: dass man sie wie ein Aikido-Praktizierender gegen seine Gegner einsetzen kann.

Wenn Sie für ein großes Unternehmen arbeiten, ist das vielleicht nicht so einfach. Sie werden es schwer haben, den spitzhaarigen Chef davon zu überzeugen, Sie Dinge in Lisp bauen zu lassen, wenn er gerade in der Zeitung gelesen hat, dass eine andere Sprache im Begriff ist, die Welt zu erobern, wie Ada vor zwanzig Jahren. Aber wenn Sie für ein Startup arbeiten, das noch keine spitzhaarigen Chefs hat, können Sie, wie wir, das Blub-Paradoxon zu Ihrem Vorteil nutzen: Sie können eine Technologie nutzen, mit der Ihre Konkurrenten, die unerschütterlich an der Mittelsprache kleben, niemals mithalten können.

Falls Sie jemals für ein Startup arbeiten, haben wir hier einen praktischen Tipp für Sie, um die Konkurrenz einzuschätzen. Lesen Sie deren Stellenausschreibungen. Alles andere auf deren Website sind vielleicht Archivfotos oder das Prosa-Äquivalent, aber die Stellenausschreibungen müssen genau angeben, was sie suchen, sonst bekommen sie die falschen Bewerber.

Während der Jahre, in denen wir bei Viaweb gearbeitet haben, habe ich viele Stellenbeschreibungen gelesen. Etwa jeden Monat tauchte ein neuer Konkurrent aus dem Nichts auf. Nachdem ich überprüft hatte, ob sie eine Live-Online-Demo hatten, schaute ich mir als Erstes ihre Stellenangebote an. Nach ein paar Jahren wusste ich, welche Unternehmen mir Sorgen machen mussten und welche nicht. Je mehr IT-Flair die Stellenbeschreibungen hatten, desto weniger gefährlich war das Unternehmen. Am sichersten waren diejenigen, die Oracle-Erfahrung verlangten. Darüber musste man sich nie Sorgen machen. Man war auch sicher, wenn sie sagten, sie wollten C++- oder Java-Entwickler. Wenn sie Perl- oder Python-Programmierer wollten, wäre das ein bisschen beängstigend gewesen – das klingt langsam nach einem Unternehmen, bei dem zumindest die technische Seite von echten Hackern geleitet wird. Wenn ich jemals eine Stellenanzeige gesehen hätte, in der nach Lisp-Hackern gesucht wurde, wäre ich wirklich besorgt gewesen.

Hinweise

[1] Viaweb bestand zunächst aus zwei Teilen: dem in Lisp geschriebenen Editor, mit dem die Benutzer ihre Websites erstellten, und dem in C geschriebenen Bestellsystem, das die Bestellungen abwickelte. Die erste Version bestand hauptsächlich aus Lisp, da das Bestellsystem klein war. Später fügten wir zwei weitere Module hinzu, einen in C geschriebenen Bildgenerator und einen Backoffice-Manager, der hauptsächlich in Perl geschrieben war.

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

[2] Robert Morris sagt, ich hätte kein Geheimnis daraus machen müssen, denn selbst 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 bereits in Lisp programmieren.“

[3] Alle Sprachen sind im Sinne der Turing-Äquivalente gleich leistungsfähig, aber das ist nicht der Sinn des Wortes, der für Programmierer von Bedeutung ist. (Niemand möchte eine Turing-Maschine programmieren.) Die Art von Leistung, die für Programmierer von Bedeutung ist, ist möglicherweise nicht formal definierbar, aber man könnte es so erklären, dass es sich um Funktionen handelt, die man in der weniger leistungsfähigen Sprache nur erhalten kann, wenn man einen Interpreter für die leistungsfähigere Sprache darin schreibt. Wenn Sprache A einen Operator zum Entfernen von Leerzeichen aus Zeichenfolgen hat und Sprache B nicht, macht das A wahrscheinlich nicht leistungsfähiger, weil man wahrscheinlich eine Subroutine 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] Anmerkung für Nerds: oder möglicherweise ein Gitter, das nach oben hin schmaler wird; es kommt hier nicht auf die Form an, sondern auf die Idee, dass zumindest eine teilweise Ordnung vorliegt.

[5] Es ist etwas 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 gesteigert.

[6] Infolgedessen nehmen Vergleiche von Programmiersprachen entweder die Form von Religionskriegen an oder sind so neutrale Lehrbücher für Studenten, dass sie eigentlich anthropologische Werke sind. Menschen, denen ihre Ruhe wichtig ist oder die eine Festanstellung anstreben, meiden das Thema. Aber die Frage ist nur zur Hälfte eine religiöse; es gibt etwas, das es wert ist, untersucht zu werden, insbesondere wenn man neue Sprachen entwickeln möchte.