Funktionale Programmierung mit Haskell
-
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.
-
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).
-
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.
-
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.
-
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.
-
ja, schon der Z80 hatte einen Maschinenbefehl für Schleifen: DJNZ = "decrement and jump if not zero"
-
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.
-
Bei inline vielleicht, aber bei allen anderen ... muss ich mal testen.
Klar. Tailrekursion. Aber schön mit -O kompilieren.
-
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.
-
Naja, dann ist alles eine Schleife, weil Recursion auch das wiederholte Ausfuehren von Code ist, bis eine Abbruchbedingung auftritt.
-
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.
-
+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?
-
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.
-
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?
-
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.
-
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.
-
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.
-
ProgChild schrieb:
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.
Stellt sich die Frage, warum du dann noch nach Quellen frägst, wenn du gleich mal ausschließt, diese lesen zu können. Naja und meine Quellen setzen nunmal voraus, dass man sie liest.
(Wobei ich hätte da auch ein paar Videos, wenn dir das helfen würde)Aber im Ernst jetzt, was erwartest du denn. Selbst wenn ich dir jetzt eine Bildschirmseite voller Links gebe um dich zu beeindrucken, nutzt dir das doch recht wenig. Denn woher weißt du, ob da überhaupt etwas sinnvolles drin steht? Oder währ dir das egal? So oder so, wenn du wirklich Quellen hinterfragen willst, kommst du ums lesen derselben nicht drum rum.
-
also gut, zugegeben, Haskell hat schon was. Auch wenn es auf den ersten Blick ein wenig nach Hieroglyphen einer außerirdischen Intelligenz aussieht
Grundsätzlich: weshalb sollte man Haskell nehmen und nicht Scheme oder eine Sprache aus der ML-Reihe, zB SML oder OCaML ??
-
ProgChild schrieb:
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.
Du behauptest, die menschliche Denkweise sei nicht prozedural und der andere behauptet, sie sei prozedural. Solange ihr keine empirischen Untersuchungen zu exakt dieser Frage vorweisen könnt, ist es doch völlig sinnlos, sich darüber zu streiten. Ich persönlich würde die Fragestellung zwar so oder so als reduktionistisch-lächerlich betrachten, aber das ist ein anderes Thema. Wo wir uns jedoch wohl einigen können, ist, dass wir es in der Tat gewohnt sind, gewisse Lösungen prozedural zu formulieren. Ich würde aber sogar behaupten, dass alle Lösungen prozedural gefunden werden. Rekursion wäre dann lediglich ein handlicher Formalismus, mit dem man das Verfahren abstrahieren und kompakt im Gedächtnis abspeichern kann.