Reden Sie mit Ihrem Computer? – Seite 1

In Maschinen bauen wir immer ein Stück von uns selbst mit ein, meint ZEIT-Redakteur Gero von Randow, 61. Und das hat überraschende Effekte. © Nicole Sturz/​Cornelia Pflüger

Es gibt scheinbar abstrakte Fragen, die von höchst praktischer Bedeutung sind. Zu diesen Fragen gehört die, ob Programmiersprachen überhaupt Sprachen sind.

Von praktischer Bedeutung ist sie, weil beispielsweise die Forderung erhoben wird, den Schulunterricht in einer Computersprache mit dem in einer Fremdsprache gleichzusetzen. Eine andere lautet, die Programmierer einer journalistischen Website als Redakteure anzusehen. Und drittens ist die Frage nach dem Sprachcharakter des Programmierens deswegen wichtig, weil die Software, die uns die Dinge des Alltags in die Hand gibt, sehr davon abhängt, wie die Programmierer ihre Rolle sehen: Bringen sie in erster Linie Sachen zum Laufen oder arbeiten sie mit den Usern zusammen?

Um der Frage näher zu rücken, ist es sinnvoll, sich mit der Geschichte der Sprachmetapher in der Informatik zu befassen. Diesem Thema widmet sich ein Forschungsprojekt, dessen Ergebnisse unlängst veröffentlicht wurden (Nofre et al., 2014). Von "machine language" war danach schon in den späten vierziger Jahren des vorigen Jahrhunderts die Rede, doch so richtig verbreitete sich die Sprachmetapher in den Fünfzigern.

Damals nämlich wuchs die Zahl der installierten Computer rapide, und mit ihr die Vielfalt der verwendeten Rechner. Wurden diese Maschinen bis dahin stets nach jeweils eigenen Regeln programmiert, wuchs nun das Interesse an allgemeingültigen Beschreibungen der Algorithmen. Dadurch löste sich gewissermaßen der Geist von der Materie, Software wurde ein eigener Forschungsgegenstand – was man auch als Rückkehr zu den Ursprüngen betrachten kann. Denn mathematisch verifizierbares Programmieren war als Konzept für Papier, Bleistift und Gehirn entstanden. Schon die Turing-Maschine, die geistige Urmutter der Computer, war ein Gedankenkonstrukt ohne Schalter oder andere Hardware.

Der Mensch befiehlt, der Computer rechnet

Um das Programmieren von seiner Bindung an einzelne Maschinentypen zu lösen, entstanden "Hochsprachen", die eine Doppelfunktion hatten. Erstens erlaubten sie dem Programmierer, Einzelaktionen der Rechner zu Gruppen zusammenzufassen, ihnen einen sprechenden Namen zu geben (wie zum Beispiel PRINT) und daraus übersichtlichere Programme zu stricken. Und zweitens konnten diese Programme nun mit anderen Programmierern diskutiert werden, unabhängig davon, vor was für Rechnern diese nun im Einzelnen saßen.

Dass sich die Sprachmetapher in Windeseile durchsetzte, mag im Übrigen auch, so spekulieren die zitierten Forscher, mit der Präsenz von Begriffen wie "Roboter" oder "Elektronengehirn" zu tun haben, wie sie bereits in der ersten Hälfte des 20. Jahrhunderts in die Literatur und die Populärwissenschaft eingedrungen waren, ja sogar in die Wissenschaft (in Form der Kybernetik, der Lehre von selbstregulierenden Systemen).

Da lag es nahe, die Regeln für die Programmierung eines Computers als Sprache zu beschreiben, in der mit dem Computer gesprochen wurde, und zwar im Befehlsmodus: Der Mensch gibt das Kommando, der Computer führt aus, nachdem entweder ein Interpreter oder ein Compiler seine Arbeit getan hatte. Der Interpreter übersetzte das eingegebene Programm Befehl für Befehl in maschinelle Sequenzen, oder ein Compiler machte aus dem Programm in einem Rutsch eine Folge von Anweisungen an seinen Prozessor.

Die Entstehung von geräteunabhängigen Hochsprachen war auch von Anfang an ein Kampffeld von Interessen – und sollte es bleiben. Die drei großen Spieler hießen Militär, Unternehmen und Universitäten (an denen mit der Verselbständigung des Programmierens die Computer Science entstand, ein Name, in dem noch die Bindung an die Maschinen nachklang, heute spricht man lieber von Informatik); waren sie auch allesamt miteinander verschränkt, achtete zugleich jeder darauf, von den anderen nicht abgehängt zu werden.

Eine institutionelle Lösung des Problems bot die bereits 1947 gegründete Association for Computing Machinery (ACM), die bis heute eine Plattform der Informatiker und eine Art Schiedsrichter ist. Mit der ACM festigte sich die Sprachmetapher endgültig, so wie ja auch im sogenannten richtigen Leben Sprache und Staat eine Art Co-Evolution durchlaufen.

Fragt sich nur, wie treffend die Sprachmetapher ist. Aus der Informatik selbst kommen skeptische Stimmen. So heißt es etwa in dem verbreiteten Lehrbuch Think Python – How to Think Like a Computer Scientist, dass es drei gravierende Unterschiede zwischen natürlichen und Programmiersprachen gebe. Erstens sind natürliche Sprachen mehrdeutig, was ihre Stärke ist; Programme hingegen müssen eindeutig sein. Zweitens sind sie redundant, damit die Botschaft auch wirklich verstanden wird; Programme indes geben jede Anweisung nur einmal (kürzlich knallten Apple-Rechner weltweit durch, weil ein Befehl aus Versehen doppelt eingegeben worden war). Und drittens ist in Programmen stets alles wörtlich gemeint.

Programmieren ist Kommunikation zwischen Menschen

Auf das genannte Python-Buch hatte mich ein Posting auf der Website des Economist aufmerksam gemacht, das ausdrücklich die Sprachmetapher ablehnt. Interessant sind die Kommentare unter dem Posting, denn sie weisen auf die Stärken der Metapher hin. Einer der User zitiert den bekannten Softwareentwickler Martin Fowler: "Jeder Idiot kann Code schreiben, den ein Computer versteht. Gute Programmierer schreiben Code, den Menschen verstehen können."

Das ist der Kern. Damit ist nicht etwa bloß gemeint, dass gute Programmierer sprechende Bezeichnungen verwenden sollen (also nicht "Zähler eins" schreiben, sondern zum Beispiel "Zähler für Login-Versuche") und auch nicht nur, dass sie Kommentare hinter ihre Zeilen setzen (etwa "dieser Befehl ruft das Unterprogramm 'Zähle die Login-Versuche auf'). Sondern man soll ihre Programme wie ein Stück Prosa lesen können. Vorausgesetzt, der Leser beherrscht die Sprache.

Im Grunde genommen ist diese Forderung eine Teilmenge einer anderen, nämlich: Schreibe für Menschen! Also für andere Programmierer, außerdem für Leute, denen du dein Programm erklären willst, und vor allem für die User. Die müssen zwar nicht den Code verstehen, aber das Verhalten der Maschine muss für sie nachvollziehbar und plausibel sein. Legendär der Verstoß früherer Windows-Versionen gegen dieses Prinzip, in denen man auf "Start" klicken musste, um das Programm zu BEENDEN.

Sprachen lernen heißt Kulturen verstehen

Programmieren ist also Kommunikation zwischen Menschen. Die Maschine ist da nur ein Zwischenschritt. Insofern ist die Sprachmetapher, wenn man sie nicht überreizt, schon ganz gut. Natürlich ist es Unsinn, Programmierunterricht als eine Art Fremdsprachenunterricht anzusehen. Und erst recht falsch wäre es, den einen durch den anderen ersetzen zu wollen. Richtig an dem Vergleich aber ist: Das Erlernen einer Fremdsprache (auch einer toten wie Latein) bedeutet, eine Kultur zu verstehen – und das gilt ebenso für Programmiersprachen. Schon deshalb sollten sie Pflichtfach sein.

Für uns Journalisten ist es durchaus von Vorteil, einmal ein einigermaßen komplexes Programm von innen betrachtet zu haben, bevor wir über Computer, Algorithmen und das Internet schreiben. Und für den Onlinejournalismus gilt, dass die organisatorische Trennung von schreibenden und programmierenden Kollegen schrittweise überwunden werden sollte.

Gewiss, es sind verschiedene Tätigkeiten. Doch so wie wir Schreiber allmählich gelernt haben, Hand in Hand mit Layoutern und Grafikern zu arbeiten, die eigene und gleichberechtigte Anforderungen an eine gedruckte Seite oder eine Website stellen, müssen wir lernen, dass Programmierer nicht einfach bloß die Gefäße bereitstellen, in die wir unsere Texte gießen. Nein, sie definieren (und das immer raffinierter) genauso wie wir die Art und Weise, wie der Leser/User mit dem umgehen kann, was ihm auf dem Bildschirm geboten wird. Schreiben, Gestalten und Programmieren gehören zusammen, und zwar nicht erst dann, wenn der Text fertig ist. In einer idealen Welt bauen Schreiber, Gestalter und Programmierer gemeinsam einen oder zwei oder drei Prototypen, bis das Produkt steht.

Man verzeihe mir den selbstbezüglichen letzten Absatz. Er ist mir durchgerutscht, aber weil er mit Herzblut geschrieben wurde, bleibt er jetzt drin. Und auch, weil er das Mantra dieser Kolumne widerspiegelt: Technik, das ist keine Ansammlung von Sachen, sondern eine Abfolge von Handlungen.