Erklärung zu Folien zur Einteilung von funktionalen Sprachen

[Hyperion]

Hallo liebe Freunde der funktionalen Programmierung,

ich bin auf dem Gebiet nicht wirklich bewandert, habe aber dennoch versucht, folgende Folien zu kapieren:
http://projects.tmorris.net/public/what ... index.html

Mich wundert ein wenig, wieso Python nach allem was dort gesagt wird, als "extremly poor" klassifiziert wird. Evtl. kann mir das jemand erklären, nen guten Link dazu geben oder aber am schönsten ein Beispiel in Python geben, bei dem die beiden geforderten Aspekte nicht erfüllt werden bzw. das zeigt, wieso das in Python generell / zumeist nicht erfüllt wird.

[sma]

Am einfachsten wäre es wohl, Tony Morris zu fragen, denn vielleicht bin ich zu müde, aber aus den Folien kann ich seine Schlussfolgerung, dass Python eine schlechte und Scala immer noch nur eine mäßige FP abgibt, nicht nachvollziehen.

Vielleicht muss man das erwähnte Paper von Wadler "The Esence of Functional Programming" lesen, um es zu verstehen.

Die Folien sagen jedenfalls nur, dass es viele Dinge gibt, die man zu Tode diskutieren kann und trotzdem nicht den Punkt trifft. Es gibt Funktionen höherer Ordnung und ausgefeilte statische Typsysteme, aber um beides geht es nicht. Einzig wichtig sind referenzielle Transparenz und das Kombinieren von Funktionen.

Ersteres sagt IMHO einfach aus, dass Funktionen keinen Seiteneffekt haben sollen und man daher einen Teilausdruck durch den berechneten Wert ersetzen darf. Das geht in Python, wenn man will, aber zugegeben muss man sich auf ein Subset der Sprache beschränken.

Das Beispiel zum Kompositionalitätsprinzip liese sich genau so auch in Python realisieren -- sogar IMHO schöner, da der "?:"-Operator eher hässlich ist. Kombinieren von Funktionen wäre auch in Python möglich, allerdings gibt es keine einfache Syntax für partielle Funktionen. Prinzipiell geht es aber.

Ich würde daher Python auf die Ebene von Scala heben, jedenfalls aber besser als Java und C/C++ ansehen.

Stefan

[cofi]

Das muesstest du den Autor fragen, mich persönlich stoeren die mikrigen Lambdas. Und natuerlich die Grundvorraussetzung der "referenziellen Transparenz" Python jede Hoffnung auf Anerkennung kaputt *g

Warum C# besser wegkommt, dürfte an LINQ liegen, und den nicht so kastrierten Lambdas.

[BlackJack]

@Hyperion: Das wundert Dich wirklich? Es geht um "pure"! Die in der ersten Kategorie haben viel Zustand der verändert wird → Seiteneffekte. Die in der zweiten Kategorie erlauben Seiteneffekte, favorisieren aber unveränderliche Variablen. Wobei C# da IMHO ein wenig aus der Reihe fällt. Vielleicht zusätzlich zu dem was cofi gesagt hat: Es gibt mit `struct`\s zusammengesetzte Wertetypen, die es in der Form in Java nicht gibt. Die in der dritten Kategorie sind "pure functional". Und davon ist Python -- $GOTT sei Dank -- weit entfernt.

Das steht und fällt alles mit der Folie Referential Transparency. Setz da mal für `function()` zum Beispiel `random.random()` ein.

FP ist für den Autor "pure FP" und dafür stimmt die Einteilung. Ich stimme mit ihm aber wahrscheinlich nicht damit überein wie erstrebenswert "pure FP" ist.

[sma]

Noch was: Auch wenn ich generell einen funktionalen Stil bevorzuge, halte ich funktionale Programmierung nicht für einen Selbstzweck. Ich akzeptiere z.B. bei Erlang oder Clojure die funktionale Programmierung als Mittel, einfacher (manche würden sagen: überhaupt) parallel ausführbare Programme zu schreiben, aber wenn's an Datenverwaltung oder I/O geht, muss es nicht funktional sein. Da ist mir der Preis (Monaden) zu hoch. Zudem fällt mir eine objektorientierte Analyse eines Problems einfacher, als es in Funktionen zu zerlegen.

Stefan

[Hyperion]

Vielen Dank für die Antworten. Die haben mich doch ein wenig erhellt! Vor allem weiß ich jetzt, dass ich noch viel zu lernen habe in dem Bereich

Prinzipiell gefallen mir die funktionalen Möglichkeiten in Python ganz gut; in Java vermisse ich so etwas wie map() dann eben doch öfters (@sma: Wie empfindest Du eigentlich functional java? Ich vermute mal, Du hast da Praxis Erfahrungen?)

[sma]

(@sma: Wie empfindest Du eigentlich functional java? Ich vermute mal, Du hast da Praxis Erfahrungen?)

Nein, habe ich nicht. Ob nun dieses Projekt oder ein ähnliches, so etwas hatte ich mir schon mal vor einigen Jahren angeschaut und nachgemachte Funktionen mittels (anonymer) innerer Klassen in Java geht IMHO gar nicht. Das empfinde ich als extrem unübersichtlich und man biegt damit Java in eine Richtung, für die es nicht gemacht wurde. Auch die Prädikate des Google Collection-APIs oder diese Hamcrest-Matcher von JUnit finde ich grenzwertig umständlich - selbst wenn mir die IDE die Arbeit abnimmt, die ganzen statischen Funktionen zu importieren. Dann schon lieber Scala -- wenn diese Sprache nur nicht so komplex wäre. Vorhin war ich gerade erstaunt, dass man offenbar "list.map(1+)" statt "list.map(1+_)" schreiben kann, was ich nicht gedacht hatte und wo man aber "(_+1)" und nicht einfach "(+1)" schreiben muss, wenn man den anderen Parameter weglassen möchte. Warum kann man manchmal (aber nicht immer) "_" weglassen, wo das doch schon eine Kurzform für eine Closure ist? Die Abkürzung zur Abkürzung zur Abkürzung?

Kann ich bitte einfach optionale Typen in Python haben?

Und falls tatsächlich mal Closures in Oracle Java 7 das Licht der Welt erblicken und IDEs die dann unterstützen, mag es besser werden, aber ich halte mal nicht den Atem an, bis das passiert. Ich suche mir da lieber eine passendere Sprache aus.

Stefan

[lunar]

Nun, C++0x hat auch Lambdas, und diverse andere funktionale Konzepte lassen sich mit Templates umsetzen. Man kann auch in C++ funktional programmieren, zumindest wesentlich besser als in Java

Was funktionale Programmierung angeht, so ist sie auch nur Mittel zum Zweck. Manche Probleme lassen sich funktional gut formulieren, andere wiederum eher weniger. Die propagierte „Befreiung von der Neumann-Maschine“ bzw. der Übergang in eine rein funktionale und zustandsfreie Welt ist aber ein Wunschtraum. Natürlich ist Zustandsfreiheit bis zu einem gewissen Grad erstrebenswert, weil sie vieles vereinfacht oder überhaupt erst ermöglicht (Parallelisierung, Testen, Korrektheitsbeweise, usw.). In der echten Welt aber gibt es Zustände, und wünschenswerte Seiteneffekte. Das lässt sich nun mal nicht vermeiden, und insofern auch nicht vollkommen verbergen.

[Leonidas]

Prinzipiell gefallen mir die funktionalen Möglichkeiten in Python ganz gut; in Java vermisse ich so etwas wie map() dann eben doch öfters (@sma: Wie empfindest Du eigentlich functional java? Ich vermute mal, Du hast da Praxis Erfahrungen?)

Ich habe erst letzte Woche in einen Java-Quelltext lauter böse Kommentare geschrieben, wo ich gerne map und foldl benutzt hätte. Functional Java würde ich nichtmal mit einem langen Stock berühren wollen, denn was ich mir von funktionaler Programmierung erhoffe sind elegantere, kürzere Codes und bei Functional Java ist dies nicht gegeben - eher im Gegenteil, zudem man keine vernünftige Syntax für anonyme Funktionen hat. Scala hat eine praktischere Syntax, aber die verschiedenen Möglichkeiten diese zu definieren gehen wohl schon übers Ziel hinaus... halte immer noch ``(lambda (params) value)`` für am besten

In Python braucht man ``lambda`` seltener, was wohl auch daran liegt dass ``operator.itemgetter`` & Co. viele triviale Lambdas unnötig macht - und komplexere Lambdas habe ich sowieso lieber als benannte Funktionen, schon allein der Übersicht halber.

[hendrikS]

Zu behaupten Python sei nicht geeignet für den funktionalen Ansatz und Haskell sei praktikabel kommt mir irgendwie vor als hat er weder mit der einen noch mit der anderen tiefere praktische Erfahrung. Dabei sind doch Python und Haskell so ähnlich. Im Prinzip kann ich ein Haskell Programm fast so aufschreiben wie ein Python Programm. Damit finde ich Python eigentlich sehr gut für funktionales Programmieren.
Auf der anderen Seite der Fakt das es im Regelfall ein mehrfaches ein Zeit in Anspruch nimmt ein Haskell Programm ordentlich ans Laufen zu bekommen macht es nicht immer zur praktikabelsten. Ich kenne eigentlich nur einen, der Haskell Programm runterschreibt wie ein Python Programm. Dazu kommt Lesbarkeit und Wartbarkeit des Codes, wo's einem manchmal echt schaurig wird.

[BlackJack]

@hendrikS: Es geht hier nicht um den funktionalen Ansatz sondern um reine funktionale Programmierung und das macht Python einem nicht so leicht. FP ist Programmieren ohne Seiteneffekte. Das ist mit Python nicht wirklich praktikabel weil die idiomatische Verwendung der Sprache auf Objekte mit veränderlichem Zustand setzt. Das "practical" auf der Folie bezieht sich auch auf FP und nicht Programmieren im Allgemeinen.

Les- und Wartbarkeit von Haskellprogrammen können wir vielleicht gar nicht beurteilen. Ich kann es sicher nicht, weil ich in der "Denke" einfach nicht verhaftet, und durch Assembler bis Python ordentlich "vorgeschädigt" bin. Leute die programmieren neu lernen, gehen da viel unbelasteter heran und viele kommen mit FP prima klar. Wesentlich besser als Leute wie ich, die am Anfang versuchen die alten Denkmuster von den imperativen Sprachen Haskell aufzuzwingen. Und das gilt vielleicht auch für den Entwurf und die Wartung von Programmen. Da ist man als alter Hase vielleicht auch zu vorbelastet um funktionale Programmentwürfe als "lesbar" anzusehen, während Unbelastete das viel unproblematischer und übersichtlicher finden.