BELIEBT SEIN

Mai 2001

(Dieser Artikel wurde als eine Art Geschäftsplan für eine neue Sprache geschrieben. Deshalb fehlt (weil es als selbstverständlich angesehen wird) das wichtigste Merkmal einer guten Programmiersprache: sehr mächtige Abstraktionen.)

Ein Freund von mir erzählte einmal einem angesehenen Experten für Betriebssysteme, dass er eine wirklich gute Programmiersprache entwerfen wollte. Der Experte sagte ihm, dass es Zeitverschwendung wäre, dass Programmiersprachen nicht aufgrund ihrer Meriten beliebt oder unpopulär werden, und dass es egal sei, wie gut seine Sprache war, niemand sie benutzen würde. Zumindest war das das, was mit der Sprache ihm passiert war.

Was macht eine Sprache beliebt? Verdienen beliebte Sprachen ihre Beliebtheit? Ist es wert, zu versuchen, eine gute Programmiersprache zu definieren? Wie würde man das tun?

Ich denke, die Antworten auf diese Fragen können gefunden werden, indem man sich Hacker ansieht und lernt, was sie wollen. Programmiersprachen sind für Hacker, und eine Programmiersprache ist gut als Programmiersprache (im Gegensatz zu, sagen wir, einer Übung in denotationaler Semantik oder Compiler-Design), wenn und nur wenn Hacker sie mögen.

1 Die Mechanik der Beliebtheit

Es ist sicherlich wahr, dass die meisten Menschen Programmiersprachen nicht einfach aufgrund ihrer Meriten wählen. Die meisten Programmierer werden von jemand anderem gesagt, welche Sprache sie verwenden sollen. Und doch denke ich, dass der Einfluss solcher externer Faktoren auf die Beliebtheit von Programmiersprachen nicht so groß ist, wie manchmal gedacht wird. Ich denke, ein größeres Problem ist, dass die Vorstellung eines Hackers von einer guten Programmiersprache nicht die gleiche ist wie die der meisten Sprachdesigner.

Zwischen den beiden zählt die Meinung des Hackers. Programmiersprachen sind keine Theoreme. Sie sind Werkzeuge, die für Menschen entworfen wurden, und sie müssen so gestaltet sein, dass sie menschlichen Stärken und Schwächen entsprechen, so wie Schuhe für menschliche Füße entworfen werden müssen. Wenn ein Schuh drückt, wenn man ihn anzieht, ist es ein schlechter Schuh, egal wie elegant er als Skulptur sein mag.

Es mag sein, dass die Mehrheit der Programmierer nicht zwischen einer guten und einer schlechten Sprache unterscheiden kann. Aber das ist bei jedem anderen Werkzeug nicht anders. Das bedeutet nicht, dass es Zeitverschwendung ist, zu versuchen, eine gute Sprache zu entwerfen. Experten-Hacker können eine gute Sprache erkennen, wenn sie eine sehen, und sie werden sie benutzen. Experten-Hacker sind eine winzige Minderheit, zugegeben, aber diese winzige Minderheit schreibt die ganze gute Software, und ihr Einfluss ist so groß, dass der Rest der Programmierer dazu neigen wird, die Sprache zu verwenden, die sie benutzen. Oft ist es in der Tat nicht nur Einfluss, sondern Befehl: oft sind die Experten-Hacker genau die Menschen, die, als ihre Chefs oder Fakultätsberater, den anderen Programmierern sagen, welche Sprache sie verwenden sollen.

Die Meinung der Experten-Hacker ist nicht die einzige Kraft, die die relative Beliebtheit von Programmiersprachen bestimmt — auch Legacy-Software (Cobol) und Hype (Ada, Java) spielen eine Rolle — aber ich denke, es ist die mächtigste Kraft auf lange Sicht. Angesichts einer anfänglichen kritischen Masse und genügend Zeit wird eine Programmiersprache wahrscheinlich etwa so beliebt, wie sie es verdient. Und Beliebtheit trennt gute Sprachen weiter von schlechten, denn das Feedback von echten, lebenden Benutzern führt immer zu Verbesserungen. Schauen Sie sich an, wie sehr sich jede beliebte Sprache im Laufe ihrer Existenz verändert hat. Perl und Fortran sind extreme Fälle, aber selbst Lisp hat sich stark verändert. Lisp 1.5 hatte zum Beispiel keine Makros; diese entwickelten sich später, nachdem Hacker am MIT ein paar Jahre Lisp verwendet hatten, um echte Programme zu schreiben. [1]

Ob eine Sprache gut sein muss, um beliebt zu sein, oder nicht, ich denke, eine Sprache muss beliebt sein, um gut zu sein. Und sie muss beliebt bleiben, um gut zu bleiben. Der Stand der Technik in Programmiersprachen steht nicht still. Und doch sind die Lisps, die wir heute haben, immer noch ziemlich genau das, was sie am MIT in den mittleren 1980er Jahren hatten, denn das ist das letzte Mal, dass Lisp eine ausreichend große und anspruchsvolle Benutzerbasis hatte.

Natürlich müssen Hacker von einer Sprache wissen, bevor sie sie benutzen können. Woher sollen sie hören? Von anderen Hackern. Aber es muss eine anfängliche Gruppe von Hackern geben, die die Sprache benutzt, damit andere überhaupt davon hören. Ich frage mich, wie groß diese Gruppe sein muss; wie viele Benutzer bilden eine kritische Masse? Aus dem Stegreif würde ich sagen zwanzig. Wenn eine Sprache zwanzig separate Benutzer hätte, was bedeutet, dass zwanzig Benutzer unabhängig entschieden haben, sie zu verwenden, würde ich sie als echt betrachten.

Dorthin zu gelangen, kann nicht einfach sein. Ich wäre nicht überrascht, wenn es schwieriger ist, von null auf zwanzig zu kommen, als von zwanzig auf tausend. Der beste Weg, um diese anfänglichen zwanzig Benutzer zu gewinnen, ist wahrscheinlich, ein Trojanisches Pferd zu verwenden: den Menschen eine Anwendung zu geben, die sie wollen, die zufällig in der neuen Sprache geschrieben ist.

2 Externe Faktoren

Lassen Sie uns damit beginnen, einen externen Faktor anzuerkennen, der die Beliebtheit einer Programmiersprache beeinflusst. Um beliebt zu werden, muss eine Programmiersprache die Skriptsprache eines beliebten Systems sein. Fortran und Cobol waren die Skriptsprache der frühen IBM-Mainframes. C war die Skriptsprache von Unix, und später war es Perl. Tcl ist die Skriptsprache von Tk. Java und Javascript sollen die Skriptsprache von Webbrowsern sein.

Lisp ist keine massiv beliebte Sprache, weil es nicht die Skriptsprache eines massiv beliebten Systems ist. Welche Beliebtheit es noch hat, stammt aus den 1960er und 1970er Jahren, als es die Skriptsprache des MIT war. Viele der großartigen Programmierer dieser Zeit waren irgendwann mit dem MIT verbunden. Und in den frühen 1970er Jahren, vor C, war der Dialekt von Lisp am MIT, genannt MacLisp, eine der einzigen Programmiersprachen, die ein ernsthafter Hacker verwenden wollte.

Heute ist Lisp die Skriptsprache von zwei mäßig beliebten Systemen, Emacs und Autocad, und aus diesem Grund vermute ich, dass die meisten der heute geschriebenen Lisp-Programme in Emacs Lisp oder AutoLisp geschrieben werden.

Programmiersprachen existieren nicht isoliert. Hacken ist ein transitives Verb — Hacker hacken normalerweise etwas — und in der Praxis werden Sprachen relativ zu dem beurteilt, was sie zum Hacken verwenden. Wenn Sie also eine beliebte Sprache entwerfen wollen, müssen Sie entweder mehr als nur eine Sprache anbieten oder Ihre Sprache so gestalten, dass sie die Skriptsprache eines bestehenden Systems ersetzt.

Common Lisp ist unpopulär, partly weil es ein Waise ist. Es kam ursprünglich mit einem System zum Hacken: der Lisp-Maschine. Aber Lisp-Maschinen (neben parallelen Computern) wurden von der zunehmenden Leistung allgemeiner Prozessoren in den 1980er Jahren überrollt. Common Lisp hätte beliebt bleiben können, wenn es eine gute Skriptsprache für Unix gewesen wäre. Es ist leider eine abscheulich schlechte.

Eine Möglichkeit, diese Situation zu beschreiben, ist zu sagen, dass eine Sprache nicht nach ihren eigenen Meriten beurteilt wird. Eine andere Sichtweise ist, dass eine Programmiersprache wirklich keine Programmiersprache ist, es sei denn, sie ist auch die Skriptsprache von etwas. Dies scheint nur unfair zu sein, wenn es als Überraschung kommt. Ich denke, es ist nicht unfairer, als zu erwarten, dass eine Programmiersprache, sagen wir, eine Implementierung hat. Es ist einfach Teil dessen, was eine Programmiersprache ist.

Eine Programmiersprache benötigt natürlich eine gute Implementierung, und diese muss kostenlos sein. Unternehmen werden für Software bezahlen, aber einzelne Hacker nicht, und es sind die Hacker, die Sie anziehen müssen.

Eine Sprache muss auch ein Buch darüber haben. Das Buch sollte dünn, gut geschrieben und voller guter Beispiele sein. K&R ist hier das Ideal. Im Moment würde ich fast sagen, dass eine Sprache ein Buch veröffentlicht haben muss, das von O'Reilly herausgegeben wurde. Das wird zum Test dafür, ob es für Hacker von Bedeutung ist.

Es sollte auch eine Online-Dokumentation geben. Tatsächlich kann das Buch als Online-Dokumentation beginnen. Aber ich denke nicht, dass physische Bücher bereits überholt sind. Ihr Format ist praktisch, und die de facto Zensur, die von Verlegern auferlegt wird, ist ein nützlicher, wenn auch unvollkommener Filter. Buchhandlungen sind einer der wichtigsten Orte, um über neue Sprachen zu lernen.

3 Kürze

Angesichts der Tatsache, dass Sie die drei Dinge bereitstellen können, die jede Sprache benötigt — eine kostenlose Implementierung, ein Buch und etwas zum Hacken — wie machen Sie eine Sprache, die Hacker mögen werden?

Eine Sache, die Hacker mögen, ist Kürze. Hacker sind faul, auf die gleiche Weise, wie Mathematiker und modernistische Architekten faul sind: sie hassen alles Überflüssige. Es wäre nicht weit von der Wahrheit entfernt zu sagen, dass ein Hacker, der kurz davor ist, ein Programm zu schreiben, entscheidet, welche Sprache er verwenden will, zumindest unbewusst, basierend auf der Gesamtzahl der Zeichen, die er tippen muss. Wenn das nicht genau so ist, wie Hacker denken, würde es einem Sprachdesigner gut tun, so zu handeln, als ob es so wäre.

Es ist ein Fehler, den Benutzer mit langatmigen Ausdrücken zu verwöhnen, die so gestaltet sind, dass sie Englisch ähneln. Cobol ist berüchtigt für diesen Fehler. Ein Hacker würde es als eine Beleidigung seiner Intelligenz und als eine Sünde gegen Gott betrachten, gebeten zu werden, zu schreiben

add x to y giving z

anstatt

z = x+y.

Es wurde manchmal gesagt, dass Lisp first und rest anstelle von car und cdr verwenden sollte, weil es die Programme leichter lesbar machen würde. Vielleicht für die ersten paar Stunden. Aber ein Hacker kann schnell genug lernen, dass car das erste Element einer Liste bedeutet und cdr den Rest. first und rest zu verwenden, bedeutet 50 % mehr Tippen. Und sie sind auch unterschiedlich lang, was bedeutet, dass die Argumente nicht übereinstimmen, wenn sie aufgerufen werden, wie car und cdr oft in aufeinanderfolgenden Zeilen sind. Ich habe festgestellt, dass es sehr wichtig ist, wie der Code auf der Seite ausgerichtet ist. Ich kann Lisp-Code kaum lesen, wenn er in einer variablen Breite Schriftart gesetzt ist, und Freunde sagen, dass dies auch für andere Sprachen zutrifft.

Kürze ist ein Bereich, in dem stark typisierte Sprachen verlieren. Bei gleichen Bedingungen möchte niemand ein Programm mit einer Reihe von Deklarationen beginnen. Alles, was implizit sein kann, sollte es auch sein.

Die einzelnen Token sollten ebenfalls kurz sein. Perl und Common Lisp stehen in dieser Frage an entgegengesetzten Polen. Perl-Programme können fast kryptisch dicht sein, während die Namen der eingebauten Common Lisp-Operatoren komisch lang sind. Die Designer von Common Lisp haben wahrscheinlich erwartet, dass die Benutzer Texteditoren haben, die diese langen Namen für sie eintippen. Aber die Kosten eines langen Namens sind nicht nur die Kosten des Eintippens. Es gibt auch die Kosten des Lesens und die Kosten des Platzes, den er auf Ihrem Bildschirm einnimmt.

4 Hackbarkeit

Es gibt eine Sache, die für einen Hacker wichtiger ist als Kürze: die Fähigkeit, das zu tun, was man will. In der Geschichte der Programmiersprachen wurde überraschend viel Aufwand darauf verwendet, Programmierer daran zu hindern, Dinge zu tun, die als unangemessen gelten. Dies ist ein gefährlich anmaßender Plan. Wie kann der Sprachdesigner wissen, was der Programmierer tun muss? Ich denke, Sprachdesigner würden besser daran tun, ihren Zielbenutzer als Genie zu betrachten, das Dinge tun muss, die sie nie vorhergesehen haben, anstatt als einen Tollpatsch, der vor sich selbst geschützt werden muss. Der Tollpatsch wird sich ohnehin ins Eigene schießen. Sie können ihn davon abhalten, auf Variablen in einem anderen Paket zuzugreifen, aber Sie können ihn nicht davon abhalten, ein schlecht gestaltetes Programm zu schreiben, um das falsche Problem zu lösen, und dafür ewig zu brauchen.

Gute Programmierer wollen oft gefährliche und unschöne Dinge tun. Mit unschön meine ich Dinge, die hinter der semantischen Fassade versteckt sind, die die Sprache zu präsentieren versucht: sich Zugriff auf die interne Darstellung einer hochrangigen Abstraktion zu verschaffen, zum Beispiel. Hacker hacken gerne, und Hacken bedeutet, in Dinge einzudringen und den ursprünglichen Designer zu hinterfragen.

Lassen Sie sich hinterfragen. Wenn Sie ein Werkzeug herstellen, verwenden die Menschen es auf Weisen, die Sie nicht beabsichtigt haben, und das gilt besonders für ein hochgradig artikuliertes Werkzeug wie eine Programmiersprache. Viele Hacker werden wollen, Ihr semantisches Modell auf eine Weise zu optimieren, die Sie sich nie vorgestellt haben. Ich sage, lassen Sie sie; geben Sie dem Programmierer Zugang zu so vielen internen Dingen, wie Sie können, ohne die Laufzeitsysteme wie den Garbage Collector zu gefährden.

In Common Lisp wollte ich oft durch die Felder einer Struktur iterieren — um Referenzen auf ein gelöschtes Objekt zu entfernen, zum Beispiel, oder um Felder zu finden, die nicht initialisiert sind. Ich weiß, dass die Strukturen darunter nur Vektoren sind. Und doch kann ich keine allgemeine Funktion schreiben, die ich auf jede Struktur anwenden kann. Ich kann nur auf die Felder nach Namen zugreifen, weil das bedeutet, was eine Struktur sein soll.

Ein Hacker möchte vielleicht nur ein oder zwei Mal in einem großen Programm das beabsichtigte Modell untergraben. Aber was für einen Unterschied es macht, dies tun zu können. Und es könnte mehr als nur eine Frage der Problemlösung sein. Es gibt auch eine Art von Vergnügen dabei. Hacker teilen das geheime Vergnügen des Chirurgen, in grobe Innereien zu pokeln, das geheime Vergnügen des Teenagers, Pickel auszudrücken. [2] Für Jungen, zumindest, sind bestimmte Arten von Schrecken faszinierend. Das Maxim-Magazin veröffentlicht jährlich einen Band mit Fotografien, der eine Mischung aus Pin-ups und grausamen Unfällen enthält. Sie wissen, wer ihr Publikum ist.

Historisch gesehen war Lisp gut darin, Hackern ihren Willen zu lassen. Die politische Korrektheit von Common Lisp ist eine Abweichung. Frühe Lisps ließen Sie an alles herankommen. Ein gutes Stück dieses Geistes ist glücklicherweise in Makros erhalten geblieben. Was für eine wunderbare Sache, willkürliche Transformationen am Quellcode vornehmen zu können.

Klassische Makros sind ein echtes Werkzeug für Hacker — einfach, mächtig und gefährlich. Es ist so einfach zu verstehen, was sie tun: Sie rufen eine Funktion mit den Argumenten der Makros auf, und was auch immer sie zurückgibt, wird anstelle des Makroaufrufs eingefügt. Hygienische Makros verkörpern das gegenteilige Prinzip. Sie versuchen, Sie davor zu schützen, zu verstehen, was sie tun. Ich habe noch nie gehört, dass hygienische Makros in einem Satz erklärt wurden. Und sie sind ein klassisches Beispiel für die Gefahren, zu entscheiden, was Programmierer wollen dürfen. Hygienische Makros sollen mich unter anderem vor der Variablenübernahme schützen, aber die Variablenübernahme ist genau das, was ich in einigen Makros will.

Eine wirklich gute Sprache sollte sowohl sauber als auch schmutzig sein: sauber entworfen, mit einem kleinen Kern von gut verstanden und hochgradig orthogonalen Operatoren, aber schmutzig im Sinne, dass sie Hackern ihren Willen lässt. C ist so. Das waren auch die frühen Lisps. Eine echte Hacker-Sprache wird immer einen leicht schmuddeligen Charakter haben.

Eine gute Programmiersprache sollte Merkmale haben, die die Art von Menschen, die den Ausdruck "Software-Engineering" verwenden, den Kopf schütteln lassen. Am anderen Ende des Kontinuums stehen Sprachen wie Ada und Pascal, Modelle der Anständigkeit, die gut zum Lehren sind und nicht viel mehr.

5 Wegwerfprogramme

Um für Hacker attraktiv zu sein, muss eine Sprache gut zum Schreiben der Arten von Programmen geeignet sein, die sie schreiben wollen. Und das bedeutet, vielleicht überraschend, dass sie gut zum Schreiben von Wegwerfprogrammen sein muss.

Ein Wegwerfprogramm ist ein Programm, das Sie schnell für eine bestimmte Aufgabe schreiben: ein Programm, um eine bestimmte Systemadministrationsaufgabe zu automatisieren, oder um Testdaten für eine Simulation zu generieren, oder um Daten von einem Format in ein anderes zu konvertieren. Das Überraschende an Wegwerfprogrammen ist, dass sie, wie die "temporären" Gebäude, die an so vielen amerikanischen Universitäten während des Zweiten Weltkriegs gebaut wurden, oft nicht weggeworfen werden. Viele entwickeln sich zu echten Programmen, mit echten Funktionen und echten Benutzern.

Ich habe das Gefühl, dass die besten großen Programme so beginnen, anstatt von Anfang an groß entworfen zu werden, wie der Hoover Staudamm. Es ist beängstigend, etwas Großes von Grund auf zu bauen. Wenn Menschen ein Projekt übernehmen, das zu groß ist, werden sie überwältigt. Das Projekt gerät entweder ins Stocken, oder das Ergebnis ist steril und hölzern: ein Einkaufszentrum anstatt eines echten Stadtzentrums, Brasilia anstelle von Rom, Ada anstatt C.

Eine andere Möglichkeit, ein großes Programm zu erhalten, besteht darin, mit einem Wegwerfprogramm zu beginnen und es ständig zu verbessern. Dieser Ansatz ist weniger entmutigend, und das Design des Programms profitiert von der Evolution. Ich denke, wenn man sich umschaut, wird sich herausstellen, dass dies der Weg ist, wie die meisten großen Programme entwickelt wurden. Und die, die sich so entwickelt haben, sind wahrscheinlich immer noch in der Sprache geschrieben, in der sie ursprünglich geschrieben wurden, denn es ist selten, dass ein Programm portiert wird, es sei denn aus politischen Gründen. Und so, paradoxerweise, wenn Sie eine Sprache entwickeln wollen, die für große Systeme verwendet wird, müssen Sie sie gut zum Schreiben von Wegwerfprogrammen machen, denn dort kommen große Systeme her.

Perl ist ein auffälliges Beispiel für diese Idee. Es wurde nicht nur zum Schreiben von Wegwerfprogrammen entworfen, sondern war praktisch selbst ein Wegwerfprogramm. Perl begann als eine Sammlung von Dienstprogrammen zur Erstellung von Berichten und entwickelte sich erst zu einer Programmiersprache, als die Wegwerfprogramme, die die Leute darin schrieben, größer wurden. Es war erst mit Perl 5 (wenn überhaupt), dass die Sprache für das Schreiben ernsthafter Programme geeignet war, und doch war sie bereits massiv beliebt.

Was macht eine Sprache gut für Wegwerfprogramme? Zunächst einmal muss sie leicht verfügbar sein. Ein Wegwerfprogramm ist etwas, das Sie erwarten, in einer Stunde zu schreiben. Daher muss die Sprache wahrscheinlich bereits auf dem Computer installiert sein, den Sie verwenden. Es kann nicht etwas sein, das Sie installieren müssen, bevor Sie es verwenden. Es muss da sein. C war da, weil es mit dem Betriebssystem kam. Perl war da, weil es ursprünglich ein Werkzeug für Systemadministratoren war, und Ihrer hatte es bereits installiert.

Verfügbar zu sein bedeutet jedoch mehr, als installiert zu sein. Eine interaktive Sprache mit einer Befehlszeilenschnittstelle ist verfügbarer als eine, die Sie separat kompilieren und ausführen müssen. Eine beliebte Programmiersprache sollte interaktiv sein und schnell starten.

Eine weitere Sache, die Sie in einem Wegwerfprogramm wollen, ist Kürze. Kürze ist für Hacker immer attraktiv, und nie mehr als in einem Programm, das sie erwarten, in einer Stunde zu erstellen.

6 Bibliotheken

Natürlich ist das Ultimative in der Kürze, das Programm bereits für Sie geschrieben zu haben und es lediglich aufzurufen. Und das führt uns zu dem, was ich für ein zunehmend wichtiges Merkmal von Programmiersprachen halte: Bibliotheksfunktionen. Perl gewinnt, weil es große Bibliotheken zur Manipulation von Zeichenfolgen hat. Diese Klasse von Bibliotheksfunktionen ist besonders wichtig für Wegwerfprogramme, die oft ursprünglich zum Konvertieren oder Extrahieren von Daten geschrieben werden. Viele Perl-Programme beginnen wahrscheinlich einfach als ein paar Bibliotheksaufrufe, die zusammengefügt werden.

Ich denke, viele der Fortschritte, die in den nächsten fünfzig Jahren in Programmiersprachen geschehen werden, werden mit Bibliotheksfunktionen zu tun haben. Ich denke, zukünftige Programmiersprachen werden Bibliotheken haben, die so sorgfältig entworfen sind wie die Kernsprache. Das Design von Programmiersprachen wird nicht darum gehen, ob Sie Ihre Sprache stark oder schwach typisiert, objektorientiert oder funktional gestalten, oder was auch immer, sondern darum, wie man großartige Bibliotheken entwirft. Die Art von Sprachdesignern, die gerne darüber nachdenken, wie man Typsysteme entwirft, wird bei dieser Vorstellung zusammenzucken. Es ist fast so, als würde man Anwendungen schreiben! Schade. Sprachen sind für Programmierer, und Bibliotheken sind das, was Programmierer brauchen.

Es ist schwierig, gute Bibliotheken zu entwerfen. Es ist nicht einfach eine Frage des Schreibens von viel Code. Sobald die Bibliotheken zu groß werden, kann es manchmal länger dauern, die Funktion zu finden, die Sie benötigen, als den Code selbst zu schreiben. Bibliotheken müssen mit einer kleinen Menge orthogonaler Operatoren entworfen werden, genau wie die Kernsprache. Es sollte möglich sein, dass der Programmierer erraten kann, welcher Bibliotheksaufruf das tut, was er braucht.

Bibliotheken sind ein Bereich, in dem Common Lisp hinterherhinkt. Es gibt nur rudimentäre Bibliotheken zur Manipulation von Zeichenfolgen und fast keine, um mit dem Betriebssystem zu kommunizieren. Aus historischen Gründen versucht Common Lisp, so zu tun, als ob das Betriebssystem nicht existiert. Und weil Sie nicht mit dem Betriebssystem kommunizieren können, ist es unwahrscheinlich, dass Sie ein ernsthaftes Programm nur mit den eingebauten Operatoren in Common Lisp schreiben können. Sie müssen auch einige implementierungsspezifische Hacks verwenden, und in der Praxis neigen diese dazu, Ihnen nicht alles zu geben, was Sie wollen. Hacker würden Lisp viel höher schätzen, wenn Common Lisp mächtige Zeichenfolgenbibliotheken und gute OS-Unterstützung hätte.

7 Syntax

Könnte eine Sprache mit Lispers Syntax, oder genauer gesagt, dem Mangel an Syntax, jemals beliebt werden? Ich kenne die Antwort auf diese Frage nicht. Ich denke jedoch, dass Syntax nicht der Hauptgrund ist, warum Lisp derzeit nicht beliebt ist. Common Lisp hat schlimmere Probleme als unbekannte Syntax. Ich kenne mehrere Programmierer, die mit der Präfix-Syntax vertraut sind und dennoch standardmäßig Perl verwenden, weil es mächtige Zeichenfolgenbibliotheken hat und mit dem Betriebssystem kommunizieren kann.

Es gibt zwei mögliche Probleme mit der Präfixnotation: dass sie unbekannt für Programmierer ist und dass sie nicht dicht genug ist. Die allgemeine Meinung in der Lisp-Welt ist, dass das erste Problem das wirkliche ist. Ich bin mir da nicht so sicher. Ja, die Präfixnotation bringt gewöhnliche Programmierer in Panik. Aber ich denke nicht, dass die Meinungen gewöhnlicher Programmierer wichtig sind. Sprachen werden aufgrund dessen, was Experten-Hacker von ihnen halten, beliebt oder unpopulär, und ich denke, dass Experten-Hacker mit der Präfixnotation umgehen könnten. Die Perl-Syntax kann ziemlich unverständlich sein, aber das hat der Beliebtheit von Perl nicht im Wege gestanden. Wenn überhaupt, hat es vielleicht dazu beigetragen, einen Perl-Kult zu fördern.

Ein ernsthafteres Problem ist die Diffusität der Präfixnotation. Für Experten-Hacker ist das wirklich ein Problem. Niemand möchte (aref a x y) schreiben, wenn er a[x,y] schreiben könnte.

In diesem speziellen Fall gibt es einen Weg, um das Problem zu umgehen. Wenn wir Datenstrukturen so behandeln, als wären sie Funktionen auf Indizes, könnten wir stattdessen (a x y) schreiben, was sogar kürzer ist als die Perl-Form. Ähnliche Tricks können andere Arten von Ausdrücken verkürzen.

Wir können viele Klammern loswerden (oder optional machen), indem wir die Einrückung signifikant machen. So lesen Programmierer Code: wenn die Einrückung etwas anderes sagt als die Begrenzer, folgen wir der Einrückung. Die Einrückung als signifikant zu behandeln, würde diese häufige Fehlerquelle eliminieren und die Programme kürzer machen.

Manchmal ist die Infix-Syntax leichter zu lesen. Dies gilt insbesondere für mathematische Ausdrücke. Ich habe mein ganzes Programmierleben lang Lisp verwendet und finde immer noch nicht, dass präfixe mathematische Ausdrücke natürlich sind. Und doch ist es praktisch, insbesondere wenn Sie Code generieren, Operatoren zu haben, die beliebig viele Argumente annehmen. Wenn wir also eine Infix-Syntax haben, sollte sie wahrscheinlich als eine Art Lese-Makro implementiert werden.

Ich denke nicht, dass wir religiös gegen die Einführung von Syntax in Lisp sein sollten, solange sie sich auf eine gut verstandene Weise in die zugrunde liegenden s-Ausdrücke übersetzt. Es gibt bereits eine Menge Syntax in Lisp. Es ist nicht unbedingt schlecht, mehr einzuführen, solange niemand gezwungen wird, sie zu verwenden. In Common Lisp sind einige Begrenzer für die Sprache reserviert, was darauf hindeutet, dass zumindest einige der Designer beabsichtigten, in Zukunft mehr Syntax zu haben.

Eines der eklatant unlispy Syntaxelemente in Common Lisp tritt in Format-Strings auf; Format ist eine eigene Sprache, und diese Sprache ist nicht Lisp. Wenn es einen Plan zur Einführung mehr Syntax in Lisp gäbe, könnten Format-Spezifizierer darin enthalten sein. Es wäre eine gute Sache, wenn Makros Format-Spezifizierer generieren könnten, so wie sie jede andere Art von Code generieren.

Ein angesehener Lisp-Hacker sagte mir, dass sein Exemplar von CLTL auf die Sektion Format aufschlägt. Meins auch. Das deutet wahrscheinlich auf Verbesserungsbedarf hin. Es könnte auch bedeuten, dass Programme viel I/O machen.

8 Effizienz

Eine gute Sprache sollte, wie jeder weiß, schnellen Code generieren. Aber in der Praxis denke ich nicht, dass schneller Code primär aus dem kommt, was Sie im Design der Sprache tun. Wie Knuth schon vor langer Zeit feststellte, ist Geschwindigkeit nur in bestimmten kritischen Engpässen wichtig. Und wie viele Programmierer seitdem beobachtet haben, ist man sehr oft im Unrecht, wo diese Engpässe sind.

In der Praxis ist der Weg, um schnellen Code zu erhalten, einen sehr guten Profiler zu haben, anstatt, sagen wir, die Sprache stark typisiert zu machen. Sie müssen nicht den Typ jedes Arguments in jedem Aufruf im Programm kennen. Sie müssen in der Lage sein, die Typen der Argumente in den Engpässen zu deklarieren. Und noch mehr, Sie müssen herausfinden können, wo die Engpässe sind.

Eine Beschwerde, die die Leute über Lisp hatten, ist, dass es schwierig ist zu erkennen, was teuer ist. Das könnte wahr sein. Es könnte auch unvermeidlich sein, wenn Sie eine sehr abstrakte Sprache haben wollen. Und in jedem Fall denke ich, dass gutes Profiling viel dazu beitragen würde, das Problem zu beheben: Sie würden schnell lernen, was teuer war.

Ein Teil des Problems hier ist sozial. Sprachdesigner schreiben gerne schnelle Compiler. So messen sie ihre Fähigkeiten. Sie betrachten den Profiler bestenfalls als ein Add-On. Aber in der Praxis könnte ein guter Profiler mehr dazu beitragen, die Geschwindigkeit tatsächlicher Programme, die in der Sprache geschrieben sind, zu verbessern als ein Compiler, der schnellen Code generiert. Hier sind die Sprachdesigner wieder etwas entfernt von ihren Benutzern. Sie machen einen wirklich guten Job, um das leicht falsche Problem zu lösen.

Es könnte eine gute Idee sein, einen aktiven Profiler zu haben — Leistungsdaten an den Programmierer zu übermitteln, anstatt zu warten, dass er danach fragt. Zum Beispiel könnte der Editor Engpässe rot anzeigen, wenn der Programmierer den Quellcode bearbeitet. Ein anderer Ansatz wäre, irgendwie darzustellen, was in laufenden Programmen passiert. Dies wäre ein besonders großer Gewinn in serverbasierten Anwendungen, wo Sie viele laufende Programme haben, die Sie sich ansehen können. Ein aktiver Profiler könnte grafisch darstellen, was im Speicher passiert, während ein Programm läuft, oder sogar Geräusche machen, die anzeigen, was passiert.

Geräusche sind ein guter Hinweis auf Probleme. An einem Ort, an dem ich gearbeitet habe, hatten wir ein großes Brett mit Zeigern, das zeigte, was mit unseren Webservern geschah. Die Zeiger wurden von kleinen Servomotoren bewegt, die ein leichtes Geräusch machten, wenn sie sich drehten. Ich konnte das Brett von meinem Schreibtisch aus nicht sehen, aber ich stellte fest, dass ich sofort am Geräusch erkennen konnte, wenn es ein Problem mit einem Server gab.

Es könnte sogar möglich sein, einen Profiler zu schreiben, der ineffiziente Algorithmen automatisch erkennt. Ich wäre nicht überrascht, wenn bestimmte Muster des Speicherzugriffs sich als sichere Anzeichen für schlechte Algorithmen herausstellen würden. Wenn es einen kleinen Kerl gäbe, der in dem Computer herumlaufen würde und unsere Programme ausführen würde, hätte er wahrscheinlich eine ebenso lange und klagende Geschichte über seinen Job wie ein Bundesangestellter. Ich habe oft das Gefühl, dass ich den Prozessor auf viele wilde Verfolgungsjagden schicke, aber ich hatte nie eine gute Möglichkeit, zu sehen, was er tut.

Eine Reihe von Lisps kompiliert jetzt in Bytecode, der dann von einem Interpreter ausgeführt wird. Dies geschieht normalerweise, um die Implementierung leichter portierbar zu machen, könnte aber eine nützliche Sprachfunktion sein. Es könnte eine gute Idee sein, den Bytecode zu einem offiziellen Teil der Sprache zu machen und es Programmierern zu ermöglichen, Inline-Bytecode in Engpässen zu verwenden. Dann wären solche Optimierungen auch portabel.

Die Natur der Geschwindigkeit, wie sie vom Endbenutzer wahrgenommen wird, könnte sich ändern. Mit dem Aufstieg serverbasierter Anwendungen könnten immer mehr Programme I/O-gebunden sein. Es wird sich lohnen, I/O schnell zu machen. Die Sprache kann mit einfachen, schnellen, formatierten Ausgabefunktionen helfen und auch mit tiefgreifenden strukturellen Änderungen wie Caching und persistenten Objekten.

Benutzer sind an der Reaktionszeit interessiert. Aber eine andere Art von Effizienz wird zunehmend wichtig sein: die Anzahl der gleichzeitigen Benutzer, die Sie pro Prozessor unterstützen können. Viele der interessanten Anwendungen, die in naher Zukunft geschrieben werden, werden serverbasiert sein, und die Anzahl der Benutzer pro Server ist die entscheidende Frage für jeden, der solche Anwendungen hostet. In den Investitionskosten eines Unternehmens, das eine serverbasierte Anwendung anbietet, ist dies der Divisor.

Jahrelang hat Effizienz in den meisten Endbenutzeranwendungen nicht viel bedeutet. Entwickler konnten davon ausgehen, dass jeder Benutzer einen immer leistungsfähigeren Prozessor auf seinem Schreibtisch haben würde. Und nach Parkinsons Gesetz hat sich die Software ausgeweitet, um die verfügbaren Ressourcen zu nutzen. Das wird sich mit serverbasierten Anwendungen ändern. In dieser Welt werden Hardware und Software zusammen bereitgestellt. Für Unternehmen, die serverbasierte Anwendungen anbieten, wird es einen sehr großen Unterschied für das Endergebnis machen, wie viele Benutzer sie pro Server unterstützen können.

In einigen Anwendungen wird der Prozessor der begrenzende Faktor sein, und die Ausführungsgeschwindigkeit wird das Wichtigste sein, was optimiert werden muss. Aber oft wird der Speicher das Limit sein; die Anzahl der gleichzeitigen Benutzer wird durch die Menge an Speicher bestimmt, die Sie für die Daten jedes Benutzers benötigen. Die Sprache kann auch hier helfen. Gute Unterstützung für Threads wird es allen Benutzern ermöglichen, einen einzigen Heap zu teilen. Es könnte auch hilfreich sein, persistente Objekte und/oder Unterstützung auf Sprachebene für Lazy Loading zu haben.

9 Zeit

Die letzte Zutat, die eine beliebte Sprache benötigt, ist Zeit. Niemand möchte Programme in einer Sprache schreiben, die verschwinden könnte, wie so viele Programmiersprachen es tun. Daher werden die meisten Hacker dazu neigen, zu warten, bis eine Sprache ein paar Jahre lang existiert hat, bevor sie überhaupt darüber nachdenken, sie zu verwenden.

Erfinder wunderbarer neuer Dinge sind oft überrascht, dies zu entdecken, aber Sie benötigen Zeit, um eine Botschaft an die Menschen zu bringen. Ein Freund von mir tut selten etwas beim ersten Mal, wenn ihn jemand fragt. Er weiß, dass Menschen manchmal nach Dingen fragen, die sie sich später als nicht gewünscht herausstellen. Um seine Zeit nicht zu verschwenden, wartet er, bis er zum dritten oder vierten Mal gebeten wird, etwas zu tun; bis dahin könnte derjenige, der ihn fragt, ziemlich verärgert sein, aber zumindest wollen sie wahrscheinlich wirklich das, wonach sie fragen.

Die meisten Menschen haben gelernt, eine ähnliche Art von Filterung bei neuen Dingen vorzunehmen, von denen sie hören. Sie beginnen nicht einmal, Aufmerksamkeit zu schenken, bis sie von etwas zehn Mal gehört haben. Sie sind vollkommen gerechtfertigt: Die Mehrheit der heißen neuen Dinge stellt sich als Zeitverschwendung heraus und verschwindet schließlich. Indem ich das Lernen von VRML hinauszögerte, vermied ich es, es überhaupt lernen zu müssen.

Daher muss jeder, der etwas Neues erfindet, damit rechnen, seine Botschaft jahrelang immer wieder zu wiederholen, bevor die Leute anfangen, sie zu verstehen. Wir schrieben, soweit ich weiß, die erste webserverbasierte Anwendung, und es dauerte Jahre, bis wir den Leuten klar machten, dass sie nicht heruntergeladen werden musste. Es war nicht so, dass sie dumm waren. Sie hatten uns einfach ausgeblendet.

Die gute Nachricht ist, dass einfache Wiederholung das Problem löst. Alles, was Sie tun müssen, ist, Ihre Geschichte immer weiterzuerzählen, und schließlich werden die Leute anfangen, zu hören. Es ist nicht der Zeitpunkt, an dem die Leute bemerken, dass Sie da sind, dass sie Aufmerksamkeit schenken; es ist der Zeitpunkt, an dem sie bemerken, dass Sie immer noch da sind.

Es ist ganz gut, dass es normalerweise eine Weile dauert, um Schwung zu gewinnen. Die meisten Technologien entwickeln sich deutlich weiter, selbst nachdem sie erstmals eingeführt wurden — insbesondere Programmiersprachen. Nichts könnte besser sein für eine neue Technologie, als ein paar Jahre lang nur von einer kleinen Anzahl von frühen Anwendern verwendet zu werden. Frühe Anwender sind anspruchsvoll und fordernd und decken schnell alle Fehler auf, die in Ihrer Technologie verbleiben. Wenn Sie nur ein paar Benutzer haben, können Sie mit allen in engem Kontakt sein. Und frühe Anwender sind nachsichtig, wenn Sie Ihr System verbessern, selbst wenn dies einige Brüche verursacht.

Es gibt zwei Möglichkeiten, wie neue Technologien eingeführt werden: die organische Wachstums-Methode und die Big-Bang-Methode. Die organische Wachstums-Methode wird durch das klassische Unternehmen im Hinterhof ohne Finanzierung veranschaulicht. Ein paar Leute, die im Verborgenen arbeiten, entwickeln eine neue Technologie. Sie bringen sie ohne Marketing auf den Markt und haben zunächst nur ein paar (fanatisch engagierte) Benutzer. Sie verbessern die Technologie weiter, und währenddessen wächst ihre Benutzerbasis durch Mundpropaganda. Bevor sie es wissen, sind sie groß.

Der andere Ansatz, die Big-Bang-Methode, wird durch das VC-unterstützte, stark vermarktete Startup veranschaulicht. Sie eilen, um ein Produkt zu entwickeln, bringen es mit großem Öffentlichkeitswirbel auf den Markt und haben sofort (so hoffen sie) eine große Benutzerbasis.

Im Allgemeinen beneiden die Garagen-Jungs die Big-Bang-Jungs. Die Big-Bang-Jungs sind glatt und selbstbewusst und von den VCs respektiert. Sie können sich das Beste von allem leisten, und die PR-Kampagne rund um den Launch hat den Nebeneffekt, sie zu Prominenten zu machen. Die organischen Wachstums-Jungs, die in ihrer Garage sitzen, fühlen sich arm und ungeliebt. Und doch glaube ich, dass sie oft einen Fehler machen, wenn sie sich selbst leid tun. Organisches Wachstum scheint bessere Technologie und reichere Gründer hervorzubringen als die Big-Bang-Methode. Wenn Sie sich die dominierenden Technologien von heute ansehen, werden Sie feststellen, dass die meisten von ihnen organisch gewachsen sind.

Dieses Muster gilt nicht nur für Unternehmen. Man sieht es auch in sponserter Forschung. Multics und Common Lisp waren Big-Bang-Projekte, und Unix und MacLisp waren organische Wachstumsprojekte.

10 Neugestaltung

"Das beste Schreiben ist Umschreiben", schrieb E. B. White. Jeder gute Schriftsteller weiß das, und es gilt auch für Software. Der wichtigste Teil des Designs ist die Neugestaltung. Programmiersprachen, insbesondere, werden nicht genug neu gestaltet.

Um gute Software zu schreiben, müssen Sie gleichzeitig zwei entgegengesetzte Ideen in Ihrem Kopf behalten. Sie brauchen den naiven Glauben des jungen Hackers an seine Fähigkeiten und gleichzeitig den Skeptizismus des Veteranen. Sie müssen in der Lage sein, zu denken wie schwer kann es sein? mit einer Hälfte Ihres Gehirns, während Sie mit der anderen denken es wird niemals funktionieren.

Der Trick besteht darin, zu erkennen, dass hier kein echter Widerspruch besteht. Sie möchten optimistisch und skeptisch in bezug auf zwei verschiedene Dinge sein. Sie müssen optimistisch über die Möglichkeit sein, das Problem zu lösen, aber skeptisch über den Wert der Lösung, die Sie bisher haben.

Menschen, die gute Arbeit leisten, denken oft, dass das, woran sie arbeiten, nichts wert ist. Andere sehen, was sie getan haben, und sind voller Staunen, aber der Schöpfer ist voller Sorgen. Dieses Muster ist kein Zufall: Es ist die Sorge, die die Arbeit gut gemacht hat.

Wenn Sie Hoffnung und Sorge im Gleichgewicht halten können, werden sie ein Projekt vorantreiben, so wie Ihre beiden Beine ein Fahrrad vorantreiben. In der ersten Phase des zweizyklichen Innovationsmotors arbeiten Sie fieberhaft an einem Problem, inspiriert von Ihrem Vertrauen, dass Sie es lösen können. In der zweiten Phase schauen Sie sich an, was Sie in dem kalten Licht des Morgens getan haben, und sehen all seine Fehler sehr klar. Aber solange Ihr kritischer Geist Ihre Hoffnung nicht überwiegt, werden Sie in der Lage sein, Ihr zugegebenermaßen unvollständiges System anzusehen und zu denken, wie schwer kann es sein, den Rest des Weges zu gehen?, und damit den Zyklus fortzusetzen.

Es ist knifflig, die beiden Kräfte im Gleichgewicht zu halten. Bei jungen Hackern überwiegt der Optimismus. Sie produzieren etwas, sind überzeugt, dass es großartig ist, und verbessern es nie. Bei alten Hackern überwiegt der Skeptizismus, und sie wagen es nicht einmal, ehrgeizige Projekte anzugehen.

Alles, was Sie tun können, um den Neugestaltungszyklus am Laufen zu halten, ist gut. Prosa kann immer wieder umgeschrieben werden, bis Sie damit zufrieden sind. Aber Software wird in der Regel nicht genug neu gestaltet. Prosa hat Leser, aber Software hat Benutzer. Wenn ein Schriftsteller einen Aufsatz umschreibt, werden die Menschen, die die alte Version gelesen haben, kaum beschweren, dass ihre Gedanken durch eine neu eingeführte Inkompatibilität gestört wurden.

Benutzer sind ein zweischneidiges Schwert. Sie können Ihnen helfen, Ihre Sprache zu verbessern, aber sie können Sie auch davon abhalten, sie zu verbessern. Wählen Sie also Ihre Benutzer sorgfältig aus und seien Sie langsam darin, ihre Anzahl zu erhöhen. Benutzer zu haben ist wie Optimierung: Der weise Kurs ist, es hinauszuzögern. Außerdem können Sie in der Regel zu einem bestimmten Zeitpunkt mehr ändern, als Sie denken. Veränderungen einzuführen ist wie ein Pflaster abzuziehen: Der Schmerz ist fast sofort eine Erinnerung.

Jeder weiß, dass es keine gute Idee ist, eine Sprache von einem Ausschuss entwerfen zu lassen. Ausschüsse führen zu schlechtem Design. Aber ich denke, die größte Gefahr von Ausschüssen ist, dass sie die Neugestaltung behindern. Es ist so viel Arbeit, Änderungen einzuführen, dass niemand sich die Mühe machen will. Was auch immer ein Ausschuss beschließt, bleibt in der Regel so, auch wenn die meisten Mitglieder es nicht mögen.

Sogar ein Ausschuss von zwei Personen behindert die Neugestaltung. Dies geschieht insbesondere an den Schnittstellen zwischen Softwareteilen, die von zwei verschiedenen Personen geschrieben wurden. Um die Schnittstelle zu ändern, müssen beide zustimmen, sie gleichzeitig zu ändern. Und so neigen Schnittstellen dazu, sich überhaupt nicht zu ändern, was ein Problem ist, weil sie eine der ad hoc Teile eines Systems sind.

Eine Lösung könnte darin bestehen, Systeme so zu gestalten, dass Schnittstellen horizontal statt vertikal sind — sodass Module immer vertikal gestapelte Schichten von Abstraktionen sind. Dann wird die Schnittstelle tendenziell von einer von ihnen besessen. Die untere von zwei Ebenen wird entweder eine Sprache sein, in der die obere geschrieben ist, in diesem Fall wird die untere Ebene die Schnittstelle besitzen, oder sie wird ein Sklave sein, in diesem Fall kann die Schnittstelle von der oberen Ebene diktiert werden.

11 Lisp

Was all dies impliziert, ist, dass es Hoffnung für ein neues Lisp gibt. Es gibt Hoffnung für jede Sprache, die Hackern das gibt, was sie wollen, einschließlich Lisp. Ich denke, wir haben einen Fehler gemacht, als wir dachten, dass Hacker von Lispers Fremdheit abgeschreckt werden. Diese tröstliche Illusion könnte uns davon abgehalten haben, das wirkliche Problem mit Lisp oder zumindest Common Lisp zu sehen, nämlich dass es für das, was Hacker tun wollen, ungeeignet ist. Eine Hacker-Sprache benötigt mächtige Bibliotheken und etwas zum Hacken. Common Lisp hat beides nicht. Eine Hacker-Sprache ist prägnant und hackbar. Common Lisp ist es nicht.

Die gute Nachricht ist, dass nicht Lisp schlecht ist, sondern Common Lisp. Wenn wir ein neues Lisp entwickeln können, das eine echte Hacker-Sprache ist, denke ich, dass Hacker es verwenden werden. Sie werden jede Sprache verwenden, die die Aufgabe erledigt. Alles, was wir tun müssen, ist sicherzustellen, dass dieses neue Lisp eine wichtige Aufgabe besser erledigt als andere Sprachen.

Die Geschichte bietet etwas Ermutigung. Im Laufe der Zeit haben nachfolgende neue Programmiersprachen immer mehr Funktionen von Lisp übernommen. Es bleibt nicht mehr viel zu kopieren, bevor die Sprache, die Sie erstellt haben, Lisp ist. Die neueste heiße Sprache, Python, ist ein verwässertes Lisp mit Infix-Syntax und keinen Makros. Ein neues Lisp wäre ein natürlicher Schritt in dieser Entwicklung.

Manchmal denke ich, dass es ein guter Marketing-Trick wäre, es eine verbesserte Version von Python zu nennen. Das klingt hipper als Lisp. Für viele Menschen ist Lisp eine langsame KI-Sprache mit vielen Klammern. Die offizielle Biografie von Fritz Kunze vermeidet es sorgfältig, das L-Wort zu erwähnen. Aber ich vermute, dass wir keine Angst haben sollten, das neue Lisp Lisp zu nennen. Lisp hat immer noch viel latenten Respekt unter den besten Hackern — denjenigen, die 6.001 belegt haben und es verstanden haben, zum Beispiel. Und das sind die Benutzer, die Sie gewinnen müssen.

In "Wie man ein Hacker wird" beschreibt Eric Raymond Lisp als etwas wie Latein oder Griechisch — eine Sprache, die Sie als intellektuelle Übung lernen sollten, auch wenn Sie sie nicht tatsächlich verwenden werden:

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

Wenn ich Lisp nicht wüsste, würde mich das Lesen dieser Zeilen fragen lassen. Eine Sprache, die mich zu einem besseren Programmierer machen würde, wenn das überhaupt etwas bedeutet, bedeutet eine Sprache, die besser zum Programmieren geeignet wäre. Und das ist in der Tat die Implikation dessen, was Eric sagt.

Solange diese Idee noch im Umlauf ist, denke ich, dass Hacker offen genug für ein neues Lisp sein werden, selbst wenn es Lisp genannt wird. Aber dieses Lisp muss eine Hacker-Sprache sein, wie die klassischen Lisps der 1970er Jahre. Es muss prägnant, einfach und hackbar sein. Und es muss mächtige Bibliotheken haben, um das zu tun, was Hacker jetzt tun wollen.

In Bezug auf Bibliotheken denke ich, dass es Raum gibt, Sprachen wie Perl und Python in ihrem eigenen Spiel zu schlagen. Viele der neuen Anwendungen, die in den kommenden Jahren geschrieben werden müssen, werden serverbasierte Anwendungen sein. Es gibt keinen Grund, warum ein neues Lisp nicht ebenso gute Zeichenfolgenbibliotheken wie Perl haben sollte, und wenn dieses neue Lisp auch mächtige Bibliotheken für serverbasierte Anwendungen hätte, könnte es sehr beliebt werden. Echte Hacker werden nicht die Nase rümpfen über ein neues Werkzeug, das ihnen hilft, schwierige Probleme mit ein paar Bibliotheksaufrufen zu lösen. Denken Sie daran, Hacker sind faul.

Es könnte ein noch größerer Gewinn sein, Unterstützung auf Kernsprachenebene für serverbasierte Anwendungen zu haben. Zum Beispiel explizite Unterstützung für Programme mit mehreren Benutzern oder Datenbesitz auf der Ebene von Typ-Tags.

Serverbasierte Anwendungen geben uns auch die Antwort auf die Frage, wofür dieses neue Lisp verwendet werden wird. Es würde nicht schaden, Lisp als Skriptsprache für Unix zu verbessern. (Es wäre schwer, es schlechter zu machen.) Aber ich denke, es gibt Bereiche, in denen es einfacher wäre, bestehende Sprachen zu schlagen. Ich denke, es wäre besser, dem Modell von Tcl zu folgen und das Lisp zusammen mit einem vollständigen System zur Unterstützung serverbasierter Anwendungen bereitzustellen. Lisp passt gut zu serverbasierten Anwendungen. Lexikalische Closures bieten eine Möglichkeit, den Effekt von Unterprogrammen zu erzielen, wenn die Benutzeroberfläche nur eine Reihe von Webseiten ist. S-Ausdrücke lassen sich gut auf HTML abbilden, und Makros sind gut darin, es zu generieren. Es müssen bessere Werkzeuge zum Schreiben serverbasierter Anwendungen entwickelt werden, und es muss ein neues Lisp geben, und die beiden würden sehr gut zusammenarbeiten.

12 Die Traum-Sprache

Zusammenfassend lassen Sie uns versuchen, die Traum-Sprache des Hackers zu beschreiben. Die Traum-Sprache ist schön, sauber und prägnant. Sie hat ein interaktives Top-Level, das schnell startet. Sie können Programme schreiben, um häufige Probleme mit sehr wenig Code zu lösen. Fast der gesamte Code in jedem Programm, das Sie schreiben, ist spezifisch für Ihre Anwendung. Alles andere wurde für Sie erledigt.

Die Syntax der Sprache ist fehlerhaft kurz. Sie müssen nie ein unnötiges Zeichen tippen oder sogar die Umschalttaste viel benutzen.

Mit großen Abstraktionen können Sie die erste Version eines Programms sehr schnell schreiben. Später, wenn Sie optimieren möchten, gibt es einen wirklich guten Profiler, der Ihnen sagt, wo Sie Ihre Aufmerksamkeit konzentrieren sollten. Sie können innere Schleifen blitzschnell machen, sogar Inline-Bytecode schreiben, wenn Sie müssen.

Es gibt viele gute Beispiele, von denen Sie lernen können, und die Sprache ist intuitiv genug, dass Sie in ein paar Minuten lernen können, wie man sie anhand von Beispielen verwendet. Sie müssen nicht viel im Handbuch nachsehen. Das Handbuch ist dünn und hat wenige Warnungen und Qualifikationen.

Die Sprache hat einen kleinen Kern und mächtige, hochgradig orthogonale Bibliotheken, die so sorgfältig entworfen sind wie die Kernsprache. Die Bibliotheken arbeiten alle gut zusammen; alles in der Sprache passt zusammen wie die Teile in einer feinen Kamera. Nichts ist veraltet oder aus Kompatibilitätsgründen beibehalten. Der Quellcode aller Bibliotheken ist leicht verfügbar. Es ist einfach, mit dem Betriebssystem und mit Anwendungen, die in anderen Sprachen geschrieben sind, zu kommunizieren.

Die Sprache ist in Schichten aufgebaut. Die höheren Abstraktionen sind auf sehr transparente Weise aus niedrigeren Abstraktionen aufgebaut, auf die Sie zugreifen können, wenn Sie möchten.

Nichts ist vor Ihnen verborgen, was nicht unbedingt verborgen werden muss. Die Sprache bietet Abstraktionen nur als eine Möglichkeit, Ihnen Arbeit zu ersparen, nicht als eine Möglichkeit, Ihnen zu sagen, was Sie tun sollen. Tatsächlich ermutigt die Sprache Sie, ein gleichberechtigter Teilnehmer an ihrem Design zu sein. Sie können alles daran ändern, sogar die Syntax, und alles, was Sie schreiben, hat, so viel wie möglich, den gleichen Status wie das, was vordefiniert ist.

Anmerkungen

[1] Makros, die der modernen Idee sehr nahe kommen, wurden 1964 von Timothy Hart vorgeschlagen, zwei Jahre nachdem Lisp 1.5 veröffentlicht wurde. Was anfangs fehlte, waren Möglichkeiten, um Variablenübernahme und mehrfache Auswertung zu vermeiden; Harts Beispiele sind beiden unterworfen.

[2] In When the Air Hits Your Brain erzählt der Neurochirurg Frank Vertosick von einem Gespräch, in dem sein Chefarzt, Gary, über den Unterschied zwischen Chirurgen und Internisten ("Flöhe") spricht:

Gary und ich bestellten eine große Pizza und fanden eine offene Nische. Der Chef zündete sich eine Zigarette an. "Schau dir diese verdammten Flöhe an, die über eine Krankheit plappern, die sie einmal in ihrem Leben sehen werden. Das ist das Problem mit Flöhen, sie mögen nur die bizarren Sachen. Sie hassen ihre Brot-und-Butter-Fälle. Das ist der Unterschied zwischen uns und den verdammten Flöhen. Sieh, wir lieben große saftige Lendenwirbelsäulenherniationen, aber sie hassen Bluthochdruck...."

Es ist schwer, sich eine Lendenwirbelsäulenherniation als saftig vorzustellen (außer im wörtlichen Sinne). Und doch denke ich, dass ich weiß, was sie meinen. Ich hatte oft einen saftigen Fehler zu verfolgen. Jemand, der kein Programmierer ist, würde es schwer finden, sich vorzustellen, dass es Freude an einem Fehler geben kann. Sicherlich ist es besser, wenn alles einfach funktioniert. In gewisser Weise ist es das. Und doch gibt es unbestreitbar eine grimmige Zufriedenheit darin, bestimmte Arten von Fehlern zu jagen.