Funktionale Programmierung mit Haskell

[u_ser-l]

Taktiker schrieb:

Wie würde denn das aussehen?

eben. In Haskell müßte man Monaden bemühen, um einen Einkaufszettel "1. .. 2. .. 3. .." zu implementieren, also eine Nachbildung sequentiellen Verhaltens durch kategorientheoretische Tricks - nicht gerade ein Formalismus, der natürlichem algorithmischem Denken angepaßt wäre. 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 und mit prozeduraler oder OO-Prog'rung einfach.

Bei zukünftig weiter zunehmender Parallelisierung der Hardware auf allen Ebenen könnte die große Zeit von Sprachen wie Haskell in der Tat bevorstehen.

[Christoph]

u_ser-l schrieb:

Taktiker schrieb:

Wie würde denn das aussehen?

eben. In Haskell müßte man Monaden bemühen, um einen Einkaufszettel "1. .. 2. .. 3. .." zu implementieren, also eine Nachbildung sequentiellen Verhaltens durch kategorientheoretische Tricks - nicht gerade ein Formalismus, der natürlichem algorithmischem Denken angepaßt wäre.

Du hast interessante Vorstellungen über Haskell. Eine Liste ist in Haskell einfach das: Eine Liste.
In deinem Beispiel: [1, 2, 3].

Klar kann man das kategorientheoretisch interpretieren. Aber muss man das machen, um die Liste [1, 2, 3] zu verstehen?

[Gast]

u_ser-l schrieb:

Die von Dir aufgezählten Argumente zu Gunsten von FP mögen alle richtig sein, nur hat FP den großen Nachteil, daß sie der menschlichen Intuition von "Algorithmus" zuwiderläuft, denn das natürliche algorithmische Denken des Menschen ist prozedural.

Das ist absoluter Blödsinn. Da ich im Moment in der Lehre tätig bin und Menschen sehe die zum ersten mal programmieren, sehe ich auch, wie schwierig die prozedurale Denkweise zu erlernen ist. Bloß weil du dich an sie gewöhnt hast, ist sie noch lange nicht natürlich.

u_ser-l schrieb:

Niemand schreibt von Natur aus seinen Einkaufszettel als funktionales Programm.

Niemand schreibt seinen Einkaufs-Zettel als prozedurales Programm. Denn die Sachen auf dem Zettel sind ja kein Programmablauf. Der Zettel stellt ja lediglich die Menge der Teile da, die du vor hast zu erwerben. Du wirst selten die Dinge in der Reihenfolge in den Einkaufskorb legen, wie sie auf dem Zettel stehen. Von daher: Blödes Beispiel.

Der Mensch denkt rekursiv und nicht prozedural. Beispiel: Das Bilden der Summe von Zahlen in einer Liste. So würde ein Mensch vorgehen:

Die Summe von zwei Zahlen kann ich. Die Summe von drei Zahlen ist die Summe von zwei Zahlen addiert mit einer weiteren Zahl... (spätestens beim nächsten mal merkt man) Die Summe von n Zahlen ist die Summe von (n-1) Zahlen plus eine weitere Zahl.

Und genau diese rekursive Denkweise setzen die Funktionalen Programmiersprachen um.

u_ser-l schrieb:

Dennoch kann man alles, was man mit FP programmieren kann, prinzipiell auch prozedural oder mit OOP programmieren, dafür sorgt die Church-Turing-Äquivalenz.

Ja richtig. Die frage ist nur, wie viel schwerer und umständlicher es ist.

[Bashar]

ProgChild schrieb:

Da ich im Moment in der Lehre tätig bin und Menschen sehe die zum ersten mal programmieren, sehe ich auch, wie schwierig die prozedurale Denkweise zu erlernen ist. Bloß weil du dich an sie gewöhnt hast, ist sie noch lange nicht natürlich.

Mein Lieblingsbeispiel ist ja immer noch das folgende. Jemand wundert sich, dass dieses Programm nicht funktioniert:

int x;
int y = x*x;
cout << "Bitte x eingeben:";
cin >> x;
cout << "Das Quadrat von x ist: " << y << endl;

Das Beispiel ist fiktiv, aber die Situation an sich hab ich schon zu oft erlebt, um es für einen Zufall zu halten. Denkt der Mensch am Ende deklarativ? (Oder hatten diejenigen Vorerfahrung mit Tabellenkalkulationen?;) )

[Gast]

Bashar schrieb:

Das Beispiel ist fiktiv, aber die Situation an sich hab ich schon zu oft erlebt, um es für einen Zufall zu halten. Denkt der Mensch am Ende deklarativ? (Oder hatten diejenigen Vorerfahrung mit Tabellenkalkulationen?;) )

Keine Ahnung. Aber die Situation, wie du sie beschreibst, hatte ich auch schon so ähnlich. Da sieht man wirklich, welche Dinge man alle als selbstverständlich annimmt, die es aber nicht sind.

[Badestrand]

ProgChild schrieb:

u_ser-l schrieb:

Dennoch kann man alles, was man mit FP programmieren kann, prinzipiell auch prozedural oder mit OOP programmieren, dafür sorgt die Church-Turing-Äquivalenz.

Ja richtig. Die frage ist nur, wie viel schwerer und umständlicher es ist.

Wenn du uns jetzt noch verrätst, warum es hier kein Unterforum zu einer funktionalen Sprache gibt..

[u_ser-l]

ProgChild schrieb:

Da ich im Moment in der Lehre tätig bin und Menschen sehe die zum ersten mal programmieren, sehe ich auch, wie schwierig die prozedurale Denkweise zu erlernen ist. Bloß weil du dich an sie gewöhnt hast, ist sie noch lange nicht natürlich.

So ein Käse. Die prozedurale Denkweise muß nicht erlernt werden, sie ist dem Menschen von Natur aus mitgegeben, weil evolutionär entstanden.

Der Urmensch mußte auf der Jagd etliche "wenn ... dann"-Entscheidungen treffen und prozedural Jagdstrategien planen, um zu überleben. Das hat die natürliche Denkweise des Menschen maßgeblich geprägt.

Das Gehirn ist geschaffen, um zu überleben, und nicht, um elegante Formalismen wie FP zu denken. Und zum Überleben muß es seit jeher prozedural denken. Niemand erbeutet ein Mammut mit funktionalen Überlegungen und Monadentheorie.

ProgChild schrieb:

Niemand schreibt seinen Einkaufs-Zettel als prozedurales Programm.

So ein Käse. Jeder macht das. "1. Supermarkt Broccoli. 2. Bücherei 3. Blabla ..." Ich denke, das Prinzip ist klar (^!)

ProgChild schrieb:

Der Mensch denkt rekursiv und nicht prozedural.

wenn FP der natürlichen Denkweise entspräche, hätte sie sich längst auf breiter Basis durchgesetzt, wahrscheinlich wäre FP vor Fortran und Cobol erfunden worden, und die Turingmaschine wäre für uns dann ebenso exotisch wie für die prozedural denkende Mehrheit der Lambda-Kalkül

[Gast]

Bashar schrieb:

int x;
int y = x*x;
cout << "Bitte x eingeben:";
cin >> x;
cout << "Das Quadrat von x ist: " << y << endl;

Das Beispiel ist fiktiv, aber die Situation an sich hab ich schon zu oft erlebt, um es für einen Zufall zu halten. Denkt der Mensch am Ende deklarativ?

der mensch denkt, du hast mit der zeile int y = x*x; eine funktion definiert, in der er nur x einsetzen muss. hat er im matheunterricht so gelernt. er rechnet ja nicht damit, dass im computer immer alles von oben nach unten ausgeführt wird und die reihenfolge eine entscheidende rolle spielt.

[Christoph]

u_ser-l schrieb:

wahrscheinlich wäre FP vor Fortran und Cobol erfunden worden

Der Lambda-Kalkül ist meines Wissens nach deutlich älter als Fortran und Cobol.

[Christoph]

Zoom schrieb:

Bashar schrieb:

int x;
int y = x*x;
cout << "Bitte x eingeben:";
cin >> x;
cout << "Das Quadrat von x ist: " << y << endl;

Das Beispiel ist fiktiv, aber die Situation an sich hab ich schon zu oft erlebt, um es für einen Zufall zu halten. Denkt der Mensch am Ende deklarativ?

der mensch denkt, du hast mit der zeile int y = x*x; eine funktion definiert, in der er nur x einsetzen muss. hat er im matheunterricht so gelernt. er rechnet ja nicht damit, dass im computer immer alles von oben nach unten ausgeführt wird und die reihenfolge eine entscheidende rolle spielt.

Und genau das ist das schöne an Haskell: Man kann etwas hinschreiben und es funktioniert genau so, wie man es aus dem Mathe-Unterricht erwartet.

[Gast]

Christoph schrieb:

Und genau das ist das schöne an Haskell: Man kann etwas hinschreiben und es funktioniert genau so, wie man es aus dem Mathe-Unterricht erwartet.

kommt drauf an, was man will. entweder computer verstehen, oder computer benutzen.

[Gast]

u_ser-l schrieb:

So ein Käse. Die prozedurale Denkweise muß nicht erlernt werden, sie ist dem Menschen von Natur aus mitgegeben, weil evolutionär entstanden.

Der Urmensch mußte auf der Jagd etliche "wenn ... dann"-Entscheidungen treffen und prozedural Jagdstrategien planen, um zu überleben. Das hat die natürliche Denkweise des Menschen maßgeblich geprägt.

Nein. Du beschreibst Dinge die nacheinander ablaufen und behauptest, weil in der Welt die Dinge immer nacheinander ablaufen, so muss der Mensch auch genau so denken. Warum bitte sollte das so sein?

Sagen wir ein Mensch steht vor einer Mammut-Herde und will ein Mammut erlegen. Folgendes denkt er bestimmt nicht:

1. Trenne ein Mammut von der Herde
2. Erlege das Mammut

Er denkt folgendes: Ein einzelnes Mammut haben wir schonmal erlegt. Wir müssen also irgendwie ein Mammut von der Herde trennen.

Du merkst die natürliche Denkweise ist genau anders herum.

u_ser-l schrieb:

So ein Käse. Jeder macht das. "1. Supermarkt Broccoli. 2. Bücherei 3. Blabla ..." Ich denke, das Prinzip ist klar (^!)

Eine Liste in Haskell bleibt ja auch weiterhin eine Liste. Die Sache ist doch wie du mit der Liste arbeitest.

u_ser-l schrieb:

wenn FP der natürlichen Denkweise entspräche, hätte sie sich längst auf breiter Basis durchgesetzt, wahrscheinlich wäre FP vor Fortran und Cobol erfunden worden, und die Turingmaschine wäre für uns dann ebenso exotisch wie für die prozedural denkende Mehrheit der Lambda-Kalkül

Badestrand schrieb:

Wenn du uns jetzt noch verrätst, warum es hier kein Unterforum zu einer funktionalen Sprache gibt..

Diese Frage lässt sich ganz einfach beantworten. Die Art wie die prozeduralen Programmiersprachen funktionieren ist die Art, wie die Computer funktionieren. Man hat mit Assembler angefangen und der Rest ist halt evolution. Es ist Tatsache, dass viele Dinge in C so sind, wie sie sind, weil man sie recht einfach in Maschienen-Befehle umsetzen kann.

Das hat aber rein garnichts zu tun, mit der Art und Weise, wie Menschen denken.

[Christoph]

Zoom schrieb:

Christoph schrieb:

Und genau das ist das schöne an Haskell: Man kann etwas hinschreiben und es funktioniert genau so, wie man es aus dem Mathe-Unterricht erwartet.

kommt drauf an, was man will. entweder computer verstehen, oder computer benutzen.

Warum schließt du das aus? Man kann mit Haskell vielleicht nicht verstehen, wie ein Computer intern funktioniert. Das kann man mit C++ aber auch nicht. Wer das möchte, muss Assembler oder sogar Verilog (und Logik-Schaltungen) lernen.

Aber nachdem man die "Assembler-Phase" hinter sich gebracht und verstanden hat, wie das funktioniert, wird IMHO so gut wie niemand mit Assembler ein richtiges Programm schreiben.

Es interessiert in den meisten Fällen einfach nicht mehr, zu welchen Maschinencodes eine for-Schleife nun genau umgewandelt wird. Genauso kann man sagen, dass es in Haskell einfach nicht mehr interessant ist, in welcher Reihenfolge nun bestimmte Terme ausgewertet werden, solange das Ergebnis stimmt.

Warum sollte man Zeit investieren in etwas, was der Computer selbst herausfinden kann, wie z.B. die Auswertungs-Reihenfolge? [1]

[1] Von Ausnahmen natürlich abgesehen. Wenn man höchste Performance oder absolut deterministisches Verhalten möchte, führt eben kaum ein Weg an Assembler oder C vorbei.

[Jester]

ProgChild schrieb:

Er denkt folgendes: Ein einzelnes Mammut haben wir schonmal erlegt. Wir müssen also irgendwie ein Mammut von der Herde trennen.

Genau, und aus dieser Überlegung heraus wird er einen Plan fassen:
1. Trenne ein Mammut von der Herde
2. Erlege das Mammut

Zerlegst Du eigentlich Deinen Alltag in lauter Teilprobleme, die Du dann völlig unabhängig voneinander in beliebiger Reihenfolge abarbeitest? Finde ich spannend. Ich persönlich nehme mir immer grobe Aufgaben vor, überlege mir aus welche Teilaufgaben zu bearbeiten sind und erledige dann eine nach der anderen.

[u_ser-l]

Christoph schrieb:

Der Lambda-Kalkül ist meines Wissens nach deutlich älter als Fortran und Cobol.

eben. Wenn FP die natürliche Denkweise ist, und prozedural nicht, dann hätte Fortran eine funktionale Prog. Sprache sein müssen, die Theorie war ja seit den 30er Jahren bekannt.

Es ist eben kein Zufall, daß die frühen Rechenmaschinen, Webstühle, Hollerith-Maschinen, Zuse, Eniac, Autocode, Fortran, Cobol, ... und wie sie alle heißen, ausnahmslos Geräte und Formalismen sind, in denen Zustand und zeitliche Abfolge wesentliche Grundbestandteile sind: sie sind Mechanismen zur Automatisierung menschlichen Denkens, und arbeiten deshalb selbstverständlich prozedural/zeitsequentiell.

ProgChild schrieb:

Du beschreibst Dinge die nacheinander ablaufen und behauptest, weil in der Welt die Dinge immer nacheinander ablaufen, so muss der Mensch auch genau so denken. Warum bitte sollte das so sein?

Weil das menschliche Gehirn zum Überleben in unserer Umwelt entstanden ist, und deshalb von Natur aus nur auf Arten denken kann, die in irgendeiner überlebensrelevanten Beziehung zur Umwelt stehen - und in dem Universum, in dem ich lebe, geschehen Dinge, die in einer wahrnehmbaren Ursache-Wirkung-Beziehung stehen (jetzt bitte keine Quantentheorie und Rosen-Einstein-Paradoxa, wir reden von Urmenschen ^^), stets zeitlich nacheinander.

Warum wohl ist bildliches Denken in 3D relativ einfach, in 4D aber so schwer, daß nur wenige Spezialisten das können, und selbst diese denken oft in 3D-Projektionen ? Eben. Selbe Begründung.

[Badestrand]

ProgChild schrieb:

Badestrand schrieb:

Wenn du uns jetzt noch verrätst, warum es hier kein Unterforum zu einer funktionalen Sprache gibt..

Diese Frage lässt sich ganz einfach beantworten. Die Art wie die prozeduralen Programmiersprachen funktionieren ist die Art, wie die Computer funktionieren. Man hat mit Assembler angefangen und der Rest ist halt evolution. Es ist Tatsache, dass viele Dinge in C so sind, wie sie sind, weil man sie recht einfach in Maschienen-Befehle umsetzen kann.

Das hat aber rein garnichts zu tun, mit der Art und Weise, wie Menschen denken.

Tut mir Leid, das nehme ich dir so nicht ab. Es hat andere Gründe, dass sich prozedurale und objektorientierte Sprachen stark durchgesetzt haben, funktionale Sprachen eben nicht. Die Umsetzbarkeit in Maschinencode ist kein Argument, sobald ein Compiler für die Sprache steht und das Kompilat ausreichende Geschwindigkeit aufweist. So jung ist die Informatik auch wieder nicht, als dass sich die funktionale Programmierung nicht durchsetzen könnte, bei den Vorteilen die gepriesen werden. Und das ist auch das, was mich an solchen Threads wie diesem stört: Glaubt man den Posts hier und aus ähnlichen Threads, müssten alle Programmierer funktional programmieren, da es einfacher zu erlernen ist, Bugs praktisch nicht vorkommen, Ergebnisse schneller vorliegen und so weiter und so fort.
Die Konzepte der funktionalen Programmierung sind durchaus interessant, funktionale Sprachen haben definitiv ihre Existenzberechtigung und finden ihre Nischen. Nichtsdestotrotz ist funktionale Programmierung eben nicht die eierlegende Wollmilchsau und nicht die Lösung für alles.

[Christoph]

u_ser-l schrieb:

Weil das menschliche Gehirn zum Überleben in unserer Umwelt entstanden ist, und deshalb von Natur aus nur auf Arten denken kann, die in irgendeiner überlebensrelevanten Beziehung zur Umwelt stehen - und in dem Universum, in dem ich lebe, geschehen Dinge, die in einer wahrnehmbaren Ursache-Wirkung-Beziehung stehen (jetzt bitte keine Quantentheorie und Rosen-Einstein-Paradoxa, wir reden von Urmenschen ^^), stets zeitlich nacheinander.

Moment. "Ursache-Wirkung" und "zeitlich nacheinander" ist nicht das gleiche.

Sprachen wie C++ und Java modellieren den Aspekt des "zeitlich nacheinander".
Funktionale Sprachen modellieren aber gerade das "Ursache-Wirkung"-Prinzip.

In funktionalen Sprachen wird die Reihenfolge implizit durch Datenabhängigkeiten dargestellt. Das ist aber nichts anderes als das Ursache-Wirkungs-Prinzip; die daraus resultierende zeitliche Abfolge ist nur ein Nebeneffekt.

[frosch03]

Leute ich muss sagen, ich finde die Diskussion total spannend

das natürliche algorithmische Denken des Menschen ist prozedural

Möglicherweise ist genau hier das Problem. Gibt es überhaupt "das natürliche denken?" Ich denke nämlich, dass Menschen unterschiedliche Neigungen haben, etwas als "einfach" zu empfinden. Vielleicht fällt es dir sehr einfach, imperativ vorzugehen, mir oft nicht

Im übrigen spricht man von der Church-Turing-These, da diese nicht bewiesen ist / nie bewiesen werden kann. [1]

Niemand schreibt von Natur aus seinen Einkaufszettel als funktionales Programm.

Vielleicht ist die Einkaufsliste auch nicht das beste Beispiel, da sie ja eigentlich keine Reihenfolge vorschreibt. Vielmehr ist das eine Aufzählung.

Währe ein Kochrezept nicht ein besseres Beispiel? Und da muss ich dir dann auch recht geben, da stehen in der tat sequentielle Anweisungen drauf. Ein missachten der Reihenfolge währe fatal (man stelle sich vor, ich brate die Eier bevor ich sie aufgeschlagen habe :)). Allerdings hat ein Rezept auch nur dort eine Reihenfolge, wo es notwendig ist. Das Würzen z.B. beinhaltet keine Reihenfolge, denn es ist ja auch egal, ob ich Salz vorm Pfeffer verwende oder umgekehrt. Lediglich wann gewürzt werden soll ist festgelegt.

Aber genau das ist auch die Strategie, die in der funProg zum Einsatz kommt. Und es ist verwunderlich, wie wenig doch eine Reihenfolge benötigt. Und oftmals existiert die Reihenfolge auch nur, weil doch immer noch sehr viel prozedural/imperativ programmiert wird. Da ist dann oft noch kurz das Hirn anstrengen angesagt und dann findet man auch seine funProg Lösung. Spannend ist, dass diese sehr häufig eleganter, kürzer und einfacher zu verstehen ist!

Naja, und da wo man tatsächlich mit Seiteneffekten arbeiten muss werden halt Monaden verwendet. Aber Monaden sind auch nicht das Werkzeug aus dem Gruselkabinett (so wie es hier oft klingt). Es ist natürlich richtig, dass Monaden ihre Herkunft in der Kategorientheorie haben. Allerdings kann man auch wunderbar mit Monaden arbeiten ohne die Kategorientheorie studiert zu haben (auch wenn es spannend ist :)). Man kann ja auch mit Datentypen arbeiten, ohne Mengenlehre studiert zu haben (auch wenn auch das spannend ist :)).

müssten alle Programmierer funktional programmieren, da es [einige Vorteile...]

Nur weil etwas sehr gut ist, bedeutet es noch lange nicht, dass es von der Mehrheit angenommen wird. Und niemand sagt, dass andere Paradigmen nicht auch gut sind. Was man allerdings durchaus beobachten kann ist, dass sehr viele Sprachen Konzepte aus der funProg übernehmen. Von daher ist an den ganzen Vorteilen sicher etwas dran.

P.S.: Glaubt ihr echt, dass die Urmenschen tatsächlich so bewusst vorgegangen sind? Ich eigentlich nicht.

[1] http://de.wikipedia.org/wiki/Church-Turing-These

[Badestrand]

Schöner Post

frosch03 schrieb:

Nur weil etwas sehr gut ist, bedeutet es noch lange nicht, dass es von der Mehrheit angenommen wird. Und niemand sagt, dass andere Paradigmen nicht auch gut sind.

Nunja, es wird ja nicht nur gesagt, funktionale Programmierung sei sehr gut, sondern in vieler Hinsicht "besser" als die "etablierten" Sprachen. Da wundert man sich doch wohl zurecht, dass funktionale Programmierung noch nicht Mainstream ist Fragt sich, wo hapert's an der Praxistauglichkeit?

[knivil]

... deshalb von Natur aus nur auf Arten denken kann, die in irgendeiner überlebensrelevanten Beziehung ... wir reden von Urmenschen

Unter diesen Voraussetzungen wuerde es den Menschen, das kreative Wesen, heute nicht geben. Desweiteren finde ich die Argumentation mittels Evolution und Urmenschen reichlich daneben. Auch kann ein Mensch nur eins nach dem anderen abarbeiten, Rechner haben diese Beschraenkung nicht (und das nicht erst, seit dem es Multiprozessormaschinen gibt).

Funktionale Programmierung bieten grossartige Moeglichkeiten, Ablaeufe automatisch zu parallelisieren. Eine Unigruppe beschaeftigt sich bei mir grad mit der automatischen Parallelisierung von C-Programmen und die kotzen staendig ab. Eine weitere Staerke ist auch die Beweisbarkeit von Programmen. Bei Software in Flugzeugen, Satelieten etc. braucht man 100% korrekten Code. Auch gibt es Systeme fuer die Ableitung von Algorithmen zu einem gegebenen mathematischen Problem. Automatisches Testen etc ... kann auch vereinfacht werden. Desweiteren gibt es genug Lisp->C Coompiler (optimierend), falls Performance dann doch nicht ausreicht.

Ein Grund, warum Lisp nicht aktuell ist, ist vielleicht, dass all die Features natuerlich auch Performance kosten und der akademische Touch.

Nichtsdestotrotz ist funktionale Programmierung eben nicht die eierlegende Wollmilchsau

Eingefleischte Anhaenger von Lisp sehen das anders. Es gibt einfach alles. (Ich bin kein eingefleischter Anhaenger, eher Anfaenger) Man kann aber viel von solchen Sprachen lernen. Und genau das passiert, funktionale Elemente halten vermehrt Einzug in neue und alte Sprachen.

Und zu Microsoft: Die haben eindeutig den Zug verpasst, ihre Forschung im Bereich der Funktionalen Programmierung ist nur verzweifelte Aufholjagt. F# gibt es auch noch nicht so lange im Vergleich zu anderen Funktionalen Programmiersprachen.

Einen kurzen Ueberblick kann man sich hier verschaffen: http://www.artima.com/weblogs/viewpost.jsp?thread=251474