Funktionale Programmierung mit Haskell

[frosch03]

u_ser-l schrieb:

Möglich ist so etwas in nahezu jeder Prog.sprache, die bindings zu X libraries zur Verfügung stellt.

Dem hab ich nichts hinzuzufügen.
Aber es wahren auch deine Worte, dass:

u_ser-l schrieb:

eine Nachbildung sequentiellen Verhaltens durch kategorientheoretische Tricks

und

u_ser-l schrieb:

Probleme aus der realen Welt lassen sich oft am einfachsten durch Zustände, Übergänge und sequentielle Abläufe modellieren, also genau das, was mit FP kompliziert ist

Daher das Beispiel mit dem Windowmanager, der ja nichts anderes als eine Zustandsmaschine ist (man könnte auch Mealy-Automat dazu sagen). Und genau diese Zustandsmaschine ist in Haskell in weniger Zeilen Code implementiert, als die vergleichbaren prozedual/imperativen Lösungen. Da ich den Source von xmonad im Detail kenne, so wie auch den Source von wmii sowie larswm, kann ich sagen, dass xmonad nicht nur kürzer, sondern auch viel sauberer (schöner) implementiert ist. Im übrigen leistet xmonad deutlich mehr als wmii oder larswm.

Verstehst du was ich meine? xmonad ist das Beispiel dafür, dass das hantieren mit Zuständen in funProg. nicht das üble Problem ist, dem man nur unter höchstem Aufwand (die von dir genannten kategorientheoretischen Tricks) begegnen kann. In Wirklichkeit ist xmonad sogar dazu geeignet um Anfängern der funProg. diese näher zu bringen. (siehe "A Taste of Haskell": http://conferences.oreillynet.com/pub/w/58/tutorials.html)

Und dass es auch in anderen Sprachen möglich ist wm's zu schreiben, dagegen will ich garnicht argumentieren.

[u_ser-l]

so auf den ersten Blick scheint der xmonad-code aber geradezu vor "do" zu wimmeln - und hinter jedem davon versteckt sich ein "Nest" imperativer Anweisungsfolgen. Das, was man in der reinen funktionalen Programmierung zur Vordertür herausstoßen wollte, kommt durch den Lieferanteneingang "Monade" wieder herein.

Trotzdem, zugegeben, xmonad ist ein eindrucksvoller proof-of-concept in funktionaler Programmierung.

[frosch03]

u_ser-l schrieb:

so auf den ersten Blick scheint der xmonad-code aber geradezu vor "do" zu wimmeln

Genau das ist der Punkt. Es geht um die saubere Trennung des funktionalen Teils von dem Teil mit den Seiteneffekten. Der funktionale Code steht jetzt natürlich nicht wirklich vor dem 'do', sondern wird in den Monaden verwendet, so wie du es hier schon sehr treffend beschreibst.
Im übrigen lässt sich diese saubere Trennung auch schon an den Datentypen der Funktionen ablesen. Man muss also nichtmal in die einzelnen Funktionen hinein schauen, um zu wissen, welche Seiteneffekte haben könnte und welche nicht.

u_ser-l schrieb:

und hinter jedem davon versteckt sich ein "Nest" imperativer Anweisungsfolgen.

Naja, Nest klingt nach echt viel, aber in der Regel hast du hinter jedem 'do' weniger als 10 imperative Anweisungen. Also etwa in dem Bereich von 7+-2 Chunks

u_ser-l schrieb:

Das, was man in der reinen funktionalen Programmierung zur Vordertür herausstoßen wollte, kommt durch den Lieferanteneingang "Monade" wieder herein.

Es ist ja nicht so, dass man Seiteneffekte aus Haskell verbannen wollte. Denn man wollte ja auch schon immer eine nützliche Sprache haben, was natürlich nur mit Seiteneffekten geht. Aber das Ziel ist es, Seiteneffekte erkennbar, handhabbar, ja beherrschbar zu machen. Und das ist, wie ich finde, durch Monaden wundbar gelöst.

Auf der anderen Seite ist es ja z.B. auch in C++ oder in C möglich, eine rein funktionale Funktion zu schreiben. sin(x), oder cos(x) sind schöne Beispiele dafür. Diese Funktionen sind tatsächlich seiteneffektfrei. Man wird aber auch nicht dazu gezwungen, nicht mal dazu, Seiteneffekte erkennbar zu machen. Und man kann dies auch nicht am Datentyp der Funktion erkennen, was dazu führt, dass man nicht weiß, wo Seiteneffekte auftreten können. Und genau hier liegt sicher auch eine Fehlerquelle.

u_ser-l schrieb:

Trotzdem, zugegeben, xmonad ist ein eindrucksvoller proof-of-concept in funktionaler Programmierung.

Absolut, ich bin auch immer wieder auf's neue von xmonad fasziniert. Ich nutze bald 10Jahre (seitdem es larswm gibt) diese tailing wm's. Hab da jetzt doch schon ein paar gesehen, und xmonad übertrifft alles Der rockt einfach

[Gast]

minhen schrieb:

Wenn du das unter "Rekursion erklären" verstehst, nur weil man eine andere Meinung als du hast ...

Nein das tue ich nicht. Ich glaube nur, dass viele Leute, die Rekursion nicht verstehen, die Dinge so erklärt bekommen haben. Ich weiß nicht, wie du Rekursion den Leuten näher bringst, darum kann ich mir kein Urteil darüber erlauben. An dem Punkt frage ich mich außerdem, wie es dazu kommt, dass ich immer wieder Leute treffen, die meinen, dass man Rekursion verwendet, damit das Programm schneller läuft. Da kann dann doch irgendwas nicht richtig erklärt werden.

minhen schrieb:

Aber mit Natürlichkeit und Unnatürlichkeit und wie der Mensch selbst im Hirnkastal denkt, hat das wenig zu tun. Menschen könnten ohne Weiteres "rekursiv denken" und der implizite Abstraktionsschritt im Formalismus würde den Anfängern trotzdem schwer fallen. Das wäre wie mit Sprache und Grammatik. Wir alle haben die deutsche Grammatik intus und können grammatikalische Sätze produzieren, erkennen und verstehen und wissen, wenn ein Satz irgendwie "kein richtiges Deutsch" ist. Und das irgendwie ist der zentrale Punkt. Wehe man muss die Regeln, die man zweifelsohne beherrscht, ausbuchstabieren, aufschreiben oder auch nur bewusst anwenden ...

Das ist natürlich nicht einfach und muss gelernt werden. Die Frage ist halt, wenn du das formulieren kannst, welche der beiden Varianten direkter deine Überlegungen in Quelltext gießen. Dass das erst gelernt werden muss, steht außer Frage. Ich behaupte nur, dass sich das lohnt, eben weil unsere Denkweise nicht prozedural ist. Und obwohl wir es vielleicht gewohnt sind, gewisse Lösungen prozedural zu formulieren.

@frosch03
Sicherlich leistet Microsoft so einiges in der Forschung. Wobei ich dich wieder nach deinen Quellen frage, für deine Behauptung.

Der GHC ist unter der BSD-Lizenz und das Copyright liegt bei "The University Court of the University of Glasgow". Willst du performanten Code erzeugen, kommst du am GHC nicht vorbei. Aber wenn man das mit den im Moment eingesetzten Script-Sprachen vergleicht, so gibt es da noch weitere Haskell-Compiler, die es an Performance locker mit den Script-Sprachen aufnehmen können. Ich schreibe das nur nochmal, weil ich finde, dass das "Microsoft-Argument" nun wirklich kein Argument gegen Haskell und den GHC ist.

[knivil]

An dem Punkt frage ich mich außerdem, wie es dazu kommt, dass ich immer wieder Leute treffen, die meinen, dass man Rekursion verwendet, damit das Programm schneller läuft. Da kann dann doch irgendwas nicht richtig erklärt werden.

Im einfachsten Fall, weil die Objekte auf dem Stack gepackt werden. Im Bereich der Funktionalen Programmierung hat man bei Rekursion aber noch ganz andere Optimierungsmoeglichkeiten: z.B. tail transfer (auch tail recursion oder tail call optimisation genannt).

[+fricky]

knivil schrieb:

Im Bereich der Funktionalen Programmierung hat man bei Rekursion aber noch ganz andere Optimierungsmoeglichkeiten: z.B. tail transfer (auch tail recursion oder tail call optimisation genannt).

höhere programmiersprachen machen aus rekursionen intern oft schleifen. der programmierer merkt natürlich nix davon. für 'nen realen computer, der bits und bytes durch die gegend scheucht, sind rekursionen mühsamer als schleifen.

[knivil]

höhere programmiersprachen machen aus rekursionen intern oft schleifen.

Intern kennt der Computer keine Schleifen nur Spruenge. Jedoch mag tail code optimisation auf Assemblerebene wie Assembler von Schleifen aussehen, Aber Schleifen und Rekursion sind trotzdem verschiedene Konzepte. Iteration wird in Scheme trotzdem durch eine rekursive Notation ausgedrueckt.

[+fricky]

knivil schrieb:

Intern kennt der Computer keine Schleifen nur Spruenge.

ich bitte dich. es gibt einige cpus instructions, die bei sprüngen automatisch irgendwelche register hoch/runterzählen oder sogar 'loop' heissen.

knivil schrieb:

Auch wird mein C++ Kompiler nie aus einer Rekursion eine Schleife machen.

sag niemals nie. wenn er's macht, merkst du jedenfalls nichts davon.

[u_ser-l]

ja, schon der Z80 hatte einen Maschinenbefehl für Schleifen: DJNZ = "decrement and jump if not zero"

[knivil]

Ich finde, dass es keine Schleifen wie sie z.B. in Pseudocode, C++ oder anderen Programmiersprachen sind. Mittels Registeroperation+Jump erzwinge ich nicht die gleiche Semantik, da ich ueberall hinspringen kann. Es ist ist richtig, das Schleifen so auf Assemblerebene umgesetzt werden. Dass ist vielleicht kleinlich, aber (nur) meine Meinung.

sag niemals nie. wenn er's macht, merkst du jedenfalls nichts davon.

Bei inline vielleicht, aber bei allen anderen ... muss ich mal testen.

[mazal]

Bei inline vielleicht, aber bei allen anderen ... muss ich mal testen.

Klar. Tailrekursion. Aber schön mit -O kompilieren.

[+fricky]

knivil schrieb:

Ich finde, dass es keine Schleifen wie sie z.B. in Pseudocode, C++ oder anderen Programmiersprachen sind. Mittels Registeroperation+Jump erzwinge ich nicht die gleiche Semantik, da ich ueberall hinspringen kann. Es ist ist richtig, das Schleifen so auf Assemblerebene umgesetzt werden. Dass ist vielleicht kleinlich, aber (nur) meine Meinung.

ich sehe das lockerer: 'ne schleife ist einfach das wiederholte ausführen eine code-abschnitts, bis eine abbruchbedingung auftritt (oder auch nicht). in dem sinn ist für mich: if (bedingung) goto dorthin; auch eine schleife.

[knivil]

Naja, dann ist alles eine Schleife, weil Recursion auch das wiederholte Ausfuehren von Code ist, bis eine Abbruchbedingung auftritt.

[+fricky]

knivil schrieb:

Naja, dann ist alles eine Schleife, weil Recursion auch das wiederholte Ausfuehren von Code ist, bis eine Abbruchbedingung auftritt.

ok, 'ausgenommen rekursionen', hätte ich noch dazuschreiben müssen. ausserdem muss das 'goto' an eine stelle hüpfen, die irgendwie dafür sorgt, dass das programm auch wieder an dem selben goto vorbeikommt.

[Mr. N]

+fricky schrieb:

knivil schrieb:

Naja, dann ist alles eine Schleife, weil Recursion auch das wiederholte Ausfuehren von Code ist, bis eine Abbruchbedingung auftritt.

ok, 'ausgenommen rekursionen', hätte ich noch dazuschreiben müssen. ausserdem muss das 'goto' an eine stelle hüpfen, die irgendwie dafür sorgt, dass das programm auch wieder an dem selben goto vorbeikommt.

Sind Continuations dann auch Schleifen?

[+fricky]

Mr. N schrieb:

Sind Continuations dann auch Schleifen?

nein, natürlich nicht. und threads bzw. tasks auch nicht, menno, du weisst doch genau, was ich meinte.

[frosch03]

ProgChild schrieb:

Aber wenn man das mit den im Moment eingesetzten Script-Sprachen vergleicht, so gibt es da noch weitere Haskell-Compiler, die es an Performance locker mit den Script-Sprachen aufnehmen können. Ich schreibe das nur nochmal, weil ich finde, dass das "Microsoft-Argument" nun wirklich kein Argument gegen Haskell und den GHC ist.

Haskell ist keine Scriptsprache. Haskell ist sogar alles andere als eine Scriptsprache :). Und nur weil es andere gibt die schlechter sind, sollte man sich doch nicht auch mit etwas schlechterem zufrieden geben. Und bevor sich irgendwer angegriffen fühlt, das soll nicht gegen irgend eine andere Sprache gehen, sondern ein "pro guter Compiler" Argument sein :).

@ProgChild, ich hab dir doch eine ganze Reihe Quellen dazu geschrieben. Was hätteste denn noch gerne?

[u_ser-l]

wird der Nachfolger Haskell' eigentlich unveränderten Haskell-98-Code compilieren ?

Und wieso gibt es so wenige real-world applications in Haskell ? - die meisten Anwendungen scheinen eher für die theoretische Informatik interessant zu sein.

[frosch03]

u_ser-l schrieb:

wird der Nachfolger Haskell' eigentlich unveränderten Haskell-98-Code compilieren ?

Und wieso gibt es so wenige real-world applications in Haskell ? - die meisten Anwendungen scheinen eher für die theoretische Informatik interessant zu sein.

Hmm, also die Compiler setzen alle mehr oder weniger gut den Haskell-98 Standard um. Alles was darüber hinaus geht wird über sogenannte Extensions dazugepackt. Wenn du z.B. die Monomorphismenrestriktion loswerdenwillst, kannst du das im ghc mittels Compilerflag -XNoMonomorphismRestriction, oder durch markieren in der Datei, bekommen.

Zu der real world geschichte, ich hab vor mir ein ganzes Buch liegen (Real World Haskell), dass sich mit real world applications auseinandersetzt. (Das gibts übrigens auch im Netz: http://www.realworldhaskell.org) Und wenne inner Wikipedia so ne schöne latex-Formel siehst, dann steckt da auch Haskellsoftware dahinter.

[Gast]

frosch03 schrieb:

@ProgChild, ich hab dir doch eine ganze Reihe Quellen dazu geschrieben. Was hätteste denn noch gerne?

Nein. Hast du nicht. Du hast lediglich auf die Publikations-Stellen hingewiesen, wo man die Behauptungen angeblich nachprüfen kann. Ich kann allerdings schlecht all diese Zeitschriften bzw. alle Paper lesen.