Funktionale Programmierung mit Haskell

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?

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?

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.

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.

frosch03

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 ??

minhen

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.

knivil

Die Frage aller Fragen ... schwer als Anfaenger zu beurteilen. Fuer Scheme gibt es z.B. "Struktur und Interpretation von Computerprogrammen" (die Videolektures kann ich nur empfehlen) und viele andere Quellen. Falls man selbst einen Interpreter schreiben moechte, kann man sich fuer den Anfang Minischeme oder Tinyscheme (grauenhafter Code) ansehen. Es gibt aber auch genug Buecher dazu. Jedoch wird Funktionale Programmierung erstmal nicht so explizit hervorgehoben. Wie es bei Haskell oder ML aussieht, weiss ich nicht.

Ich würde aber sogar behaupten, dass alle Lösungen prozedural gefunden werden.

Die Mathematik hat mich eines besseren belehrt. Kreativitaet laesst sich schwer prozedural ausdruecken (und waere dann wohl nicht mehr als Kreativitaet zu betrachten).

minhen

knivil schrieb:

Die Mathematik hat mich eines besseren belehrt. Kreativitaet laesst sich schwer prozedural ausdruecken (und waere dann wohl nicht mehr als Kreativitaet zu betrachten).

Was verstehst du unter Kreativität und wieso ist dies mit Rekursion, nicht aber prozedural möglich? Kann es sein, dass Kreativität für dich etwas ist, was nicht explizit ausbuchstabiert dort stehen darf, sondern implizite Schritte umfassen muss, die nur immateriell im Geiste herumschweben dürfen? Bei einem solchen Verständnis wäre Rekursion natürlich kreativer. Wie gesagt, Rekursion befindet sich eine Abstraktionsstufe höher. Doch mein Verständnis von Kreativität ist das nicht.

knivil

Irgendwie gehts langsam am Thema vorbei: Funktionale Programmierung vs. Prozedurale. Rekursion kann ich auch mit Prozeduren machen. Es ging um Prozeduren als natuerlicher Ansatz um Probleme zu loesen. Damit kann man aber manchmal schwerlich Problemloesungsstrategien entwickeln. Aussderm habe ich nie behauptet, dass Kreativitaet irgendwas mit Rekursion zu tun haette.

minhen

Natürlich geht Rekursion auch prozedural, das ist jedem hier klar. (Zumindest habe ich es hier schon mehrfach geschrieben.) Worauf die Dichotomie also eigentlich hinaus wollte, sollte eigentlich klar sein.

Hast du denn ein Beispiel, wo man das Problem rekursiv anpacken muss? Meine Behauptung ist, dass man die Probleme zunächst rein sequentiell ohne Rekursion durchdenkt. Und dass Rekursion eben ein Endprodukt ist. Das, wenn man es beherrscht, natürlich auch einfach zu handhaben ist und auch nicht schwerer nachvollziehbar ist. Rekursion bleibt dabei aber ein Endprodukt. Bei der Suche nach einer Lösung eines Problems fängt man sequentiell an. Meine Behauptung. Wo ist das nicht so? Mir fällt das ehrlich gesagt schwer vorzustellen. Wie soll man eine Lösung finden, ohne dass man erst die Einzelfälle durchdenkt? Man muss ja nicht alle durchdenken. Doch auch wenn ich die ersten x Fälle durchdenke und dann sage "aha, das ist ja rekursiv lösbar!" habe ich sequentiell angefangen.

knivil

habe ich sequentiell angefangen

Probieren ist immer sequentiell, damit kann man alles erschlagen. Aber man hat nur angefangen ...

aha, das ist ja

Genau hier faengt Kreativitaet an, das ist nicht mehr sequentiell oder prozedural.

eigentlich hinaus wollte, sollte eigentlich klar sein.

Mir ist es nicht klar. Aber das trifft sich gut, du scheinst mich auch nicht zu verstehen.

Jester

minhen schrieb:

Hast du denn ein Beispiel, wo man das Problem rekursiv anpacken muss? Meine Behauptung ist, dass man die Probleme zunächst rein sequentiell ohne Rekursion durchdenkt.

Ein Beispiel, das man rekursiv anpacken *muss* wird er wohl kaum haben. Immerhin lässt sich jedes Problem, das sich rekursiv lösen lässt auch iterativ lösen.

Allerdings ist es manchmal tatsächlich einfacher etwas rekursiv zu lösen, als iterativ. Ich würde zum Beispiel wetten, dass jemand, der über schnelle Berechnung von Potenzen nachdenkt zuerst ein rekursive Sqare-and-Multiply auf dem Blatt stehen hat und erst einige Zeit später die iterative Implementierung hingeschrieben hat (die für ne Sprache wie C++ effizienter sein sollte). Insofern sehe ich Rekursion nicht zwingend als das Endprodukt an.

Tatsächlich habe ich manchmal ne Menge Arbeit damit, rekursive Algorithmen so umzuformulieren, dass sie sich halbwegs vernünftig implementieren lassen.

mazal

Rekursion kommt häufig vor und ist oftmals die "natürlichste" Herangehensweise an ein Problem, da man es Recht häufig mit rekursiven Strukturen zu tun hat: Grammatiken, Dateisystemen, Bäumen etc.

mazal schrieb:

Rekursion kommt häufig vor ...

wie in dem lied 'ein mops kam in die küche...'

knivil

Oder: http://99-bottles-of-beer.net/ . Hier mal die Variante in Scheme (wenn man etwas mit quotes rumspielt, geht es vielleicht auch kuerzer, auch die Mapidee von Haskell kann man uebernehmen):

;;; Tim Goodwin (tim@pipex.net)

(define bottles
  (lambda (n)
    (cond ((= n 0) (display "No more bottles"))
          ((= n 1) (display "One bottle"))
          (else (display n) (display " bottles")))
    (display " of beer")))

(define beer
  (lambda (n)
    (if (> n 0)
        (begin
          (bottles n) (display " on the wall") (newline)
          (bottles n) (newline)
          (display "Take one down, pass it around") (newline)
          (bottles (- n 1)) (display " on the wall") (newline)
          (newline)
          (beer (- n 1))))))

(beer 99)

knivil schrieb:

Oder: http://99-bottles-of-beer.net/ . Hier mal die Variante in Scheme...

die BASIC-version von der seite da^^ finde ich besser. die ist dazu noch iterativ.

frosch03

Also wenn ich mal aus meiner Haskellerfahrung berichten darf.
Oft geht man da noch einen Schritt weiter, und versucht von der Rekursion zu abstrahieren indem
man Funktionen höherer Ordnung verwendet (z.B. fold). Damit bin ich dann nicht mehr iterativ, und hab mich auch nicht explizit um die Rekursion gekümmert.

Keine Ahnung wie es euch geht, aber um den Turm von Hanoi zu lösen fällt mir grad nur die rekursive Lösung ein. Kann es sein, dass diese hier auch deutlich einfacher ist als die Iterative mittels Schleife?