Babel-Bulletin 06.04.11
In der letzten Zeit habe ich mich so intensiv wie nie zuvor mit Programmiersprachen beschäftigt – weswegen ich auch zu fast nichts anderem mehr gekommen bin. Sich in eine andere Sprache hineinzudenken ist ein bisschen, wie in ein anderes Land zu fahren. Grundsätzlich ist einem so ziemlich alles bekannt, und man findet sich eigentlich ganz gut zurecht. Aber alle Nase lang wird einem doch klar, dass es ein fremdes Land ist, in dem die Gepflogenheiten zu verschieden sind, als dass man sie noch als gewohnt durchgehen lassen könnte.
Schon der eine oder andere fremdländische Spion ist entlarvt worden, weil er Dinge getan hat, die ähnlich, aber doch ein bisschen zu verschieden waren, um sie noch als einheimisch anzusehen. Ein Beispiel findet sich dazu in dem Film "Inglourious Basterds" von Quentin Tarantino aus dem Jahr 2009. In dem Film (der es im IMDB-Ranking immerhin auf Platz 91 innerhalb der Top 250 geschafft hat) bestellt einer der fremdländischen, als Deutsche verkleideten Helden Getränke, wobei er dem Wirt die entsprechende Anzahl Finger zeigt – ohne den Daumen dazu zu benutzen. Dadurch wird er als Nicht-Deutscher entlarvt, und die geplante stille Aktion endet in einem Blutbad.
Ein Freund von mir wusste Vergleichbares aus Asien zu berichten. Nein, nicht das mit dem Blutbad, das mit den Fingern. Er war ein Jahr lang mit Holiday on Ice auf Asien-Tournee und musste dort immer wieder feststellen, dass er, von was auch immer er eine bestimmte Anzahl wollte, eins zu wenig bekam. Bis er herausbekam, dass die "Angesprochenen" seinen Daumen ignorierten, wenn er ihnen mit dessen Hilfe die gewünschte Anzahl zeigte.
Bei Programmiersprachen verhält es sich ähnlich, wenn man versucht, seine Gewohnheiten zu übertragen. Grundsätzlich funktioniert das, was man überträgt, schon irgendwie, aber für eine "falsche" Anwendung wird man in der Regel in irgendeiner Form bestraft. In einem Blutbad mag es zwar nicht enden, aber in einem geeigneten Umfeld kann es doch gehörigen Schaden anrichten.
Natürlich ist gegen einen seichten Übergang nichts einzuwenden. Blickt man in die Vergangenheit von C++, so stellt man fest, dass es oft gar nicht im Zusammenhang mit der Objektorientierung verwendet wurde. Vielmehr machte man sich nur das deutlich zuverlässigere Typsystem zunutze – C++ als besseres C. Es wäre ja auch schlimm, wenn man nicht mit einem kleinen fremden Wortschatz umschreiben dürfte, was in einem Wort – würde es einem nur einfallen – gesagt werden kann. Und dazu bedarf es noch nicht einmal einer Fremdsprache – bei fehlenden Fremd- oder Fachwörtern geht es einem ja genauso.
Aber C++ ist auch ein schönes Beispiel dafür, dass man seine Ansichten bei einem Sprachwechsel ändern muss. Von jeher ist bekannt, dass eine for-Schleife immer die Form
for (int i = 0; i < n; i++)
hat. Eine kleine Änderung kann da schon fatale Interpretationsfehler zur Folge haben. So ist die Schleife
for (int i = 1; i <= n; i += 1)
zwar im Wesentlichen äquivalent (zumindest was die Häufigkeit anbetrifft), wird aber den geneigten Leser zunächst verwirren und unnötig zum Denken anhalten.
Im Zusammenhang mit dem Überladen von Operatoren tut sich hier aber ein Problem auf, bei dem sich der Unterschied zwischen i++ und ++i deutlich bemerkbar macht. Ersteres erfordert nämlich eine Kopie des Objekts das geliefert wird, während das Originalobjekt inkrementiert wird. Zweiteres hat es da viel einfacher, denn hier kann das Originalobjekt erhöht und unmittelbar als Ergebnis geliefert werden.
Da das Kopieren des Objekts beliebig aufwendig sein kann, versucht man natürlich, sich dieses zu ersparen, wenn man es – wie in der for-Schleife – gar nicht benötigt. Also findet man im C++-Umfeld sehr häufig die Variante
for (int i = 0; i < n; ++i),
damit die überflüssige Kopie nicht dauernd erzeugt wird.
In der Programmiersprache D wird diese "Problem" übrigens dadurch gelöst, dass es nur einen Inkrement- (und analog einen Dekrement-)Operator gibt. Dieser wird dann so verwendet, dass im Falle von i++ das Erzeugen der Kopie eigenständig vom Übersetzer eingefügt und im Falle von ++i darauf verzichtet wird. Und da es dem Übersetzer nicht schwerfällt, den Kontext zu erkennen, muss die Kopie natürlich nur dann von ihm erzeugt werden, wenn sie auch wirklich benötigt wird.
Bei den obigen Beispielen handelt es sich "nur" um Trivialitäten. Wenn es also um wirklich wichtige Dinge gibt, muss man schon sehr vorsichtig sein. Das ist gerade dann der Fall, wenn sich die Dinge in den unterschiedlichen Ländern und Sprachen scheinbar so ähnlich sind.
So berichten Geschäftsleute gerade im Zusammenhang mit den USA, die uns in vielerlei Hinsicht so ähnlich sind, von unerwarteten Problemen. Die Handelskammern empfehlen deshalb auch Schulungen über das Geschäftsgebaren der US-Amerikaner. Bei Chinesen und Japanern taucht das Problem deutlich weniger auf, weil dort jeder weiß, dass sie die Dinge anders machen. So haben die meisten schon einmal etwas davon gehört, dass schon das Überreichen einer Visitenkarten zu einem kleinen "Staatsakt" ausarten kann.
Oftmals reicht es übrigens schon, das Bundesland zu wechseln. Wenn man als Rheinländer nach Franken oder Bayern kommt, kann man schon die eine oder andere Überraschung erleben. Wer das nicht so recht glauben kann, dem sei die sehr schöne Beschreibung chinesischer und bayerischen Eigenheiten und deren Kompatibilitätsprobleme empfohlen, die sich in "Briefe in die chinesische Vergangenheit" von Herbert Rosendorfer finden. (Eine kleine Einführung zu den Briefen findet sich auch bei Dieter Wunderlich.)
Desgleichen gilt für Programmiersprachen. Bei einem (auch nur kurzen) Wechsel empfiehlt es sich also, auch einmal einen Blick unter die Haube zu werfen, um besser erkennen zu können, ob die gewohnten Mechanismen noch taugen. So kann man sich viel Ärger ersparen und neue Wege entdecken, Probleme zu lösen.
Nicht dass ich glaube, eine neue Sprache kennen zu lernen sei genau so spannend, wie ein neues Land zu erkunden, aber es doch hat auf jeden Fall seine Reize, oder?
Michael Wiedeking ist Java-Programmierer der ersten Stunde, schreibt regelmäßig Artikel und spricht auf Konferenzen im In- und Ausland. Am liebsten aber "sammelt" er Programmiersprachen und beschäftigt sich mit ihrem Design und ihrer Implementierung.