Danach haben wir fortgeschrittene Konzepte (Typ-, Konstruktorklassen, Monaden) kennengelernt und deren klassische Anwendungen gesehen (Parser und Interpreter).
Schließlich habe ich zwei konkrete Beispiele vorgeführt (Spielprogramme, Sequencer) und daran gezeigt, wie man Software-Entwurf und Prototyping in Haskell macht. Das geplante dritte Beispiel (Jonglieren) habe ich nur genannt, nicht implementiert.
Alle diese Beispiele sind so angelegt, daß sie von Studenten noch ergänzt und erweitert werden können, auch mit Bezug zu anderen Lehrveranstaltungen. (Spiel-Algorithmen: künstliche Intelligenz, Jonglieren: Roboter-Lernen, Computergrafik).
Ich ermuntere nochmals dazu, während des kommenden Semsters für das Connect-Spiel gute Algorithmen zu implementieren, und ich plane (kurz vor dem Sommer) einen öffentlichen Wettkampf einiger Programme (vorausgesetzt, es gibt bis dahin genug).
Als wesentliche Eigenschaften und Gründe für die Benutzung von Haskell sehe ich sowohl die völlige referentielle Transparenz als auch das einerseits mächtige, andererseits strenge Typsystem. Das gestattet einerseits sehr abstraktes (polymorphes) Programmieren (und damit eine gute Modularisierung), und zwingt andererseits zum sehr genauem Durchdenken des Algorithmus, bevor man auch nur die ersten Zeilen tippt.
Ich kann hier nur deutlichst versichern, daß der Zeitaufwand zum Debuggen der gezeigten Programme fast gleich Null war. Das Schreiben dauert länger, und noch ein bißchen mehr verbraucht man normalerweise, bis das Programm vom Typchecker akzeptiert wird. Das liegt aber immer daran, daß man sich eben vorher nicht genau genug überlegt hatte, was die Funktion eigentlich sollte.
Hat nun Haskell überhaupt Nachteile? Aber sicher. Solange wir beim reinen Second-Order-Polymorpic Lambda-Kalkül bleiben, ist alles wunderbar. Einige Ergänzugen sind jedoch, obwohl nötig, nicht so zufriedenstellend. Beispiele: Records sind schwerfällig zu benutzen (Feld-Namen müssen disjunkt sein). Das Modulsystem sollte hierarchisch sein (mit Sub-modulen in sub-directories). Ich wünsche mir statische Polymorphie (der Nutzer möchte ambigöse Ausdrücke hinschreiben, wenn das er durch Typ- oder andere Annotionen eindeutig macht.)
Man kann hieraus jedoch niemandem einen Vorwurf machen. Haskell ist eben auch eine akademische Sprache, in dem Sinne, daß verschiedene Design-Entscheidungen ausprobiert (implementiert) werden, und später fixiert oder verworfen. Das geschieht nicht allein mit dem Ziel, Haskell zu verbessern, oder die anderen funktionalen Sprachen.
Keiner bestreitet, daß entsprechende Sprachen und Systeme immer noch auf einer Außenseiterposition stehen. Trotzdem haben Entwicklungen in funktionalen Sprachen Einfluß auch auf andere. (Beispiel: das FUNARG-Problem (dynamische oder statische Bindung) wurde zunächst in LISP festgestellt (und gelöst), bevor es dann bei ALGOL(68) auch in einer großem imperativen Sprache zu beachten war.)
Wir können uns als funktionale Programmierer schon irgendwie als einer Avantgarde zugehörig betrachten, in den sechziger/siebziger Jahren war das eben LISP am MIT, mit weltweiten Folgen bis heute (GNU, emacs, gcc).
Man hat ja heutzutage in den meisten modernen Sprachen auch funktionale Elemente. Die haben wir jetzt in ihrer "reinen Form" kennengelernt, und können sie nun hoffentlich auch in vielen Varianten wiederfinden und ausnutzen. ("A good programmer can write LISP in any language".)