Polyglot Programming, oder: Wie Open Source das Programmieren veränderte

Inhaltsverzeichnis

Open Source hat einen großen Einfluss auf die Art, wie Programmiersprachen entstehen und welche von ihnen zur Entwicklung quelloffener Projekte genutzt werden. Das ständige Erscheinen neuer Sprachen macht die Entscheidung schwer, mit was man sich als Nächstes beschäftigen soll.

Eine häufig gestellte Frage ist: "Ich möchte anfangen zu programmieren, aber welche Sprache soll ich lernen?" Dicht gefolgt von: "Ich schreibe in X, aber ich möchte etwas anderes machen – welche Sprache sollte ich mir ansehen?" Früher gab es auf diese Fragen vorgefertigte Antworten, deren Vor- und Nachteile sich über Kaffee oder Bier diskutieren ließen. Doch die Kultur und die Verbreitung von Open Source haben das geändert. Jetzt gibt es darauf nur noch eine Antwort: "Alle."

Das heißt nun nicht, dass man jede existierende Sprache heraussuchen und so lange seitenweise Quellcode studieren soll, bis man in allen flüssig programmieren kann. Um genau verstehen zu können, was stattdessen zu tun ist, sei kurz die Geschichte der Computersprachen rekapituliert.

Es war einmal

In der Frühzeit der Computer war es teuer, Software zu schreiben. Handgefertigter Maschinencode diente als Grundlage für Compiler, die andere Software erzeugen konnten. Der Aspekt des Handgemachten benötigte viel Zeit und Energie, sodass Sprachen anfänglich für verschiedene Domänen beziehungsweise Industrien entworfen wurden: COBOL war für Unternehmen, FORTRAN für die Wissenschaft und so weiter. Unternehmen verdienten Geld durch die Herstellung proprietärer Compiler. In Wissenschaft und Forschung begann dann jedoch die Jagd nach einer Sprache für die Computerwissenschaften, und während einige versuchten, eine höheres Level an Abstraktion für Maschinencode zu erstellen, versuchten andere die Maschine zu abstrahieren. So entstanden BPCL, C und andere Sprachen als High-Level-Abstraktionen, und virtuelle Maschinen nutzten Lisp und P-Code, um abstrakte Maschinen zu erschaffen. Obwohl Ideen und Konzepte oft geteilt wurden, Compiler und VM-Code wurden es nicht.

Ein besonderer Schwachpunkt lag für Softwareentwickler in Unix, wo C-Compiler sehr teuer waren. Viele Unix-Systeme, wie die frühen Versionen von SunOS, kamen zwar mit einem C-Compiler, der aber wurde selten gepflegt. Da ein C-Compiler eine essenzielle Rolle in der Herstellung eines freien Software-Betriebssystems, wie es das GNU-Projekt im Auge hatte, spielen sollte, kam der GNU C Compiler erstmals 1987 auf den Markt. Mit der Zeit entwickelte sich GCC in ein stabiles Projekt und diente aufgrund seiner modularen Struktur jedem als Backend zum Erstellen von Code, der einen eigenen Compiler für andere Sprachen entwickeln wollte.

Im selben Jahr erschien auch eine andere Sprache: Perl. Zu Anfang eher als ein Werkzeug mit eigener Sprache als eine eigene Sprache wahrgenommen, zog Perl aus, um eine effiziente Sprache zum Extrahieren und Reduzieren von Logs und anderen Informationen in Berichten zu bieten. Dieser Rahmen wurde schnell erweitert und der Charakter von Perl lud viele Entwickler zum Experimentieren und Erstellen eigener Sprachsyntax und Werkzeuge ein.

Säen und ernten

GCC und Perl leisteten eine gute Arbeit darin, Entwicklern Werkzeuge zum Erstellen von Sprachen an die Hand zu geben. Der GNU C Compiler, der sich mit der Zeit zur GNU Compiler Collection entwickelte, konnte standardmäßig bald mit C, C++, Java, Objective-C, FORTRAN und Ada umgehen, plus vielen anderen. In der Folge von Perl gelangten Python und Ruby in den Mainstream, beide mit unterschiedlichen Wegen, eine Skriptsprache anzugehen. Python bot eine leerzeichensensitive, menschenlesbare Syntax, deren Fokus auf Lesbar- und Verständlichkeit sie ideal zum gemeinschaftlichen Entwickeln von Skripten machte. Ruby verband hingegen etwas von der Perl-Syntax mit Smalltalk-Ideen zu einer faszinierenden Sprache. Sie gewann an Sichtbarkeit, als das schnell Verbreitung findende Framework zur Webentwicklung Rails in ihr verfasst wurde. All diese Sprachen sind quelloffen und freie Software.

Die polyglotte Zukunft

Auch wenn sie erst später quelloffen werden sollte, hatte die Java Virtual Maschine ebenfalls ihren Einfluss. Erst wurde Python, später dann Ruby in eine auf der JVM gehostete Sprache gewandelt, die sich auf der JVM in Bytecode kompilieren und dort ausführen ließ. Skriptsprachen konnten von der Just-In- Time-Kompilierung und den umfangreichen Bibliotheken der JVM profitieren. Andere sahen das Konzept und entwickelten es weiter, sodass neue Sprachen wie Scala entstanden, die durch ihren Aufbau als Alternative für Java selbst dienen sollten.

Dann kam das LLVM-Projekt, dass zu Anfang durch den enthaltenen Just-In-Time- oder Ahead-Of-Time-Compiler in Javas Bereich einzudringen schien, sich aber mittlerweile in ein Projekt entwickelt hat, dass der Open-Source-Welt eine ganze Bandbreite von Compiler- und Analysewerkzeugen bereitstellt. Besonders bekannt ist hier der alternative C- und C++-Compiler Clang. Die Low-level-VM-Teile der LLVM wurden auch dazu genutzt, leistungsfähigere Versionen einiger Skriptsprachen zu entwickeln.

Eines der so angestoßenen Projekte ist JavaScript, die lange eher stiefmütterlich behandelte Skriptsprache für das Web. Nachdem einige Entwickler sie in den 2000er-Jahren wiederentdeckt haben, forderte die moderne Webentwicklung eine Beschleunigung von JavaScript, und so erschienen JIT-Compiler, Analysemodule und Werkzeuge in den Browsern, die genau das ermöglichten. Das wiederum brachte Entwickler dazu, JavaScript als Grundlage für eigene Sprachen wie CoffeeScript und TypeScript zu nehmen, die man in JavaScript kompilieren kann, und die die Sprache zum Kern der HTML5-Entwicklung machten. Dank Node.js, einer JavaScript-Laufzeitumgebung, die um Googles JavaScript- Engine V8 herum entwickelt wurde, konnte sich JavaScript dann ganz aus dem Browser befreien – wobei auch V8 quelloffen ist.

Die polyglotte Zukunft

An diesem Punkt ist man in der Gegenwart der Programmiersprachen angelangt. Die Jagd nach einem besseren C geht weiter – C++ konnte sich nie von seinen altertümlichen C-Wurzeln lösen. Die bekannteste der Alternativen ist Googles Go, die viele Anhänger aufgrund des Entwickler-Credos "Wie C wäre, wenn wir es heute machen würden" gewinnen konnte. Go nimmt die praktischen Elemente der objektorientierten und funktionalen Sprachen eher auf einem Sprach- denn auf einem Bibliothekslevel auf und setzt sie in einer Sprache zusammen, die zum Bau der Backend-Infrastrukturen des Web gedacht ist. Darüber hinaus gibt es noch Mozillas Rust – eine Sprache, die unter den Herausforderungen entstand, die mit dem Erstellen einer soliden, zuverlässigen und sicheren Plattform zum Bau von Webbrowsern einhergehen. In der Welt der Java Virtual Machine hingegen wandeln Unternehmen ihre Erfahrungen im Entwickeln von Enterprise-Anwendungen in Sprachen für genau den Zweck um: Red Hats Ceylon, JetBrains Kotlin oder, in kleinerem Rahmen, Xtend von Eclipse.

Jede dieser Sprachen gestaltet sich eine eigene Domäne, weil Open-Source-Entwickler die Werkzeuge, die zum Entwickeln einer Sprache notwendig sind, bereitstellen und die Techniken, die dazu gebraucht werden, der Allgemeinheit übergeben haben. Open Source gilt heute als Standard zur Entwicklung von Sprachen, und Sprachen lassen sich so entwerfen, dass sie spezielle Anforderungen erfüllen. Diesen
Wechsel, weg vom Bau einer allgemein gültigen Sprache hin zum Entwickeln vieler zweckgebundener Sprachen, hat auch in großen Teilen die Verfügbarkeit quelloffener Komponenten zu verantworten, die als Grundlage nutzbar sind.

Damit zurück zur eingangs gestellten Frage: Welche Sprache sollte man lernen oder als Nächstes lernen? Flexibilität ist hier der Schlüssel, außer man weiß schon genau, was das nächste Problem oder die nächste Herausforderung sein wird.

Fazit

Die Zukunft des Programmierens ist mehrsprachig. Das zeigt auch eine Umfrage im Dr. Dobbs Journal, in der es darum geht, dass Entwickler mit mehr als einer Sprache arbeiten. Was man lernen kann, ist Programmieren – nicht nur eine Sprache, sondern so viele Idiome, wie zeitlich sinnvoll sind. Man sollte die Ideen und Stilmittel dahinter lernen, nicht die speziellen Fähigkeiten, bis man die Sprache tatsächlich funktional oder fließend können muss. Es wird in der Zukunft zunehmend mehr Sprachen geben, und niemand wird plötzlich sagen: "Das reicht." Sprachen sind, wenn sie schon keine Gebrauchsgüter sind, mit Open-Source-Werkzeugen gebaut, und ihnen ist es zumindest teilweise zu verdanken, dass Entwickler nun in einem neuen polyglotten Zeitalter der Programmierung angekommen sind.

Dj Walker-Morgan
ist Chefredakteur bei der Heise-Schwester The H. (jul)