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.