Über Programmiersprachen-Designer und andere Verbrecher

Neulich bin ich im Internet auf ein "Spiel" gestoßen, bei dem man anhand von Bildern entscheiden muss, ob es sich bei den Dargestellten um Programmiersprachen-Designer oder um Serienmörder handelt. Mir ist zwar nicht ganz klar, warum als Verbrecher ausgerechnet die Serienkiller herhalten mussten – schließlich gibt es doch auch genügend Kapitalverbrecher oder Verkehrssünder –, aber vielleicht hat der Autor des Spiels wirklich unter seiner Programmiersprache gelitten.

Dennoch muss er ja irgendwie darauf gekommen sein, dass Programmiersprachen-Designer vergleichbar zu Verbrechern sind. Der Duden definiert ein Verbrechen als "schwere Straftat", "verabscheuenswürdige Untat" oder "verwerfliche, verantwortungslose Handlung". Das mit der Straftat stimmt sicherlich nicht, denn "strafbar" ist es ja nicht, eine Programmiersprache zu entwerfen. Aber "verwerflich" oder "verantwortungslos" könnte die Implementierung des einen oder anderen Sprach-Features schon sein.

Nachdem es keinen konkreten Anforderungskatalog für Programmiersprachen gibt, wird es natürlich schwierig, einem Sprachdesigner ein Fehlverhalten vorzuhalten. Im syntaktischen Bereich beispielsweise wird dies ausgesprochen schwierig, denn schließlich gewöhnt man sich an fast alles: Die vielen runden Klammern in Lisp "( )", die vielen geschweiften Klammern in den C-ähnlichen Sprachen "{ }", die spitzen Klammern für Templates und Generics "< >", die eckigen Klammern in SETL "[ ]", keine Klammern in Python oder die Oxford-Klammern in Haskell und Fortress "[| |]".

Aber selbst wenn es einen objektiven Katalog gäbe, würde der nur bedingt etwas nutzen. Denn schließlich sind Gesetze nur moralisches Minimum. So bleibt es – wie so oft – einem selbst überlassen, wo man die Untergrenze festlegt. So ist meine persönliche Grenze bei dem Test erreicht, mit dem geprüft wird, ob ein Wert innerhalb eines bestimmten Bereichs liegt:

a < b < c.

In den meisten Programmiersprachen muss man eine solche, aus der Schulmathematik bekannte Schreibweise, in zwei Teile zerlegen:

(a < b) ∧ (b < c),

was in Ermangelung des Zeichens "∧" für das logische Und beispielsweise als

(a < b) /\ (b < c)

oder

(a < b) && (b < c)

geschrieben wird.

Natürlich ist dieser Ausdruck äquivalent zum oberen Beispiel, aber er ist für mich deutlich schwerer zu erfassen, weil er nach zwei unabhängigen Anweisungen aussieht. Erschwert wird die Lesbarkeit noch zusätzlich, wenn man den Ausdruck verdreht

(b > a) ∧ (b < c),

dem seiner Natur nach nicht mehr eindeutig entnommen werden kann, ob b innerhalb bestimmter Grenzen liegen soll oder einfach nur zwei Bedingungen genügen muss.

Wer selbst schon einmal eine Grammatik geschrieben hat, der weiß auch, warum man das lieber so als anders macht. Das Problem ist nämlich, dass a < b einen Booleschen Wert liefert. Für einen Infix-Operator . < ., der zwei Zahlen vergleicht, und den entsprechenden Wahrheitswert liefert, wäre (a < b) < c demnach nicht definiert.

Also müsste man sich hier etwas mehr Mühe geben, damit beispielsweise auch Ausdrücke wie

a < b < c < d

oder

a ≤ b < c

möglich wären. Dahingegen sollten Ausdrücke der Form

a < b > c

nicht möglich sein. Analog dürfte demnach auch

a = b = c

geschrieben werden (wobei hier mit "=" natürlich der Vergleich und nicht die Zuweisung gemeint ist), es aber auf keinen Fall

a ≠ b ≠ c

heißen.

In der Programmiersprache Icon beispielsweise sind Ausdrücke dieser Art möglich. In einer Implementierung wird das Problem dadurch gelöst, dass bei einem solchen verketteten Ausdruck, bei dem Vergleich im Erfolgsfall einfach der rechte Operand geliefert wird, der dann weiter verglichen werden kann; bei Misserfolg wird der Ausdruck an der entsprechenden Stelle mit einer Art "fail" abgebrochen, was Bedingungen und Schleifen als "false" werten. (Damit sind in Icon noch ganz andere Ausdrücke möglich, aber das ist eine andere Geschichte.)

In die relativ neue Sprache Fortress sollte diese Schreibweise auch zulässig sein, und zwar nicht nur für "<" und ">", sondern auch für alle artverwandten Operatoren wie "≤", "≥" und sogar für "≺", "≻", "⊏", "⊐", "⊲", "⊳", "⊰", "⊱" usw. Dabei dürfen allerdings – zurecht – unterschiedliche Operatoren nicht kombiniert werden: a ⊏ b < c ist also nicht erlaubt. Allerdings weiß ich nicht, ob es diese Schreibweise in die finale Version geschafft hat.

Wie immer wird es auch hier die "Aber das braucht doch wirklich keiner"-Stimmen geben. Das sehe ich allerdings anders. Es geht hier nämlich nicht um dieses konkrete Beispiel – wenngleich es für mich sehr schön demonstriert, wie einfach man die Lesbarkeit einer Sprache verbessern könnte. Denn man ist außerhalb der funktionalen Programmierung schließlich jahrzehntelang ohne Closures und Lambdas (oder wie auch immer sie in den modernen Sprachen heißen mögen) ausgekommen. Und für alle, die sie schätzen gelernt haben, stellen sie neuerdings eine ungeheure, unverzichtbare Hilfe dar.

Und um das noch einmal klarzustellen: Auf ein offensichtlich brauchbares Feature zu verzichten ist grundsätzlich nicht verwerflich. Es aber nicht zu machen, weil sonst die Grammatik oder der Compiler komplizierter würden, das fällt für mich in die Kategorie "Unterlassene Hilfeleistung". Denn, sagt das Strafgesetzbuch:

"Wer bei Unglücksfällen oder gemeiner Gefahr oder Not nicht Hilfe leistet, obwohl dies erforderlich und ihm den Umständen nach zuzumuten, insbesondere ohne erhebliche eigene Gefahr und ohne Verletzung anderer wichtiger Pflichten möglich ist, wird mit Freiheitsstrafe bis zu einem Jahr oder mit Geldstrafe bestraft."

Natürlich kann man nicht jede Programmiersprache als "Unglücksfall" oder "gemeine Gefahr" bezeichnen, aber die eine oder andere Sprache hat den einen oder anderen Programmierer schon in arge Not gebracht. Demnach sind allzu bequeme Programmiersprachen-Designer oder faule Compiler-Bauer zwar noch keine Schwerverbrecher, aber immerhin schon Straftäter, oder?

PS: Über die "doppelten" eckigen Klammern (U+27E6 MATHEMATICAL LEFT WHITE SQUARE BRACKET und U+27E7 MATHEMATICAL RIGHT WHITE SQUARE BRACKET), die wie oben in ASCII oft als "[|" bzw. "|]" dargestellt werden, habe ich schon mehrfach gehört, dass sie "Oxford-Klammern" heißen, kann aber keine Literatur dazu finden. Falls also schon jemand etwas davon gehört haben sollte, bin ich über jeden Hinweis dankbar. [Nachgereicht: Ein Leser war so freundlich, in dem Kontext auf diesen Link hinzuweisen.] ()