Warum verwenden so wenige Entwickler Lisp?

Lisp ist die Programmiersprache der wahren Könner unter den Programmierern!

Wenn dem so ist, und die meisten Lisp-Programmierer werden das in der einen oder anderen Form unterschreiben, dann darf man sich fragen, warum nicht mehr Personen Lisp programmieren, sondern im Gegenteil Lisp von den meisten Programmierern für eher sonderbar gehalten wird. Nimmt man hinzu, dass Lisp bereits 1958 (auf einer IBM 704 mit Kernspeicher) das Licht der Welt erblickt hat, dann wird einem sofort klar, dass es sich, falls die Lisp-Anhängerschaft Recht hat, nur um einen Irrtum der Geschichte handeln kann, dass Lisp nur in einem winzigen Teil aktueller Softwareprojekte verwendet wird.

Mit dieser Frage gehen einzelne Lisp-Programmierer sehr unterschiedlich um. In einem Aufsatz namens "Beating the Averages" unterstreicht Paul Graham, dass es ihm sogar Recht ist, wenn Lisp nicht besonders populär ist, da er dadurch einen Wettbewerbsvorteil gegenüber Konkurrenten hat, die "Blub-Sprachen" (wie er sie nennt) benutzen müssen und dadurch viel weniger flexibel in der Entwicklung sind. Dies ist natürlich die Sichtweise eines Unternehmers, der sich fragt, wie schnell er Projekt umsetzen kann und man muss diesen Ansatz nicht unbedingt teilen. Im Gegensatz zu ihm werden nämlich andere Lisp-Entwickler nicht müde zu betonen, welche Vorteile Lisp gegenüber allen anderen Sprachen aus bestimmten Gründen hat und warum eben diese anderen Sprachen niemals genau diese Vorteile haben werden, es sei denn man baut sie zu Lisp um. Warum das aber so wenig Erfolg zeitigt, sehen wir im folgenden Abschnitt.

Programmierer sind sektiererisch. Sehr sektiererisch sogar und dabei manchmal schlimmer als Anhänger von Religionsgruppen. Die Programmiersprachen haben zwischen ihren Anwendern Mauern errichtet, die jeder Programmierer auf Gedeih und Verderb verteidigt. "Watt de Buur nich kennt datt frett he net!" sagt ein Sprichwort und keiner nimmt diese Ausage so ernst wie die Bauern selbst und die programmierende Kaste.

Das hat einen nicht ganz trivialen Grund: Mit zunehmender Routine in "seiner" Programmiersprache beginnt der Programmierer immer mehr in seiner Programmiersprache nicht nur arbeiten, sondern auch zu denken. Das tut er automatisch und das ist gut so, denn sonnst könnte er nicht effektiv arbeiten. Damit ist ja auch durchaus nicht gemeint, dass er in Gedanken in seiner Programmiersprache im Kopf vor sich hin brabbelt, sondern nur, dass er die Strukturen der Aufgabenstellung auf die Strukuren seiner Programmiersprache abbildet.

Das ist die Modellierung. Er schafft eine Verbindug zwischen den Einzelteilen seines gewünschten Ergebnisses und den Mitteln, die ihm dazu zur Verfügung stehen. Diese sind Dinge wie Module, Klassen, Bibliotheken, Funktionen, Rekursion, Iteration, Variablen, Listen, Closures, Streams, Monaden oder was auch immer von seinem Programmiersystem unterstützt wird.

Auf der anderen Seite ist genau dies aber gefährlich, denn der Programmierer ist damit in seiner Welt, die "Fortran", "Java" oder "C" heisst, gefangen. Die Sprache beeinflusst unser Denken mehr als alles andere. Wir können immer nur das denken, was unsere Sprache auch darzustellen in der Lage ist. Und das gilt für künstliche Sprachen genauso wie für natürliche.

Das erkennt man auch daran, dass mit dem Voranschreiten in jeder Richtung, der Mensch auch die eigene Sprache den Erfordernissen marginal anpassen muss, damit sie ihm als Werkzeug zur Bewältigung seiner Aufgaben nützlich ist.

Hinter diesem Begriff steckt auch der Schlüssel zur Abhängigkeit seines Denkens von seiner Sprache, seinem Werkzeug: Ein Handwerker zum Beispiel, der sich einer Aufgabe gegenüber sieht, überlegt sich beim Betrachten der Baustelle anhand seiner Werkzeuge und Methoden: "Da muss ich zunächst die Zarge lösen, ein neues Loch für die Angel bohren, einen Dübel einsetzen, die Zarge wieder einbauen, die Angel eindrehen. Wenn das Türblatt dann nicht passt, gegebenenfalls mit dem Hobel Material wegnehmen…".

Dabei richtet sich die Arbeitsweise nach den vorhandenen Werkeugen, die jeweils bestimmte Arbeitsschritte ermöglichen. Die Vorhgehensweise ist für den Handwerker genauso evident wie seine Werkzeuge und was er am allerwenigsten gebrauchen kann, ist jemand, der sich daneben stellt, alles besser weis und ungefragt Vorträge darüber hält. "Haben wir schon immer so gemacht!", denkt er. Er steckt so tief in seiner Welt, dass er sie solange verteidigen wird, wie er kann, denn es gibt aus seiner Sicht keinen Anlass, an seinem Vorgehen etwas zu ändern.

Aufgeschlossenheit und Überzeugung schließen sich nun einmal gegenseitig aus. Ich möchte aber die Handwerker nicht schlecht machen - sie dienen nur als Beispiel. Diese Art des Denkens ist Ärzten, Rechtsanwälten und Ingenieuren genauso zu eigen wie - ja, richtig: Programmierern.

Es gibt ein ungeheuer lehrreiches Beispiel aus der europäischen Geschichte, das uns zeigt, welche einschneidenden Einschränkungen eine Sprache seinem Sprecher auferlegen kann, ohne das dieser überhaupt merkt, wie sehr er von dieser behindert wird: Die Rede ist von der Römischen Zahlschrift.

Kein Historiker wundert sich heute, dass die Römer zur Entwicklung der Mathematik überhaupt nichts beigetragen haben. Wie sollten sie auch? Eine Notation, in der bereits das Multiplizieren von Zahlen oberhalb von 10000 eine abendfüllende Beschäftigung werden musste, muss dazu geführt haben, dass man die meisten Berechnungen einfach unterlassen hat, weil es zu kompliziert war.

Die Mathematik haben die Römer gerade noch dazu gebrauchen können, um den Zehnten beim Eintreiben der Steuern zu berechnen und um zusammenzuzählen, wieviele Sandalen man benötigt, um ein Heer auszustatten. Sobald es komplizierter wurde, musste man auf andere Mittel als das Rechnen ausweichen, um z.B. logistische Fragen zu lösen.

Bestimmt – und das ist ein entscheidender Gesichtspunkt – haben die Römer großes Geschick entwicklt, die Unzulänglichkeit ihres Zahlsystems zu kompensieren, aber nie hatten sie die Chance, dabei zu solchen Fragen vorzustossen, wie die, wie Optimierungen anzugehen sind, oder wie sich Rechenvorgänge verallgemeinern oder vereinfachen lassen. Den Römern fehlte sogar die Fähigkeit zur vollständig korrekten Behandlung von Brüchen. Man beschränkte sich einfach auf solche Brüche, deren Nenner Teiler von Zwölf oder Vielfache von Zehn sind.

Das fatale ist, dass die Römer diese Schwäche den Zahlen selbst zuordnen mussten, aber kaum ihrer unzureichenden Zahlen-Notation. Sie konnten nicht zwischen beidem unterschieden und daher war für sie war nicht nur ihr Zahlensystem mangelhaft sondern die Zahlen selbst.

Genau in die selbe Falle muss derjenige tappen, der Programmieren für ein schwieriges Geschäft hält und kein Lisp kann. Es ist für Ihn unmöglich, zu erkennen, dass sein Problem mit viel weniger Anweisungen und deutlich klarer in Lisp gelöst werden kann.

Das Ausweichen auf andere Mittel aber ermöglicht es einem Sprecher, bei seiner insuffizienten Sprache zu bleiben und sich mit ihr zu arrangieren. Sie hindert ihn aber gleichzeitig am Umstieg auf ein besseres System. Dieser Workaround erscheint ihm weniger aufwendig, als etwas komplett Neues zu lernen oder zu suchen. Also bleibt alles erst mal Alles so lange wie irgend möglich beim Alten.

Zurück zu unserem Thema Programmiersprachen bedeutet das: Die Blub-Entwickler können nicht begreifen, dass die LISP-Welt so einen Wind um ihre Sprache macht und Lisp-Anhänger verzweifeln daran, dass die Blub-Welt einfach nicht verstehen will, dass in ihren Programmiersprachen etwas Wichtiges fehlt: Die eigene Programmierbarkeit. Diese Programmierbarkeit von Lisp hängt aber direkt von der Verwendung von S-Expressions ab, durch die Programme und Daten eine identische Darstellung haben.

Die S-Expressions dürften nicht-Lisp-Programmierern genauso unheimlich sein, wie den Römern das dezimale Stellenwertsystem der Inder, wenn sie es gekannt hätten. Und sie dürften dieselben Einwände gegen das Stellenwertsystem erhoben haben, wie sie heute gegen Lisp erhoben werden: Nämlich, dass es schwerer zu interpretieren ist.

Trotzdem hat es sich wegen seiner gewaltigen Möglichkeiten irgendwann durchgesetzt. Allerdings muss man sich erst mal die Mühe machen, zu verstehen. Aber Geschichte soll sich ja häufiger wiederholen…