Funktionale Programmierung mit Haskell
-
u_ser-l schrieb:
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 ??
Weil Haskell eine reine funktionale Sprache ist. Das Bedeutet, dass wenn du Haskell benutzen kannst, dann hast du auch funktionale Programmierung verstanden. Nimmst du etwas wie ML, welches auch prozedurale Programmierung unterstützt, dann programmierst du am Ende unter Umständen nur prozedural mit einer anderen Syntax.
Also wenn du Haskell verstanden hast, dann hast du funktionale Programmierung verstanden. Das sollte dich dazu befähigen so gut, wie jede andere funktionale Programmiersprache zu verwenden und dann nur ein wenig Syntax und noch ein paar Feinheiten zu lernen.
Was man dann am Ende einsetzt, halte ich dann für nebensächlich.
Noch bezüglich Real-World Anwendungen von funktionaler Programmierung. Erlang ist für Webserver in letzter Zeit recht beliebt geworden. Und wird wohl auch von eigen großen Firmen eingesetzt.
-
Jetzt habe ich schon das halbe (übrigens toll geschriebene) "Learn you a Haskell ..."-Tutorial durchgelesen ... und Ihr seid daran schuld
-
ProgChild schrieb:
sondern präzise eine oder zwei Quellen.
Alles klar. Wenn dir jetzt mal meinen Post anschaust, dann hab ich dir da ganz Präzise eine Quelle genannt, nämlich: "Runtime Support for Multicore Haskell" [1] und wenn du das so in Google eingibst, bekommst du sofort den link aufs pdf. Gut, vielleicht hast du das übersehen oder dir fehlte der link aufs pdf, den geb ich dir natürlich gerne
Genial sind auch die drei "Scrap your boilerplate" paper [2]. So und jetzt aber genuch, den Rest darfst'e dir selber ergoogeln Bzgl. Erlang: ich weiß ja nicht ob ihr Jabber einsetzt, aber DER jabberserver (ejabberd) ist in Erlang geschrieben, und der rockt auch mal
@u_ser-l: An sowas ist man gerne Schuld
[1] http://www.haskell.org/~simonmar/papers/multicore-ghc.pdf
[2] http://research.microsoft.com/en-us/um/people/simonpj/papers/hmap/gmap3.pdf
-
Jester schrieb:
frosch03 schrieb:
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?
volkard vor einigen Jahren schrieb:
//zielRichtung ist die richtung vom startturm zum zielturm ...sieht auch nicht so richtig schwierig aus.
Die genannte Umsetzung glaube ich erst, wenn ich das funktionierende Programm sehe. Habe mal eine iterativer Version in Scheme gesehen, die sah wesentlich komplizierter aus, hat aber funktioniert. Leider lernt man aus der Iterativen nicht viel, das sie halt ... kompliziert ist. Die rekursive Variante ist um einiges eleganter.
Zu higher order functions: ich meinte ja, dass z.B. map ausnutzen kann. In Scheme gibt es auch fold-left / fold-right etc. aber diese sind halt rekursiv implementiert. (wobei iterativ und rekusiv in Scheme gleich aussehen, man spricht aber von iterativ, wenn der Stack (Expansion) beschraenkt und unabhaengig von der Eingabe ist O(1)). Die gepostete Scheme-Version von 99 Bottles of Beer ist iterativ.
-
knivil schrieb:
Die genannte Umsetzung glaube ich erst, wenn ich das funktionierende Programm sehe.
nimmst du mal vorlieb mit
http://www.mah-jongg.ch/towerofhanoi/
und probierst als mensch das verfahren.
wirst sehen, daß es für den menschen sogar viel netter ist als die rekursive.und es ist auch möglich, das zu programmieren. das verfahren ist nur das argument dagegen, daß man das rekursiv programmieren MÜSSE.
Habe mal eine iterativer Version in Scheme gesehen, die sah wesentlich komplizierter aus, hat aber funktioniert.
mit dem berechnen der höhen für die grafik ists iterativ nicht ganz so einfach, als wie wenn man die rekursiv mitschickt. aber die zugfolge ist iterativ nachgerade triv.