Loading...

DIE DURCHSCHNITTLICHEN SCHLAGEN

Original

April 2001, rev. April 2003

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

Im Sommer 1995 starteten mein Freund Robert Morris und ich ein Startup namens Viaweb. Unser Plan war es, Software zu schreiben, die es Endnutzern ermöglicht, Online-Shops zu erstellen. Was zu dieser Zeit neuartig an dieser Software war, war, dass sie auf unserem Server lief und gewöhnliche Webseiten als Schnittstelle verwendete.

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

Ein weiteres Ungewöhnliches an dieser Software war, dass sie hauptsächlich in einer Programmiersprache namens Lisp geschrieben wurde. Es war eine der ersten großen Anwendungen für Endnutzer, 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 man ein Hacker wird" geschrieben, und darin empfiehlt er angehenden Hackern unter anderem, welche Sprachen sie lernen sollen. Er schlägt vor, mit Python und Java zu beginnen, da sie leicht zu lernen sind. Der ernsthafte Hacker wird auch C lernen wollen, um Unix zu hacken, und Perl für Systemadministration und CGI-Skripte. Schließlich sollte der wirklich ernsthafte Hacker in Betracht ziehen, Lisp zu lernen:

Lisp ist es wert, gelernt zu werden, weil man die tiefgreifende Erleuchtungserfahrung haben wird, wenn man es endlich versteht; diese Erfahrung wird Sie für den Rest Ihres Lebens zu einem besseren Programmierer machen, auch wenn Sie Lisp selbst danach nicht viel verwenden.

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

Aber warten Sie mal. Dieses Gleichnis lässt sich nicht so weit ausdehnen. Der Grund, warum Latein keinen Job verschafft, ist, dass niemand es spricht. Wenn Sie auf Latein schreiben, kann Sie niemand verstehen. Aber Lisp ist eine Computersprache, und Computer sprechen, was immer Sie, der Programmierer, ihnen sagen.

Wenn Lisp Sie also, wie er sagt, zu einem besseren Programmierer macht, warum würden Sie es dann nicht verwenden wollen? Wenn einem Maler ein Pinsel angeboten würde, der ihn zu einem besseren Maler machen würde, scheint es mir, dass er ihn in all seinen Gemälden verwenden möchte, oder nicht? Ich versuche hier nicht, über Eric Raymond lustig zu machen. Im Großen und Ganzen ist sein Rat gut. Was er über Lisp sagt, entspricht ziemlich genau der gängigen Weisheit. Aber es gibt einen Widerspruch in der gängigen Weisheit: 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 tatsächlich bessere Programme hervorbringt, 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 Konkurrenz aus dem Geschäft drängen. Und wenn man ein Startup gründet, spürt man das sehr deutlich. Startups tendieren dazu, eine Alles-oder-Nichts-Angelegenheit zu sein. Entweder werden Sie reich, oder Sie bekommen gar nichts. In einem Startup, wenn Sie auf die falsche Technologie setzen, werden Ihre Konkurrenten Sie zermalmen.

Robert und ich kannten Lisp gut und konnten keinen Grund sehen, unseren Instinkten nicht zu vertrauen und mit Lisp zu gehen. Wir wussten, dass alle anderen ihre Software in C++ oder Perl schrieben. Aber wir wussten auch, dass das nichts zu bedeuten hatte. Wenn Sie Technologie so auswählen, würden Sie Windows verwenden. Wenn Sie Technologie wählen, müssen Sie ignorieren, was andere machen, und nur darüber nachdenken, was am besten funktionieren wird.

Das gilt besonders für ein Startup. In einem großen Unternehmen können Sie das tun, was alle anderen großen Unternehmen tun. Aber ein Startup kann nicht das tun, was alle anderen Startups tun. Ich glaube, das wird nicht von vielen verstanden, 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 der durchschnittliche große Konzern macht, können Sie erwarten, genauso gut abzuschneiden wie der Durchschnitt der großen Unternehmen - das heißt, etwa zehn Prozent pro Jahr zu wachsen.

Dasselbe wird natürlich auch passieren, wenn Sie ein Startup leiten. Wenn Sie alles so machen, wie es der durchschnittliche Startup tut, sollten Sie mit durchschnittlicher Leistung rechnen. Das Problem hierbei ist, dass durchschnittliche Leistung bedeutet, dass Sie aus dem Geschäft gehen werden. Die Überlebensrate für Startups liegt deutlich unter fünfzig Prozent. Wenn Sie also ein Startup leiten, müssen Sie unbedingt etwas Ungewöhnliches tun. Wenn nicht, sind Sie in Schwierigkeiten.

1995 wussten wir etwas, das ich glaube, unsere Konkurrenz nicht verstanden hat und was auch heute noch viele nicht verstehen: Wenn Sie Software schreiben, die nur auf Ihren eigenen Servern laufen muss, können Sie jede beliebige Sprache verwenden. Wenn Sie Desktop-Software schreiben, gibt es eine starke Tendenz, Anwendungen in der gleichen Sprache wie das Betriebssystem zu schreiben. Vor zehn Jahren bedeutete Anwendungsentwicklung, in C zu programmieren. Aber bei webbasierten Software, vor allem wenn Sie den Quellcode sowohl der Sprache als auch des Betriebssystems haben, können Sie jede beliebige Sprache verwenden.

Diese neue Freiheit ist jedoch ein zweischneidiges Schwert. Jetzt, da Sie jede Sprache verwenden können, müssen Sie darüber nachdenken, welche Sie verwenden. Unternehmen, die so tun, als habe sich nichts geändert, riskieren, dass ihre Konkurrenz das nicht tut.

Wenn Sie jede Sprache verwenden können, welche verwenden Sie dann? Wir haben uns für Lisp entschieden. Zum einen war es offensichtlich, dass schnelle Entwicklung in diesem Markt wichtig sein würde. Wir starteten alle von Null, also würde ein Unternehmen, das neue Funktionen schneller als seine Konkurrenz fertigstellen könnte, einen großen Vorteil haben. Wir wussten, dass Lisp eine wirklich gute Sprache ist, um Software schnell zu schreiben, und serverseitige Anwendungen verstärken den Effekt der schnellen Entwicklung, da Sie Software sofort veröffentlichen können, sobald sie fertig ist.

Wenn andere Unternehmen Lisp nicht verwenden wollten, umso besser. Es könnte uns einen technologischen Vorsprung geben, und wir brauchten jede Hilfe, die wir bekommen konnten. Als wir Viaweb starteten, hatten wir keine Erfahrung in Geschäftsführung. Wir wussten nichts über Marketing, Personalbeschaffung, Kapitalbeschaffung oder Kundengewinnung. Keiner von uns hatte jemals einen richtigen Job gehabt. Das Einzige, was wir gut konnten, war Softwareentwicklung. Wir hofften, dass das uns retten würde. Jeden Vorteil, den wir in der Softwareentwicklung bekommen konnten, würden wir mitnehmen.

Man könnte also sagen, dass die Verwendung von Lisp ein Experiment war. Unsere Hypothese war, dass wenn wir unsere Software in Lisp schreiben würden, wir Funktionen schneller fertigstellen könnten als unsere Konkurrenz, und auch Dinge in unserer Software tun könnten, die sie nicht könnten. Und weil Lisp so hochrangig ist, bräuchten wir kein großes Entwicklungsteam, also wären unsere Kosten niedriger. Wenn dem so wäre, könnten wir ein besseres Produkt für weniger Geld anbieten und trotzdem Gewinn machen. Wir würden alle Nutzer bekommen, und unsere Konkurrenz würde keinen bekommen und schließlich aus dem Geschäft gehen. Das war zumindest, was wir hofften, dass passieren würde.

Was waren die Ergebnisse dieses Experiments? Etwas überraschend hat es funktioniert. Wir hatten irgendwann viele Konkurrenten, in der Größenordnung von zwanzig bis dreißig, aber keine ihrer Software konnte mit unserer konkurrieren. Wir hatten einen WYSIWYG-Online- Geschäftsaufbauer, der auf dem Server lief und sich dennoch wie eine Desktop-Anwendung anfühlte. Unsere Konkurrenz hatte CGI-Skripte. Und wir waren bei den Funktionen immer weit vor ihnen. Manchmal versuchten Konkurrenten in 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 zwei nach einer Pressemitteilung eines Konkurrenten duplizieren konnten. Bis die Journalisten, die die Pressemitteilung berichteten, an uns herantraten, hatten wir die neue Funktion auch.

Es muss unseren Konkurrenten so vorgekommen sein, als hätten wir eine Art Geheimwaffe - als würden wir ihren Enigma-Verkehr entschlüsseln oder so etwas. In Wirklichkeit hatten wir eine Geheimwaffe, aber sie war einfacher, als sie dachten. Niemand verriet uns Neuigkeiten über ihre Funktionen. Wir konnten einfach Software schneller entwickeln, als irgendjemand für möglich gehalten hätte.

Als ich etwa neun Jahre alt war, kam ich zufällig an ein Exemplar von The Day of the Jackal von Frederick Forsyth. Die Hauptfigur ist ein Auftragskiller, der beauftragt wird, den Präsidenten von Frankreich zu töten. Der Killer muss an der Polizei vorbeikommen, um in eine Wohnung zu gelangen, die auf die Route des Präsidenten blickt. Er geht direkt an ihnen vorbei, verkleidet als alter Mann mit Krücken, und sie ahnen nichts.

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

Und so, ein wenig peinlich muss ich sagen, habe ich nie öffentlich etwas über Lisp gesagt, während wir an Viaweb arbeiteten. Wir haben es nie in der Presse erwähnt, und wenn man auf unserer Website nach Lisp gesucht hätte, hätte man nur die Titel von zwei Büchern in meiner Biografie gefunden. Das war kein Zufall. Ein Start-up 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 so beibehalten.[2]

Die Leute, die unsere Technologie am besten verstanden, waren die Kunden. Sie kümmerten sich auch nicht darum, in welcher Sprache Viaweb geschrieben war, aber sie merkten, dass es wirklich gut funktionierte. Es ermöglichte ihnen, großartig aussehende Online-Shops buchstäblich in Minuten aufzubauen. Und so, hauptsächlich durch Mundpropaganda, bekamen wir 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 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 Nutzer sie jetzt haben, aber das Letzte, was ich gehört habe, waren etwa 20.000.

Das Blub-Paradox

Was ist so toll an Lisp? Und wenn Lisp so toll ist, warum benutzen es nicht alle? Das klingen wie rhetorische Fragen, aber tatsächlich haben sie einfache Antworten. Lisp ist so toll nicht wegen irgendeiner magischen Eigenschaft, die nur Anhänger sehen, sondern einfach, weil es die mächtigste Sprache ist, die es gibt. 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 werde mit einer schockierend kontroversen Aussage beginnen: Programmiersprachen unterscheiden sich in ihrer Leistungsfähigkeit.

Kaum jemand würde bestreiten, dass Hochsprachen mächtiger sind als Maschinensprache. Die meisten Programmierer würden heute zustimmen, dass man normalerweise nicht in Maschinensprache programmieren sollte. Stattdessen sollte man in einer Hochsprache programmieren und einen Compiler sie in Maschinensprache übersetzen lassen. Diese Idee ist sogar in die Hardware eingebaut: Seit den 1980er Jahren sind Befehlssätze für Compiler und nicht für menschliche Programmierer ausgelegt.

Jeder weiß, dass es ein Fehler ist, sein gesamtes Programm von Hand in Maschinensprache zu schreiben. Was weniger oft verstanden wird, ist, dass es hier ein allgemeineres Prinzip gibt: Wenn man die Wahl zwischen mehreren Sprachen hat, ist es, alles andere gleich, ein Fehler, in etwas anderem als der mächtigsten zu programmieren.[3]

Es gibt viele Ausnahmen von dieser Regel. Wenn Sie ein Programm schreiben müssen, das sehr eng mit einem Programm zusammenarbeiten muss, das in einer bestimmten Sprache geschrieben ist, kann es eine gute Idee sein, das neue Programm in derselben Sprache zu schreiben. Wenn Sie ein Programm schreiben müssen, das nur etwas sehr Einfaches tun muss, wie Zahlenverarbeitung oder Bitmanipulation, können Sie genauso gut eine weniger abstrakte Sprache verwenden, vor allem da sie möglicherweise etwas schneller sein kann. Und wenn Sie ein kurzes, wegwerfbares Programm schreiben, sind Sie möglicherweise besser daran, einfach die Sprache zu verwenden, die die besten Bibliotheksfunktionen für die Aufgabe hat. Aber im Allgemeinen wollen Sie für Anwendungssoftware die mächtigste (vernünftig 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 einem geringeren Maße, wie das Programmieren in Maschinensprache.

Sie können sehen, dass Maschinensprache sehr niedrig ist. Aber zumindest als eine Art soziale Konvention werden Hochsprachen oft alle als gleichwertig behandelt. Sie sind es nicht. Technisch gesehen bedeutet der Begriff "Hochsprache" nichts sehr Genaues. Es gibt keine Trennlinie mit Maschinensprachen auf der einen Seite und allen Hochsprachen auf der anderen Seite. Sprachen fallen entlang eines Kontinuums [4] der Abstraktheit, von den mächtigsten bis hinunter zu den 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 irgendjemand ernsthaft argumentieren, dass Cobol äquivalent in Macht zu Python 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 Schließungen zur Sprache hinzugefügt. Die meisten Perl-Hacker würden zustimmen, dass Perl 5 mächtiger ist als Perl 4. Aber sobald Sie das zugegeben haben, haben Sie zugegeben, dass eine Hochsprache mächtiger sein kann als eine andere. Und es folgt unweigerlich, dass Sie, außer in Sonderfällen, die mächtigste verwenden sollten, die Sie bekommen können.

Diese Idee wird jedoch selten bis zu ihrem Schluss verfolgt. Nach einem bestimmten Alter wechseln Programmierer nur selten freiwillig Sprachen. Welche Sprache die Leute auch gewohnt sind, sie neigen dazu, sie gerade gut genug zu finden.

Programmierer werden sehr an ihre Lieblingssprachen gebunden, und ich möchte niemanden verletzen, also werde ich diesen Punkt mit einer hypothetischen Sprache namens Blub erklären. Blub liegt genau in der Mitte des Abstraktheitskontinuums. Es ist nicht die mächtigste Sprache, aber es ist mächtiger als Cobol oder Maschinensprache.

Und tatsächlich würde unser hypothetischer Blub-Programmierer keines 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 jemand damit etwas erledigen kann. Es hat nicht einmal x (Blub-Funktion Ihrer Wahl).

Solange unser hypothetischer Blub-Programmierer in Richtung des Leistungskontinuums blickt, weiß er, dass er nach unten blickt. Sprachen, die weniger leistungsfähig sind als Blub, sind offensichtlich weniger leistungsfähig, weil ihnen ein Merkmal fehlt, das er gewohnt ist. Aber wenn unser hypothetischer Blub-Programmierer in die andere Richtung, nach oben auf dem Leistungskontinuum, blickt, erkennt er nicht, dass er nach oben blickt. Was er sieht, sind lediglich seltsame Sprachen. Er betrachtet sie wahrscheinlich als in etwa gleichwertig in Bezug auf die Leistungsfähigkeit wie Blub, aber mit all diesem anderen haarigen Zeug, das auch noch dazukommt. Blub ist für ihn gut genug, denn er denkt in Blub.

Wenn wir jedoch zum Standpunkt eines Programmierers wechseln, der eine der Sprachen höher auf dem Leistungskontinuum verwendet, stellen wir fest, dass er seinerseits auf Blub herabblickt. Wie kann man in Blub etwas erledigen? Es hat nicht einmal y.

Durch Induktion sind die einzigen Programmierer in der Lage, alle Leistungsunterschiede zwischen den verschiedenen Sprachen zu erkennen, diejenigen, die die mächtigste Sprache verstehen. (Dies ist wahrscheinlich das, was Eric Raymond meinte, wenn er sagte, dass Lisp Sie zu einem besseren Programmierer macht.) Man kann den Meinungen der anderen nicht trauen, wegen des Blub-Paradoxons: Sie sind mit der Sprache zufrieden, die sie zufällig verwenden, weil sie ihr Denken über Programme bestimmt.

Ich weiß das aus eigener Erfahrung als High-School-Kind, das 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 über alles, was ich überblickte.

Die fünf Sprachen, die Eric Raymond Hackern empfiehlt, befinden sich an verschiedenen Punkten auf dem Leistungskontinuum. Wo sie im Verhältnis zueinander liegen, ist ein sensibles Thema. Was ich sagen werde, ist, dass ich denke, dass Lisp an der Spitze steht. Und um diese Behauptung zu unterstützen, werde ich Ihnen von einer 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, das Makro genannt wird. Aber Lisp-Makros sind einzigartig. Und glauben Sie es oder nicht, was sie tun, hängt mit den Klammern zusammen. Die Entwickler von Lisp haben diese vielen Klammern in der Sprache 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 nicht in dem trivialen Sinne, dass die Quelldateien Zeichen enthalten und Zeichenketten einer der unterstützten Datentypen der Sprache sind. Der Lisp-Code, nachdem er vom Parser gelesen wurde, besteht aus Datenstrukturen, die Sie durchlaufen können.

Wenn Sie verstehen, wie Compiler funktionieren, ist das, was wirklich vor sich geht, nicht so sehr, dass Lisp eine seltsame Syntax hat, sondern dass Lisp überhaupt keine Syntax hat. Sie schreiben Programme in den Parserbäumen, die innerhalb des Compilers erzeugt werden, wenn andere Sprachen geparst werden. Aber diese Parserbäume sind für Ihre Programme voll zugänglich. Sie können Programme schreiben, die sie manipulieren. In Lisp werden diese Programme Makros genannt. Es sind Programme, die Programme schreiben.

[1] [2] [3] [4] [5]

Programme, die Programme schreiben? Wann würde man das jemals wollen? Nicht sehr oft, wenn man in Cobol denkt. Ständig, wenn man in Lisp denkt. Es wäre hier praktisch, wenn ich ein Beispiel für eine leistungsfähige Makro geben und sagen könnte: Da! Was ist damit? Aber wenn ich das täte, würde es für jemanden, der Lisp nicht kennt, wie Kauderwelsch aussehen; es gibt 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, so schnell wie möglich voranzukommen, und selbst da bin ich erst auf Seite 160 zu den Makros gekommen.

Aber ich denke, 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 schwerer zu schreiben als gewöhnliche Lisp-Funktionen, und es gilt als schlechter Stil, sie zu verwenden, wenn sie nicht unbedingt nötig sind. Jedes Makro in diesem Code ist also deshalb da, weil es sein muss. Das bedeutet, dass mindestens 20-25% dieses Programms Dinge tun, die man in keiner anderen Sprache leicht machen kann. Wie skeptisch der Blub-Programmierer auch immer gegenüber meinen Behauptungen über die geheimnisvollen Kräfte von Lisp sein mag, das sollte ihn neugierig machen. Wir haben diesen Code nicht zu unserem Vergnügen geschrieben. Wir waren ein winziges Start-up und haben so hart wie möglich programmiert, um technische Barrieren zwischen uns und unseren Konkurrenten aufzubauen.

Ein misstrauischer Mensch könnte anfangen, sich zu fragen, ob es hier vielleicht einen Zusammenhang gibt. Ein großer Teil unseres Codes tat Dinge, die in anderen Sprachen sehr schwer zu machen sind. Die daraus resultierende Software konnte Dinge, die die Software unserer Konkurrenz nicht konnte. Vielleicht gab es da eine Art Verbindung. Ich ermutige Sie, diesem Faden zu folgen. Vielleicht steckt in diesem alten Mann, der auf Krücken dahinschleicht, mehr, als auf den ersten Blick zu sehen ist.

Aikido für Start-ups

Aber ich erwarte nicht, irgendjemanden (über 25) dazu zu bringen, Lisp zu lernen. Der Zweck dieses Artikels ist nicht, die Meinung irgendjemandes zu ändern, sondern Menschen, die bereits daran interessiert sind, Lisp zu verwenden - Menschen, die wissen, dass Lisp eine leistungsfähige Sprache ist, aber sich Sorgen machen, weil sie nicht weit verbreitet ist - zu beruhigen. In einer Wettbewerbssituation ist das ein Vorteil. Die Macht von Lisp wird durch die Tatsache verstärkt, dass Ihre Konkurrenz sie nicht versteht.

Wenn Sie daran denken, Lisp in einem Start-up einzusetzen, müssen Sie sich nicht darum sorgen, dass es nicht weit verbreitet ist. Sie sollten hoffen, dass es so bleibt. Und das ist wahrscheinlich auch so. Es ist die Natur von Programmiersprachen, dass die meisten Menschen mit dem zufrieden sind, was sie gerade verwenden. Die Hardware ändert sich so viel schneller als persönliche Gewohnheiten, dass die Programmierpraktiken in der Regel 10 bis 20 Jahre hinter dem Prozessor hinterherhinken. An Orten wie dem MIT schrieben sie in den frühen 1960er Jahren Programme in Hochsprachen, aber viele Unternehmen fuhren fort, bis in die 1980er Jahre Maschinencode zu schreiben. Ich wette, dass viele Leute bis dahin Maschinencode geschrieben haben, bis der Prozessor, wie ein eiliger Barkeeper, der nach Hause will, sie schließlich hinauswarf, indem er auf einen RISC-Befehlssatz umstellte.

Normalerweise ändern sich Technologien schnell. Aber Programmiersprachen sind anders: Programmiersprachen sind nicht nur Technologie, sondern auch das, worüber Programmierer nachdenken. Sie sind zur Hälfte Technologie und zur Hälfte Religion.[6] Und so bewegt sich die Mediansprache, also die Sprache, die der Median-Programmierer verwendet, so langsam wie ein Eisberg. Die Garbage Collection, die Lisp um 1960 eingeführt hat, gilt jetzt weithin als etwas Gutes. Die Laufzeittypprüfung, ebenfalls, gewinnt an Popularität. Lexikalische Schließungen, die Lisp Anfang der 1970er Jahre eingeführt hat, sind jetzt gerade so auf dem Radar. Makros, die Lisp Mitte der 1960er Jahre eingeführt hat, sind immer noch terra incognita.

Offensichtlich hat die Mediansprache 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 Praktizierender des Aikido, gegen Ihre Gegner einsetzen können.

Wenn Sie für ein großes Unternehmen arbeiten, wird das nicht einfach sein. Sie werden große Mühe haben, den spitzköpfigen Chef davon zu überzeugen, Dinge in Lisp zu bauen, wenn er gerade in der Zeitung gelesen hat, dass eine andere Sprache, wie vor zwanzig Jahren Ada, dabei ist, die Welt zu erobern. Aber wenn Sie für ein Start-up arbeiten, das noch keine spitzköpfigen Chefs hat, können Sie, wie wir es getan haben, den Blub-Paradoxon zu Ihrem Vorteil nutzen: Sie können Technologie einsetzen, die Ihre Konkurrenz, die unbeweglich an der Mediansprache klebt, niemals erreichen kann.

Wenn Sie jemals für ein Start-up arbeiten, hier ist ein praktischer Tipp, um Konkurrenten zu bewerten. Lesen Sie ihre Stellenanzeigen. Alles andere auf ihrer Website mag Stockfotos oder das Äquivalent in Prosa 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 gearbeitet haben, habe ich viele Stellenbeschreibungen gelesen. Scheinbar tauchte jeden Monat ein neuer Konkurrent aus dem Nichts auf. Das Erste, was ich tat, nachdem ich überprüft hatte, ob sie eine funktionierende Online-Demo hatten, war, einen Blick auf ihre Stellenanzeigen zu werfen. Nach ein paar Jahren konnte ich sagen, welche Unternehmen man sich ansehen musste und welche nicht. Je mehr IT-Flavor die Stellenbeschreibungen hatten, desto ungefährlicher war das Unternehmen. Am sichersten waren die, die Oracle-Erfahrung suchten. Um die musste man sich keine Sorgen machen. Man war auch sicher, wenn sie sagten, sie wollten C++- oder Java-Entwickler. Wenn sie Perl- oder Python-Programmierer suchten, war das schon beängstigend - das klingt nach einem Unternehmen, in dem zumindest die technische Seite von echten Hackern geleitet wird. Wenn ich jemals eine Stellenausschreibung für Lisp-Hacker gesehen hätte, hätte mich das wirklich beunruhigt.

Anmerkungen

[1] Viaweb hatte anfangs zwei Teile: den Editor, der in Lisp geschrieben war und von den Leuten zum Erstellen ihrer Websites verwendet wurde, und das Bestellsystem, das in C geschrieben war und Bestellungen abwickelte. Die erste Version bestand hauptsächlich aus Lisp, weil das Bestellsystem klein war. Später fügten wir zwei weitere Module hinzu, einen Bildgenerator, der in C geschrieben war, und einen Back-Office-Manager, der hauptsächlich in Perl geschrieben war.

Im Januar 2003 veröffentlichte Yahoo eine neue Version des Editors, der in C++ und Perl geschrieben ist. Es ist 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 seitengenierenden Vorlagen sind nach meinem Wissen immer noch Lisp-Code. (Siehe Greenspuns Zehntes Gesetz.)

[2] Robert Morris sagt, ich hätte nicht geheim sein müssen, denn selbst wenn unsere Konkurrenz gewusst hätte, dass wir Lisp verwendeten, hätten sie nicht verstanden, warum: "Wenn sie so schlau wären, würden sie schon in 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, lässt sich vielleicht nicht formal definieren, aber man könnte 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 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, denn man kann das in B wahrscheinlich durch eine Unterprogrammfunktion ersetzen. Aber wenn A Rekursion unterstützt und B nicht, ist das wahrscheinlich keine Sache, die man durch das Schreiben von Bibliotheksfunktionen beheben kann.

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

[5] Es ist etwas irreführend, Makros als eigenständiges Merkmal zu behandeln. In der Praxis wird ihre Nützlichkeit durch andere Lisp-Funktionen wie lexikalische Schließungen und Rest-Parameter erheblich gesteigert.

[6] Infolgedessen nehmen Vergleiche von Programmiersprachen entweder die Form von Glaubenskriegen an oder von Lehrbüchern für Studenten, die so entschieden neutral sind, dass sie eigentlich Werke der Anthropologie sind. Menschen, die ihren Frieden schätzen oder Tenure anstreben, meiden dieses Thema. Aber die Frage ist nur zur Hälfte eine Glaubensfrage; es gibt etwas dort, das es wert ist zu untersuchen, vor allem wenn man neue Sprachen entwerfen möchte.