Die allermeisten Menschen in Deutschland sprechen deutsch, und fast spricht auch jeder englisch, manche können französisch oder spanisch reden, andere versuchen sich in Mandarin oder Japanisch. Fragt man hingegen, ob jemand C++ beherrsche, oder Java, oder ob jemand wohl in der Lage wäre, ein wenig COBOL zu verstehen, sieht die Sache meistens anders aus.
Und das ist eigentlich absurd. Programmiersprachen umgeben uns, sie sind ein wesentlicher Bestandteil der Geräte, die wir tagtäglich benutzen, und damit unserer Welt. Sie sind alltäglich. Von der Digitaluhr an der Wand über das moderne Autoradio bis zu den Raketen der Nasa, den Drohnen des Militärs, den Zügen der Bahn und den PCs, Tablets und Mobiltelefonen in unseren Wohnungen: Alle diese Geräte enthalten kleine Computer, und all diese kleinen Computer müssen programmiert werden, damit geschieht, was geschehen soll.
Und all diese Programme, die man heute wie selbstverständlich nutzt, von Schreibprogramm und Tabellenkalkulation bis hin zum Browser oder zu Spielen wie Solitär und Tetris oder Half-Life und GTA, wurden von irgendeinem Menschen in irgendeiner Programmiersprache oder - häufiger - von mehreren Menschen und in mehreren Programmiersprachen geschrieben.
Die Geschichte der Programmiercodes beginnt mit einem Misserfolg
Doch ähnlich, wie man sich juristische Schreiben sicherheitshalber von einem Anwalt erklären lässt (obwohl sie eigentlich auf Deutsch verfasst sind), blickt man auf Programmcode und kann nur hoffen, dass es andere Menschen gibt, die sich damit auskennen und schon wissen, was sie da tun. Man sieht die Zeichen, erkennt sogar die einzelnen Wörter, aber der Gesamtzusammenhang entzieht sich, und man bleibt abhängig von denen, die diese Sprache verstehen.
Die Geschichte der Programmiersprachen beginnt in Deutschland, und zwar mit einem Misserfolg. Konrad Zuse entwarf in den Vierzigerjahren die Programmiersprache Plankalkül, die gemeinhin als die erste höhere Programmiersprache gilt. Doch dann kam der Zweite Weltkrieg, und das Nachfolgemodell des Z-3-Rechners, für den die Sprache gedacht war, wurde nie gebaut. Plankalkül wurde deshalb auch niemals praktisch eingesetzt. Die erste Programmiersprache, die auch tatsächlich eingesetzt wurde, ist deshalb Fortran. Sie wurde 1954 von IBM entwickelt.
Von den ersten Programmiersprachen in den Fünfzigerjahren war es dann ein langer Weg mit vielen Abzweigungen bis hin zu den jüngsten Entwicklungen. Bei einem Blick auf den Stammbaum der Programmiersprachen kann einem etwas schwindelig werden, so viele gibt es inzwischen. Wer soll die denn alle beherrschen? Und: Braucht man sie überhaupt alle?
Viele Programmierer, viele Sprachen
Das sind berechtigte Fragen, aber wer sich auskennt, wechselt vielleicht lieber das Thema, als zu antworten. Denn dass es so viele Programmiersprachen gibt, hängt sicher auch mit einer nicht immer sympathischen Eigenheit vieler Informatiker zusammen: Sie wissen vieles immer besser.
Von ein paar Spezialfällen mal abgesehen, kämen zum Beispiel Linguisten kaum auf die Idee, eine neue Sprache entwickeln zu wollen. Ungeduldigen Informatikern ist das hingegen durchaus zuzutrauen. Schneller, besser, eleganter, mächtiger, höher, weiter und nicht zuletzt cooler soll die neue Programmiersprache sein. Das heißt: Sie soll es ermöglichen, komplizierte Anweisungen in weniger und verständlicherem Code zu schreiben. Und weil sie auch noch mehr können soll als andere Programmiersprachen, ist sie - in den Worten der Informatiker - auch "mächtiger".
Welche Sprache in diesem Klima überlebt, entscheidet der Markt nach dem Darwin-Prinzip. Im Ökosystem der Programmiersprachen gilt "survival of the fittest" genauso wie für Darwins Finken. Allerdings hat hier die Natur weniger die Hände im Spiel als technische und wirtschaftliche Rahmenbedingungen und Entwicklungen.
So schwimmt zum Beispiel COBOL, der Quastenflosser der Programmiersprachen, immer noch quietschlebendig im Großrechnermeer von Banken und Versicherungen umher, während die COBOL-Programmierer langsam, aber sicher aussterben. Oder zumindest in Rente gehen. Die Systeme, die auf COBOL basieren, sind einfach zu weit verbreitet und funktionieren bis heute so gut, dass sich bislang niemand an die komplizierte und teure Aufgabe machte, sie zu ersetzen.
Ein Revival erlebte in den letzten Jahren das oft verpönte Java-Script. Lange Zeit war es wegen seiner Unkompliziertheit und seiner Toleranz gegenüber nachlässigen Programmierstilen in Fachkreisen verschrien, doch die Entwicklungen des Internets und die neuen Erwartungen der Nutzer an Webseiten ermöglichten das Comeback der Skriptsprache. Java-Script lässt Webseiten vielseitiger und flexibler auf die Aktionen des Nutzers reagieren. Im Fachjargon würde man an dieser Stelle von "dynamischen" Webseiten im Gegensatz zu "statischen" Webseiten reden.
Wirtschaftliche Interessen waren hingegen bei der Verbreitung der Programmiersprache Objective-C im Spiel. Sie wurde in den 80er-Jahren als Erweiterung für C entwickelt. Objective-C ist maßgeblicher Bestandteil der Betriebssysteme aller Apple-Geräte.
Wer also Apps für das iPhone entwickeln möchte, kam bis vor ein paar Monaten nicht oder nur mit sehr viel Mühe an Objective-C vorbei. Wer ein iPad oder einen Mac besitzt, hat viele Hunderttausend Zeilen Programmcode in Objective-C zu Hause. Im Juni 2014 stellte Apple endlich eine Nachfolgesprache vor, die alles besser, einfacher und schöner machen soll, und die einen hübschen Namen zum langen Stammbaum der Programmiersprachen hinzufügt: Swift!
Auch Programmiersprachen basieren auf Alphabet, Vokabular, Syntax und Grammatik
Damit gibt es jetzt eine weitere Sprache, die im Grunde exakt das kann, was alle Sprachen können: Alle Programmiersprachen sind nichts anderes als formale Sammlungen von Rechenvorschriften, die von einem Computer ausgeführt werden können. So weit, so trocken.
Anders gesagt: Wie andere Sprachen auch besteht eine Programmiersprache aus einem Alphabet, einem Vokabular, einer Syntax und einer Grammatik. Üblicherweise basieren Programmiersprachen auf der englischen Sprache, wer Englisch versteht, kann oft erraten, was bestimmte Anweisungen bewirken sollen. Zudem hat sich auch ein gewisser Grundwortschatz herauskristallisiert, der den meisten höheren Programmiersprachen gemein ist, so dass man als erfahrene C++-Programmiererin nicht vollkommen hilflos vor dem Code eines Java-Programmes steht.
So ist es nicht verwunderlich, dass das Erlernen einer neuen Programmiersprache mit etwas Erfahrung deutlich einfacher ist als etwa das Erlernen von Polnisch, wenn man schon Deutsch, Englisch und ein bisschen Italienisch kann.
Fehler verzeihen sie nicht
Ein Beispiel verdeutlicht das: Wenn ein Programmierer auf einem Bildschirm etwas anzeigen möchte, benutzt er je nach Programmiersprache die Anweisung "print", "write", "alert", "display", "put" oder einen anderen Befehl: Er druckt, schreibt, alarmiert, setzt oder zeigt etwas an. Welches Wort genau er in welcher Sprache verwenden muss, muss der Programmierer erst lernen und sich dann merken, und zwar ganz genau. Denn Programmiersprachen sind streng, sie verzeihen keine Fehler. Wenn die gewählte Sprache also ein "write" erwartet, wird sie bei einem "print" nicht selbständig auf die Idee kommen, dass möglicherweise "write" gemeint gewesen sein könnte. Stattdessen wird sie entweder nichts tun oder frustriert das Programm zum Abstürzen bringen. Ein Fehler im Code. Dagegen würde ein Münchner Bäcker vielleicht auch etwas frustriert gucken, aber trotzdem eine Semmel verkaufen, obwohl er nach einem Brötchen gefragt wurde.
Das klingt zunächst so, als ob es beim Programmieren wenig Raum zur kreativen Vielfalt gäbe. Schließlich sind Programmiersprachen sensible, pedantische Wesen, die genau wissen, was sie wollen (und vor allem was nicht). Doch das ist nur die halbe Wahrheit: Auch innerhalb des strengen Korsetts einer Programmiersprache gibt es genug Raum, so dass sich Programmierer darüber streiten können, ob Einrückungen im Code nun aus zwei oder vier Zeichen bestehen sollen, welche Namenskonventionen für Variablen gelten oder ob erklärende Kommentare im Code ein Indiz für guten oder schlechten Programmierstil sind.
Für viele Fragen gibt es durchaus gute, sachliche Argumente auf beiden Seiten. Andere Diskussionen hingegen werden eher auf der Basis persönlicher Vorlieben geführt und entpuppen sich schnell als wenig zielführend. Das hat allerdings bis jetzt noch keinen Programmierer davon abgehalten, diese Glaubenskriege immer und immer und immer wieder neu auszufechten. Wie gesagt: Manche wissen es gerne besser.
Betrachtet man die Taxonomie der Programmiersprachen, so ist eine der wichtigsten Unterscheidungen die zwischen den Hochsprachen und den Maschinen-, den Assemblersprachen. Historisch gesehen kamen Letztere zuerst, sie hängen nämlich, wie der englische Name schon sagt, sehr viel enger mit den Maschinen zusammen, auf denen die Programme ausgeführt werden. Darüber hinaus sind sie aus der Sicht des Computers weniger abstrakt, was für den Programmierer wiederum bedeutet, dass man sich bei der Arbeit um wirklich jedes Detail selbst kümmern muss. Hochsprachen hingegen weisen einen höheren Grad an Abstraktion zu der darunterliegenden Technik auf, sind dafür aber für den Menschen leichter zu verstehen und nehmen ihm lästige Arbeiten ab.
Kreative Programmierer: Filmzitate, Shakespeare-Dramen - alles dabei
Wenn man sich nun - stark vereinfacht - zum Beispiel den Speicher eines Computers, also den Teil, der sich Zwischenergebnisse merken kann, als eine Kommode mit vielen Schubladen vorstellt, dann muss die Assemblerprogrammiererin dem Computer en détail erklären, welchen Wert er denn in welche Schublade legen soll. Sie teilt ihm also mit, er möge bitte ein virtuelles blaues Bällchen in Schublade 26 legen. Möchte sie das blaue Bällchen wiederhaben, so muss sie dem Computer auch sagen, dass es in Schublade 26 steckt. In einer Hochsprache dagegen reicht es aus, dem Computer mitzuteilen, er soll das blaue Bällchen einfach irgendwo in die Kommode stecken, da, wo noch Platz ist, und wenn man es dann wieder braucht, wird das Programm eigenständig in der Lage sein, es zu finden.
Was danach auf der Transistorebene im Computer passiert, ist mehr oder weniger immer das Gleiche, allerdings werden, je höher und damit abstrakter die Programmiersprache ist, mehr Übersetzungsschritte benötigt, bis am Ende etwas herauskommt, das der Computer auch verstehen kann. Diese Übersetzungen muss der Programmierer nicht selbst machen. Das übernehmen spezielle Programme, die Compiler heißen. Während Assemblercode direkt in die dringend benötigten Nullen und Einsen übersetzt werden kann, wird Code in einer Hochsprache unter Umständen erst in Code einer anderen weniger abstrakten Hochsprache, dieser dann wiederum in Assemblercode und dieser dann in einem letzten Schritt in für den Computer verständliche Anweisungen übersetzt.
Dass Hochsprachen immer lesbarer werden, bedeutet allerdings leider nicht, dass das Programmieren einfacher würde. Schon seit den frühen Fünfzigerjahren - also ungefähr so lange, wie es Programmiersprachen gibt - glaubt man fest daran, dass Programmiersprachen irgendwann so einfach werden, dass jeder selbst programmieren kann. Tatsächlich wurde dieses Ziel in den letzten sechzig Jahren zuverlässig eben nicht erreicht.
Nach dem zehnten Geburtstag: veraltet
Dies liegt unter anderem daran, dass die Entwicklungen in der Software denen der Hardware konsequent hinterherhinken. Programme, die vor zehn Jahren noch vollkommen ausreichend waren, wirken heute hoffnungslos veraltet. Wenn die Geräte leistungsfähiger werden, muss die Software nachziehen. Das kann sie aber immer nur bedingt. Neue Entwicklungen müssen her, und das bedeutet leider meistens, dass es komplexer wird. Auch der Anspruch an die Funktionalität von Programmen nimmt eher zu als ab, es gibt ständig neue und mehr Geräte, kleine Telefone, flache Tablets, die man bei der Entwicklung bedenken muss, und wenn man gerade glaubt, man hätte so weit alles verstanden, kommt irgendwer mit einem ganz neuen Programmierkonzept daher.
Das muss allerdings nicht immer ganz ernst gemeint sein. Einen guten Beweis für die Kreativität vieler Programmierer bilden die esoterischen Programmiersprachen, die wohl kaum für ernsthafte Softwareprojekte eingesetzt werden, dafür aber immerhin für Erheiterung sorgen können. ArnoldC besteht zum Beispiel aus Zitaten aus Arnold-Schwarzenegger-Filmen, in der Sprache Shakespeare sehen die Programme aus wie Shakespeare-Dramen. Und dann gibt es da noch Whitespace. Code in dieser Sprache kann man nicht sehen. Doch das Geheimnis lässt sich schnell lüften: Er besteht ausschließlich aus Leerzeichen, Tabulatoren und Zeilenumbrüchen anstelle von Buchstaben, Sonderzeichen und Zahlen.
Das Aha-Erlebnis, das Whitespace lehrt, gilt fürs ganze Programmieren: Wenn man es erst mal begriffen hat, ist es halb so schwer. Wenn man zum Beispiel sowieso mit einem Sprachkurs liebäugelt, kann man durchaus auch überlegen, ob man sich nicht demnächst einfach mal mit dem Erlernen einer Programmiersprache beschäftigen möchte. Es lohnt sich.
Die Autorin arbeitet als Softwareentwicklerin in Essen. Sie bloggt unter www.anneschuessler.com.