Warum gibt es so viele Programmiersprachen?

Zuballerst bitte ich um Entschuldigung: Für die Vereinfachung. Das mache ich immer, schließlich richtet sich der Blog an die (interessierte) Allgemeinheit, doch bin ich mir sicher das bei Raumfahrt und Chemie / Ernährung nur wenige Experten mitlesen. Bei diesem Thema ist es anders, vor allem gibt ex da viele selberernannte Experten und meistens kommt dann auch nach dem zweiten Kommentar die fruchtlose Diskussion auf: „Welche Programmiersprache ist die beste“. Doch darum geht es nicht, sondern warum gibt es so viele Sprachen.

Als ich mich für Computer interessierte, gab es schon Dutzende von Programmiersprachen, heute sind es noch viel mehr. Ich wage zu behaupten es gibt mehr Programmiersprachen als es Rechnerarchitekturen gibt. Aber fangen wir an es mal genauer zu beleuchten. Ich meine es gibt mehrere Gründe.

Grund Nummer 1: Es gibt so viele Programmiersprachen weil man immer leistungsfähigste Konstrukte entwickelt hat.

Oder anders ausdrückt: genauso wie sich die Hardware weiter entwickelt, so entwickeln sich auch die Softwaretechnik weiter, wobei dies Hand in Hand geht, denn mit den ersten Rechnern hätte man sicher kein System wie ADA laufen lassen können.

Anfangs gab es gar keine Programmiersprachen: die Programmierer gaben die Maschinensprache in binärer Form ein. Jedes Bitmuster stand für einen Befehl oder einen Daten/Adresswert. Die erste Verbesserung war der Assembler bei dem man für die Befehle einigermaßen verständliche Wörter ausdachte wie „Add“, „Mov“ oder „JMP“ für Addiere, Bewege oder Springe. Bis heute gilt: Mikroprozessoren verstehen nur sehr einfache Befehle. Der Assembler brachte noch eine weitere Verbesserung: Man konnte Konstanten und Variablen definieren und er kümmerte sich um die Adressberechnung denn bei Verzweigungen oder wenn Daten eingeladen werden sollten musste man Adressen angeben.

Die ersten höheren Programmiersprachen wie COBOL und FORTRAN boten eine höhere Abstraktionsebene. Man konnte und mathematische Formeln direkt eingeben, ohne sich darum zu kümmern wie der Prozessor sie berechnet. Damit waren sie zum ersten Mal unabhängig von der verwendeten Hardware. Was FORTRAN oder COBOL von den nachfolgenden Sprachen unterschied war, das beide spezialisiert waren. COBOL eignete sich hervorragend zur formatierten Datenverarbeitung wie sie bei Versicherungen, Lohnabrechnungen oder anderen betriebswirtschaftlichen Abläufen vorkommt. Gerüchteweise sollen einige BW-Ausbildungen auch COBOL Kurse enthalten. Mit  FORTRAN konnte man dagegen vornehmlich Berechnungen vor allem naturwissenschaftliche spezialisiert. Beide kannten nicht die Typisierung von Daten, man gab bei einer  FORTRAN Routine z.B. nur die Parameter an, nicht welchen Datentyp sie hatten und in der ursprünglichen Form keine Möglichkeit für strukturierte Programmierung also bedingte Schleifen. Stattdessen wurde mit GOTO im Programm herumgesprungen.  FORTRAN und COBOL waren Programmiersprachen für einen bestimmten Einsatzzweck. Das ist zwar immer gegeben, doch sie waren schon sehr eingeschränkt. Mit COBOL würde man keine mathematischen Probleme angehen (es gab die Grundrechenarten, aber nichts weitergehendes) und die Fähigkeiten von  FORTRAN Text zu verarbeiten sind doch sehr beschränkt. (der Datentyp Char wurde erst später eingeführt). FORTAN hatte anfangs sogar keine mit der Backus-Naur form definierte Grammatik. Das bewirkte bei der Raumsonde Mariner 1 einen Totalverlust, da eine Zeile wie

DO 15 I = 1.100

im Quelltext stand und da stehen sollte:

DO 15 I = 1,100

Das letztere Stand für eine zählende Schleife bei der I von 1 auf 100 hochgezählt wurde und der Schleifenblock wurde mit Anweisungsnummer (Zeilennummer) 15 beendet.

Der Compiler meldete dies jedoch nicht als Fehler, da (zumindest damals) Leerzeichen nicht als Trenner betrachte und der Punkt für den Dezimalpunkt ansah war für den Compiler die Zeile gleichbedeutend mit

DO15I=1.100

Also Zuweisung des Wertes 1.1 an die Variable DO15I ….

Die nächste Generation waren Sprachen die geeignet waren verschiedenste Problemen auf algorithmischem Wege zu lösen, also mit einer Lösungsvorschrift die man auch umfangssprachlich formulieren kann. Dazu gab es Schleifen wie die While Schleife „Mache etwas so lange … gegeben ist“ oder Repeat Schleife „Wiederhole solange bis …“ anstatt den Gotos die vorher dominierten. Dazu gehöre auch das es nun nicht nur die elementaren Datentypen des Prozessors gab sondern neue wie Teilbereiche (für Jahreszahlen sollte vielleicht ein wert von 2178 nicht zulässig sein) zusammengefasste Daten (die Bestandteile einer Person sind Name, Vorname, Telefonnummer etc…).

Dazu gehören eine Reihe von Programmiersprachen. Stammvater ist Algol, wichtige Ableger sind Pascal und C.

Eine Frage, die sich spätestens jetzt auftut ist: Warum hat man nicht einfach  FORTRAN erweitert. Ich denke es sind drei Gründe die dafür verantwortlich sind. Das eine ist das sobald eine Sprache etabliert ist, d.h. weit eingesetzt wird, es sehr schwer ist an der bisherigen Syntax zu ändern Denn damit würde die alte Software nicht mehr laufen. Selbst wenn alle sich einig sind, das die bisherige Syntax Scheisse ist. Ein Paradebeispiel ist die Stringverwaltung von C. Die Länge eines Strings wird durch ein Nullbyte festgelegt und wenn man nicht ganz genau aufpasst kann man mit einem zu langen String für den man nicht den Platz vorgesehen hat, wichtige Daten überschreiben. Darauf beruht ein Angriff auf Software, der sogenannte Buffer-Overflow beim dem Strings Code überschrieben und so Schadcode einschleusen. Heute legen Compiler Prüfdaten auf den Stack um eine Veränderung festzustellen, aber die Stringverarbeitung von C wurde nie geändert.

Bei FORTRAN sieht man dies deutlich. Dem ersten Compiler im April 1957 folgten bald FORTRAN II bis IV in vier Jahren bis 1961. Der nächste Standard wär dann  FORTRAN 66. Nach weiteren 11 Jahren folgte  FORTRAN 77 und nach 13 Jahren FORTRAN 90. Danach ging es dann wieder schneller mit FORTRAN 95,2003 und 2008. Das spiegelt dann auch den Rückgang in der Verbreitung wieder, denn je weiter eine Sprache verbreitet ist, desto mehr wollen bei neuen Features mitreden.

Anstatt das jemand seine Ideen in einem Komitee einbringt und Jahre wartet bis sie umgesetzt werden, ist es meist so, dass er eine eigene Sprache kreiert. Das ist möglich, weil eine Programmiersprache letztendlich Software ist und wie jede andere Software kann sie entwickelt werden. Ich selbst habe schon eine Programmiersprache für entwickelt und dann noch zweimal in modifizierter Form eingesetzt. Es gibt sogar Tools wie LEX und Yacc die einem einen Teil (das Parsen des Quelltextes) abnehmen. Wenn man ein völlig neues Konzept kreieren will das es so noch nicht gibt wie regelbasierte Programmierung (Prolog) Objektorientierung in reiner Form (Smalltalk) so kommt man gar nicht um diesen Schritt herum. Bei dem einbetten in vorhandene Programmiersprachen muss man dann zu viele Kompromisse eingehen. So ist reine Objektorientierung schwer möglich wenn die Programmiersprachen auch Datentypen kennt die nicht vom Basistyp Objekt abstammen. Eine regelbasierende Programmiersprache die keinen linearen Ablauf kennt sondern Backtracking verwendet wird man schlecht mit einer prozeduralen Sprache mit einem linearen Ablauf verheiraten können.

So, morgen geht es dann weiter mit weiteren Gründen….