Herr Leitenberger, warum gibt es so viele Programmierspachen?

 100 total views,  1 views today

Tja was antwortet man Maschinenbau-Studenten, die schon mit einer für die Lehre entworfenen Programmiersprache ihre Probleme haben, warum es noch so viel mehr Sprachen gibt?

Nun, es gibt natürlich einige Beantwortungsmöglichkeiten: Die eine ist weil bisherige Programmiersprachen etwas nicht hatten was gewünscht war. Diese allgemeine Aussage kann man in viele Unteraspekte unterteilen.

Betrachtet man es historisch, dann waren die ersten Programmiersprachen noch begrenzt: FORTRAN konnte nur Berechnungen, COBOL nur Datenverwaltung. Selbst so Basics wie die heutigen Schleifentypen, Parameter als Wert und Referenzparameter mussten erst noch entstehen. Das kam dann über Programmiersprachen wie Algol, Pascal und C.

Das eine ist der Grundstock an Sprachfeatures. Das zweite sind Konzepte. Nach der prinzipiellen Art sind drei Sprachtypen zu unterscheiden, nämlich prozedurale, funktionale und deklarative. Wenn man dann noch technische Randbedingungen hinzunimmt, kann man leicht zwischen Sprachen unterscheiden die interpretiert sind oder Maschinensprache erzeugen.

Und natürlich gibt es noch Weiterentwicklungen wie das Objektmodell, Modularisierung, Erweiterung fundamentaler Datenstrukturen wie das native Unterstützen von Bäumen, Listen oder assoziativen Arrays. Schon hier kann man über über Bibliotheken viel nachrüsten, ohne den Sprachkern zu erweitern.

Doch wenn ich mal von den grundlegenden technischen Basiseinschränkungen absehe (eine interpretierte Sprache hat einfach andere Möglichkeiten zur Laufzeit, z.B. kann sie viel einfacher Code interpretieren als eine schon übersetzte Sprache) und vielleicht auch, dass eine eierlegende Wollmilchsprache die sowohl deklarativ wie auch prozedural und funktional und objektorientiert ist nicht wünschenswert ist, dann gibt es trotzdem noch viel zu viele Sprachen.

Die Frage ist: warum? Nun ein Grund ist, dass Standards meistens drauf hinauslaufen dass Sprachen sich nur ganz langsam weiter entwickeln. Man sieht dass an den Oldtimern wie Cobol, FORTRAN oder C. Die Komptabilität zu alten Programmen führt dazu dass die Erweiterungen immer kleiner werden. Das scheint nun auch anderen Sprachen so zu gehen wie Ruby, Python oder Java. Schon dass führt dazu dass viele einfach was neues machen wie dies z.B. bei C++ der Fall war.

Das nächste und wahrscheinlich der Hauptgrund für neues Sprachen ist einfach der „Ich mach mein Ding“ Ansatz. Anstatt zu sehen wie man eine existierende Sprache weiterentwickelt werden kann, damit sie den Bedürfnissen entspricht, macht man einfach eine neue. Angesichts der Vorrede über existierende Standards ist das ja auch kein Wunder. Einen Compiler zu schreiben ist dank Lex und Yacc ja auch kein Problem. Wenn eine große Firma dahinter steht, dann wird das ganze sogar erfolgreich. Die Zahl der Beispiele ist endlos. So VbScript bei Microsoft als Alternative zu Javascript und Google macht es mit seinem Dart ja auch nicht anders oder C# als Alternative zu Java, nachdem es mit dem J++/J# nicht so richtig geklappt hat.

Man kann gegen Firmenstandards sagen was man will, aber sie entwickeln sich schneller weiter als offizielle Standards. Nehmen wir mal Delphi, das ja auf Pascal basiert. Pascal hat praktisch keine Marktbedeutung mehr und der einzige Hersteller von Delphi ist eben die Firma Embacederro (Ex-Borland). Das gab die Freiheit sich praktisch vom Standard zu verabschieden und erst Pascal objektorientiert zu erweitern und dann daraus ein komponentenbasierendes visuelles Programmiersystem zu machen, mit dem man erstaunlich viel machen kann. Bestimmte Teile wie die Möglichkeit es komponentenbasiert zu erweitern haben andere Sprachen noch immer nicht, wenn auch die Möglichkeiten der Kernsprache inzwischen gegenüber C# ein bisschen veraltet sind. Der springende Punkt ist dass es aber im Kern immer noch Pascal ist, für dasselbe Konzept muss man bei den C-ähnlichen Sprachen vier Generationen durchgehen nämlich C,C++,Java und C#.

Dann gibt es noch die Programmiersprachen als Selbstverwirklichung. Also jeder nur mittelmäßig begabte kann eine Programmiersprache erstellen. Von mir stammen auch zwei, die jeweils Messsysteme gesteuert haben. Eine für eine Demonstration an der Hochschule an der ich arbeitete und eine zweite für die automatisierte Ausführung von Tests bei einem Hersteller von sicheren Steuerungen. Von der letzten habe ich mal ein Programm abgedruckt, wie ihr seht ist es so ein Mischmasch zwischen BASIC und Pascal:

3 thoughts on “Herr Leitenberger, warum gibt es so viele Programmierspachen?

  1. Zu den wichtigen frühen Programmiersprachen gehören noch:
    – Lisp (funktional), ab 1958.
    – Prolog (deklarativ), ab 1972.
    welche beide in der KI Forschung viel verwendet wurden. Lisp ist auch sehr schön für die Implementierung von GUIs.
    – APL (funktional), aus den 60ern.
    Eine der ersten interaktiven Programmiersprachen überhaupt. Wurde ursprünglich als mathematische Notation entworfen, abeitet interaktiv auf Arrays beliebiger Dimension. Wurde viel in der Versicherungsmathematik verwendet. War auf IBM 360 Timesharing Systemen verfügbar. War 1984 auf IBM PC verfügbar.
    Weiterhin:
    – Smalltalk, ab 1970.
    – Simula-67 als erste objektorientierte Sprache.
    – Forth, ab 1970. Extrem kleine Sprache zur Gerätesteuerung (initial Radioteleskope).

    Diese Sprachen sind extrem unterschiedlich zueinander, sie haben auch sehr unterschiedliche Zielsetzungen in der Anwendung.

  2. Weiterhin gibt es sehr viele kleine Programmiersprachen.

    Eine kleine Programmiersprache entsteht üblicherweise wenn die Konfigurationsdatei einer Applikation komplizierter und komplizierter wird.

    Initial ist es oft ausreichend wenn eine Konfigurationsdatei aus Schaltern und Zuweisungen besteht:
    one-based-arrays
    with-logging
    logfile = …
    loglevel =

    Wenn die Module einzeln debuggt werden müssen geht es weiter mit
    module xyz
    enable-trace
    loglevel =
    tracelevel =
    trace in { a, b, c, … }
    end module

    Irgendwann kommt dann entweder ein IF oder ein CASE dazu, und später eine Funktion oder ein Macro.

    Das alles wird ad hoc zusammengebastelt.
    In diesem Zustand ist z.B. die Konfigurationssprache von Apache v2.2 heute.

    Wenn man dann die Konfigurationssprache noch weiter ausbauen muß, kommen irgendwann Typen und Schleifen dazu (oft sehr spät), die Syntax ist mittlerweile richtig krank, und man wünscht sich, man hätte gleich mit einer richtigen Programmiersprache angefangen. (z.B. REX, Lisp, Forth)

  3. Moin,

    mal meine provokante These:

    Smalltalk war seiner Zeit mindestens 30 Jahre voraus, und erforderte damals mehr Hardware für eine Workstation, als ein typisches Rechenzentrum für hunderte von Benutzern hatte. Seitdem sind regelmäßig neue Sprachen entstanden, die jedesmal einen Schritt näher an Smalltalk waren. Die Geschweiften-Klammer-ALGOL-Sprachfamilie wurde durch die Erweiterungen C++, Java und C# nicht wirklich besser, und während die interpretersprachen wie PHP, Perl, Phython und Ruby tatsächlich jedes mal einen Schritt näher an der Objektorientierung sind, Legt deren Implementierung nahe, dass deren Authoren ‚a little Smalltalk‘ gelesen haben, sich an richtige OO nicht rangetraut haben, aber die Mängel wie Ref-Counting Garbage Collector und simpler/langsamer Bytecode Interpreter übernommen haben, ohne sich mal vorher bei ausgewachsenen Lisp oder Smalltalk Systemen anzuschauen wie das richtig geht.

    Meine Favoriten: Lua weils Prototypenorientiert klein, schmal und schnell ist, und eben Smalltalk!

    ciao,Michael

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.