Ist es Zeit für eine neue Programmiersprache?

Huch, eine gefährliche Sicherheitslücke in Opera erlaubt die Ausführung von beliebigem Code. Schon irgendwie episch, dass sowas heutzutage immernoch passiert. In Zeiten, wo man jedes Bit noch dreimal verwenden musste, kann ich ja verstehen, dass sich hin und wieder Fehler eingeschlichen haben – man musste ziemlich lowlevel programmieren, um zu optimieren.

Nun, spätestens seit DOM und dynamic HTML sollten diese Zeiten aber zumindest für Browser so langsam zu Ende sein. Nun weiß ich freilich nicht, in was Opera genau geschrieben ist, aber ich vermute doch stark einen ziemlich großen C++-Kern, mit ziemlich vielen lowleveligen Aufrufen (ich bin bekanntermaßen kein C++-Freund, aber selbst C++ erlaubt einem  zum Beispiel, Arraygrenzen automatisch prüfen zu lassen, wenn man entsprechende Kapselungen verwendet – diese sind freilich ineffizienter).

Ich persönlich tendiere aber eher zu der Meinung, ein Browser sollte in einer sinnvollen Hochsprache geschrieben sein, mit einer guten Grundengine. Nachdem man von sämtlichen Browsern immer wieder hört, sie hätten Speicherlecks, was mich bei der Notwendigkeit der Behandlung dynamisch wachsender und sich verformender DOM-Bäume nicht wirklich wundert, ist hier vermutlich sogar ein Garbage Collector angebracht – letztendlich wäre nämlich alles, was man erzeugt, um dieses Problem effizient zu lösen, sowieso bereits ein Garbage Collector (zumal JavaScript sowieso einen Garbage Collector voraussetzt). Hochsprachen die das leisten gäbe es genug. Common Lisp und Scheme fielen mir da ein, Perl (ok, sort of) und Python, Haskell, *ml, Java, aber selbst ein konservativer Boehm Weiser GC sollte es bei entsprechender Kapselung in C++ tun. Sicherlich, Runtimes können auch Bugs haben. Aber es ist sinnvoller, auf eine Runtime zu setzen, die – sofern sie korrekt funktioniert – Sicherheit garantiert, und diese ggf. zu patchen, und damit gleich ziemlich viel Software abzusichern.

Wenn man sich nun aber die oben aufgelisteten Sprachen anschaut, fällt recht schnell eines auf: Irgendwie haben alle Sprachen inzwischen ziemlich viele Gemeinsamkeiten. Es mag sein, dass mit Haskell das imperative Programmieren erheblich schwerer ist (aber dank Syntaktischem Zucker im Zusammenhang mit Monaden eben nicht wirklich unmöglich – ja, man kann darüber streiten, ob das wirklich imperative Programmierung ist, aber … es fühlt sich so an, es sieht so aus, also ist es für mich imperativ), während C++ gerade mal Lambda-Konstrukte bekommen hat, die – wie ich C++ einschätze – kaum benutzbar sind. Trotzdem: Im Grunde bekommen momentan die meisten Programmiersprachen die Features von so ziemlich allen anderen. Das liegt wohl wiederum daran, dass die meisten derartigen Features eher kleine Anpassungen voraussetzen.

Wie dem auch sei, was entsteht ist also mehr oder weniger ein Einheitsbrei – zumindest habe ich momentan diesen Eindruck. Alle Programmiersprachen bekommen mehr oder weniger alle existenten Features irgendwie hinzugepfriemelt. Das ist auch nicht wirklich etwas schlechtes – an sich ist es gut, wenn man versucht, verschiedene Features irgendwie ineinander zu integrieren um sie kompatibel zu machen. Nur fehlt es mir persönlich momentan an echten Neuerungen. Ich sehe auf Freshmeat z.B. ständig irgendwelche neuen Interpreter, aber ich sehe selten irgendetwas wirklich neues.

Einen dann doch ganz anderen Weg gehen aber zum Beispiel Logikprogrammiersprachen, wobei ich gestehen muss, bis auf eine Vorlesung und ein wenig Doku über LogTalk wenig bis nichts darüber zu wissen. Logikprogrammierung scheint zwei Aspekte zu kombinieren, die ich mit meinem begrenzten Wissen als Trends prognostiziere: Kontextorientierte Auswertung und Programmverifkation bzw. -extraktion.

Kontextorientierte Auswertung geht in Richtung Lazy Evaluation, und bietet eine ideale Möglichkeit, Berechnungsprocesse zu verteilen –  nachdem Prozessoren jetzt eher dazu tendieren, mehr zu werden, als schneller, sehr sinnvoll. Außerdem lässt sie sich sehr gut in bestehenden Programmcode integrieren, und steht Typsystemen und Verifikation nicht im Weg.

Programmverifikation und Programmextraktion hingegen sind wiederum Techniken, die moderne Softwareprojekte brauchen werden. Spätestens, wenn man wirklich mal relevantes Cloud Computing betreiben will, wird man auf das Problem stoßen, sinnvoll und effizient Berechnungsprozesse eines anderen Rechners ausführen zu müssen, ohne Angst vor Exploits zu haben. Und man wird auf das Problem stoßen, eine fertige Berechnung zu verifizieren, in signifikant kürzerer Zeit als die Berechnung selbst gedauert hat.

Dabei ist Programmverifikation keine Möglichkeit, alle Exploits zu verhindern – das hört spätestens dann auf, wenn die Hardware Fehler macht. Aber es ist eine Möglichkeit, bekannte Sicherheitslücken zu verhindern, indem man Spezifikationen erstellt, die ein Programm erfüllen muss. Somit lassen sich Probleme wie Buffer Overflows effektiv beheben. Programmextraktion wiederum ist eine meiner Meinung nach sehr schöne Möglichkeit, Prototypen für Spezifikationen zu erzeugen, die man später effizienter macht. Ich  vermute, der höhere Aufwandt bei der Erzeugung der Software würde sich bald Amortisieren.

Das sind die Trends, die ich vorhersage. Freilich gibt es das alles schon, aber es führt momentan noch eher ein Nischendasein, während funktionale Konzepte inzwischen ziemlich weitreichend verbreitet sind. Was natürlich auch mit der Jahrzehntelangen Forschung auf diesem Gebiet zu tun hat. Da müssen diese Gebiete noch nachlegen.

Soweit meine Meinung. Andere Meinungen und Ergänzungen dazu würden mich interessieren.

7 Antworten zu Ist es Zeit für eine neue Programmiersprache?

  1. Es ist ein weit verbreitetes Missverständnis, dass man in Haskell nicht imperativ programmieren sollte und dass einem Haskell da Steine in den Weg legt. Jeder, der sich näher mit Haskell beschäftigt hat, behauptet mit Fug und Recht, dass es in Haskell viel leichter ist, imperativ zu programmieren, als in tatsächlich imperativen Sprachen.

    Schließlich kann ich in Haskell innerhalb von fünf kurzen, prägnanten Zeilen einen Echo-Server programmieren, der ohne zusätzliche Arbeit vollständig multithreading-fähig ist und problemlos mit zehntausenden von Verbindungen zurechtkommt.

    Du solltest aufhören, immer so schlecht von Haskell zu reden, solange du dich nicht _richtig_ damit beschäftigt hast.

  2. dasuxullebt sagt:

    Danke für deinen Kommentar. Hm. Ich seh nicht so recht inwiefern ich schlecht von Haskell geredet habe. Generell habe ich genau in einem Blogpost mal meine Eindrücke über Haskell verarbeitet, und – neben vielem Positiven – ein paar Kritikpunkte aufgelistet (und dass man sich ziemlich intensiv damit beschäftigen muss, war einer davon), aber in dem Zusammenhang war klar dass ich ein Haskel-Noob bin, das habe ich auch dazugeschrieben. Ansonsten hab ich einmal geschrieben dass es Stundenlang dauert GHC zu compilieren, was aber eher eine Kritik an MacPorts war, wenn man es überhaupt als Kritik auffassen kann (eigentlich war es mehr ein Tatsachenbericht über MacPorts). Nur ein einziges Mal habe ich wirklich kritisiert dass ich die ganzen monadischen Konstrukte seltsam finde, da ging es aber eher um etwas generelles. Die meisten Haskell-Programmierer, mit denen ich geredet habe bisher, bestehen aber auch eher drauf, dass sie eben gerade _nicht_ imperativ programmieren.

    Was ich jetzt in diesem konkreten Blogpost negatives über Haskell gesagt haben soll ist mir schleierhaft – mal abgesehen von der Tatsache, dass Haskell sich genau wie jede andere Programmiersprache meines Eindrucks nach in den momentan entstehenden Einheitsbrei einreiht, und imperative Features in Monaden kapselt.

    Man könnte hier höchstens vielleicht anmerken, dass ich kein Wort an das Typsystem von Haskell und dessen Erweiterungen verschwendet habe, obwohl ich später von formaler Programmverifikation rede. Aber wo rede ich speziell schlecht von Haskell? Allgemein in meinem ganzen Blog?

  3. Ich kann mich an keinen Fall erinnern, in dem du konkret schlechtgemacht hast, aber deine Posts bezüglich Haskell sind eben oft irreführend und lassen die Sprache schlechter dastehen als sie ist. In diesem Fall war es deine Aussage, dass es sein möge, dass das imperative Programmieren in Haskell erheblich schwerer sei, aber nicht unmöglich.

    Das ist deshalb falsch und irreführend, weil imperatives Programmieren in Haskell tatsächlich so leicht ist, dass man selbst imperativ wesentlich kürzeren und prägnanteren Code bekommt als in anderen Sprachen. Und wenn ich „wesentlich“ sage, dann meine ich das auch.

    Der Hintergrund ist der, dass die IO-Monade und Monaden allgemein nicht einfach nur eine Möglichkeit sind, I/O in Haskell widerspruchsfrei auszudrücken, sondern eine besonders gute Ausdrucksweise für I/O allgemein. Wenn es ginge, würde ich in jeder anderen Sprache ebenso die IO-Monade benutzen, aber es gibt sie leider nunmal nur in Haskell. Abgesehen davon ist das RTS (run time system) von Haskell unglaublich genial, besonders wenn es um Dateien, Netzwerke und Multithreading geht.

    Daher bitte ich dich, dich erst richtig mit der Sprache zu beschäftigen und dann Kommentare zu schreiben, denn sonst wirkst du wie jemand, der eigentlich keine Ahnung vom Thema hat, aber unbedingt etwas gesagt haben will. Das ist nicht böse gemeint, im Gegenteil! Wenn dein Blog so schlecht wäre, würde ich ihn nicht lesen. ;)

  4. Jeder, der sich näher mit Haskell beschäftigt hat, behauptet mit Fug und Recht, dass es in Haskell viel leichter ist, imperativ zu programmieren, als in tatsächlich imperativen Sprachen.

    Ich bin mir nicht sicher, ab wann man sich „näher“ mit Haskell beschäftigt hat. Ich habe The Haskell School of Expression zumindest gelesen, und vor einiger Zeit habe ich eine für ein Uni-Projekt nützliche Monas entworfen, implementiert und genutzt. Ist das ausreichend?

    Ich weiß auch nicht, was Du mit „tatsächlich imperativen“ Sprachen meinst. Ich sehe zum Beispiel Common Lisp als imperative, objektorientierte Sprache an. Es ist jedenfalls definitiv keine algebraische Sprache. (Da der Begriff „funktionale Programmierung“ heutzutage nur noch auf algebraische Programmierung abzuzielen scheint, fehlt mir ein bißchen der passende Ausdruck für das eigentliche Hauptparadigma von Lisp. Das aber nur am Rande bemerkt.)

    Wie dem auch sei — ich finde, daß Haskell eine wunderschöne Sprache ist, nur: Sie schränkt zugunsten ihrer Eleganz die Programmierweise schon ziemlich ein, unter anderem indem sie, ähnlich wie C, keinerlei dynamische Objektorientierung unterstützt. Und damit meine ich nicht unbedingt den engen Begriff der Objektorientierung von Smalltalk et al., sondern ganz allgemein das ungezwungene, dynamische (und teilweise interaktive) Hantieren mit Werten, die eine Identität und andere dynamische Eigenschaften haben. (Natürlich ist das Bild, das ich vor Augen habe, dasjenige extrem dynamische von Common Lisp, Smalltalk und Self, da ich bislang kein schöneres kenne. Aber selbst eher primitive Sprachen wie Scheme bieten eine eingeschränkte Form dieser Art von Objektorientierung.)

    Allein schon aus diesem Grund ist Haskell für mich keine angenehme imperative (wenn auch eine außerordentlich angenehme algebraische!) Sprache. Ich kann allerdings gut verstehen, daß das nicht alle so sehen. Einiges daran ist Geschmacks- und Gewohnheitssache. Mir liegt das dynamische Programmieren einfach mehr, zumindest momentan und für die meisten Problemstellungen — und nachdem ich für mein aktuelles Projekt aus reiflicher Überlegung heraus trotzdem eine statische, algebraische Sprache gewählt habe, möchte ich nicht glauben, daß es sich dabei einzig und allein um den Blub-Effekt handelt.

  5. P.S. „Algebraische Programmierung“ ist auch nur ein Begriff, den ich mir ausgedacht habe und der wahrscheinlich etwas ganz anderes bedeutet, als wie ich ihn verwende. Ich hoffe, es geht aus dem Kontext hervor, was ich damit meine. (Eben die Denkweise in Hinblick auf Datenstrukturen, die ML und Haskell von Lisp abgrenzt — vermutlich schwer in kurze Worte zu fassen.) Besonders toll wäre es freilich, wenn mir jemand einen Tip geben könnte, wie man dieses Programmierparadigma unmißverständlicherweise nennen könnte.

  6. Dass die objektorientierte Programmierung in Haskell fehlt, ist eigentlich keine Design-Entscheidung, sondern wirklich einfach nur ein fehlendes Feature. Man kann ja in Haskell dynamisch programmieren (Data.Dynamic), die Grundlage dazu ist also vorhanden. Es fehlen ‚extensible records‘ und ich denke, ein Großteil der Haskell-Programmierer ist sich einig, dass die Sprache das früher oder später unterstützen sollte.

    Allerdings gibt es einen guten Grund dafür, dass dynamische, objektorientierte Programmierung bis heute fehlt und warum sich objektorientierte Haskell-Dialekte nie durchgesetzt haben. Man kann sehr wohl imperativ programmieren und genau dieselben Programme schreiben, aber man muss sich anders ausdrücken als etwa in C++ oder Common Lisp. Beispiel: Statt mehrere Objekte zu erstellen würde man in Haskell mehrere Threads erstellen. Da hat man dann auch gleich noch den Vorteil, dass der Code völlig automatisch SMP-fähig wird.

  7. Dass die objektorientierte Programmierung in Haskell fehlt, ist eigentlich keine Design-Entscheidung, sondern wirklich einfach nur ein fehlendes Feature.

    Ich glaube eigentlich eher, daß es im wesentlichen weder das eine noch das andere ist, das Haskell weniger dynamisch und imperativ macht als Lisp, sondern ein kulturelles Merkmal.

    Es ist ja nicht so, daß es nicht Ansätze gäbe, Objektorientierung auf Haskell aufzusetzen. Mir ist zum Beispiel O’Haskell bekannt. Nur scheinen die existierenden Ansätze nicht gut anzukommen, wenn man nach ihrer Verbreitung geht. Kein Wunder: Imperative Programmierung in Haskell ist für den typischen Haskellprogrammierer „gut genug“.

    Genauso ist algebraisch-funktionale Programmierung in Common Lisp für den typischen Lisper „gut genug“. Allerdings wird gleichwohl jemand, der Haskell gewohnt ist, in einer Common-Lisp-Umgebung nicht glücklich sein. Nicht, daß man die Features von Haskell nicht in Common Lisp nachrüsten könnte (Pattern-Matching zum Beispiel kann man sich in verschiedenen Formen als Bibliotheken laden — die mächtigen Lispmakros machen’s möglich). Das hilft einem nur eben nichts: Alle Bibliotheken, die man verwenden will, werden in objektorientiertem Stil geschrieben sein, nicht in algebraischem. Wenn man Code mit jemand anderem diskutieren möchte, wird er sich über den Stil wundern. Der algebraische Stil paßt nicht mit den Entwicklungswerkzeugen (Debugger, REPL, Editor, Compiler etc.) zusammen. Und, und, und.

    Genauso würde es womöglich der Objektorientierung in Haskell gehen. Man könnte GHC mit OOP-Features ausstatten. Das wäre natürlich in bestimmten Situationen sehr nützlich. Aber was würde dem Anwender das nutzen, der seine Programme in einem primär smalltalkesquen Stil schreiben möchte? Wenig. Es wäre eben doch ein Haskell mit Objektsystem, nicht ein Smalltalk-Haskell-Hybrid — auch, wenn rein technisch da nicht unbedingt ein Unterschied besteht.

    Ich habe einmal irgendwo gelesen, daß die Schritte zum Erstellen eines Hallo-Welt-Programms in Smalltalk wie folgt aussehen (so ein bißchen tongue-in-cheek):

    1. Man starte seinen Smalltalk-Workspace.
    2. Man öffne ein neues Workspace-Text-Fenster.
    3. Man schreibe „Hallo, Welt!“ hinein.
    4. Man speichere den Workspace.

    Ein Java-Programmierer würde nach der Lektüre dieser Anleitung wohl in den meisten Fällen den Kopf schütteln (oder er würde sie mißverstehen, indem er den Workspace mit einer IDE verwechselt). Ein Schemer auch. Ein Lisper kann sie schon ganz gut nachvollziehen. Dabei hat es eigentlich nicht so viel mit den technischen Eigenschaften der Programmiersprache zu tun, ob man die Anleitung befolgen könnte. (Speicher-Dumps kann man auch von C++-Programmen machen.)

    Was ich damit sagen will, ist: Die Kultur um eine Sprache herum ist mehr als nur Beiwerk. Sie ist ein wesentliches Sprachmerkmal. Ich vermute (!), daß die Haskell-Community mit dem Smalltalk-Verständnis von Objektidentität genauso wenig anfangen kann wie die Lisp-Community mit der algebraischen Denkweise. Doch: Was soll’s? Verschiedene Kulturen zu haben, ist doch eine gute Sache. So kann man sich die richtige je nach Einsatzzweck und Neigung aussuchen.

    Ich glaube nicht an die große Einzellösung für alle Probleme.

    (Ich sage auch nicht, daß es eine Mischung aus Haskell- und Smalltalk/Self-Kultur nicht geben kann, sondern nur, daß eine solche nicht einfach von einem Tag auf den anderen dadurch entsteht, daß man ein Feature in eine Programmiersprache hineinwirft. Mich würde durchaus auch sehr interessieren, wie eine solche Mischung wohl aussehen könnte. Gibt es schon Entwicklungen, die in die Richtung weisen?)

Schreibe einen Kommentar

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s

%d Bloggern gefällt das: