Funktionale Programmierung mit Haskell
-
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.
-
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 MammutZerlegst 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.
-
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.
-
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.
-
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.
-
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.
-
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?
-
... 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
-
knivil schrieb:
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.
Welcher große Softwarehersteller forscht denn sonst so im Bereich FP? Du hattest Google erwähnt, spielst wahrscheinlich auf Map-Reduce an. Da ist aber nur die Idee funktional, die haben das dann natürlich in einer imperativen Sprache (C++ AFAIK) implementiert.
Und F# würde ich nicht als Forschungsbeitrag interpretieren, das ist ja im wesentlichen eine Anpassung von OCaml an Mainstream-Bedürfnisse. Guck dir lieber an, was sie im Bereich Haskell machen.
-
Jester schrieb:
Genau, und aus dieser Überlegung heraus wird er einen Plan fassen:
1. Trenne ein Mammut von der Herde
2. Erlege das MammutJa genau. Aber diese Formulierung erfordert einen Zusätzlichen Denk-Schritt. Und jetzt denken wir mal weiter. Jetzt will der Urmensch seinen Begleitern klar machen, was zu tun ist. Sagt ihnen einfach nur die beiden Schritte, werden sie sich fragen, warum die beiden Schritte sinnvoll sind. Formuliert er sie so, wie ich oben, verstehen sie sofort, dass es sinnvoll ist.
Jester schrieb:
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.
Genau das ist der Punkt. Du hast erst ein großes Problem, welches du in Dinge zerlegst, die du in einem Schritt lösen kannst. Das was am Ende dabei raus kommt ist eine sinnvolle Reihenfolge. Den Sinn der Reihenfolge versteht aber nur der, der deine vorherige Überlegung kennt und der weiß, was das große Problem ist, was es zu lösen gibt.
Was ich sagen will: Die Überlegungen finden nicht prozedural statt. Das Ergebnis mag hinterher ein prozeduraler Ablauf sein, aber das sagt ja gar nichts darüber aus, wie der zustande gekommen ist.
Vielleicht nochmal der Einkaufszettel. Bloß weil ich am Ende die Dinge in der Reihenfolge auf dem Zettel stehen habe, wie ich sie später erledigen will, so heißt es noch lange nicht, dass sie mir in genau der Reihenfolge eingefallen sind. Das wäre sogar sehr verwunderlich.
u_ser-l schrieb:
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.
Diese Dinge sind alle sequenziell, weil wir keine Möglichkeit haben, sie nicht sequenziell zu gestalten. Ich stimme nur absolut nicht mit dir überein, dass das genau dem Menschlichen denken entspricht. Wenn ich eine Saftpresse erfinde, dann bedeutet das ja auch nicht, dass ich genauso denke, wie meine Saftpresse funktioniert. Ich denke nicht in Form von Orangen-Hälften. Und nur weil meine Saftpresse Strom braucht um zu funktionieren, so heißt das noch lange nicht, dass ich Strom brauche, um das selbe zu tun.
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.
Das mag schon sein. Nur wenn ich etwas baue, dann interessiert mich eine Wirkung. Das heißt ich muss nach den Ursachen suchen, die später meine Wirkung erzeugen. Dass ich diese natürlich ausführen muss, bevor ich die Wirkung erhalte ist klar. Das sagt aber gar nichts darüber aus, wie ich darauf gekommen bin.
Glaubst du Otto hatte als erstes die Teile zusammen, die er brauchte um seinen Motor zu bauen und hat sich dann überlegt, was er damit anstellt? Nein! Er wollte einen Motor bauen und hat sich dann überlegt, welche Teile er dafür braucht und diese dann beschafft.
u_ser-l schrieb:
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.
Falsch. Bildliches denken ist per Definition 3D. Darum ist es schwierig. Bloß weil ich mit einem Toaster keine Pizza backen kann, heißt es noch lange nicht, dass es unmöglich ist, eine Pizza zu backen. Der Toaster ist bloß das falsche Instrument. Genauso wie bildliche Vorstellung hier fehl am Platz ist.
Bloß weil du nur 3-dimensionale Dinge sehen kannst, heißt das doch noch lange nicht, dass du nicht 4-dimensional denken kannst. Unsere Wirklichkeit ist 4D. Es gibt nämlich noch eine Zeitliche Komponente. Und ich kann mir wunderbar einen Ball vorstellen, der durch die Luft fliegt.
Badestrand schrieb:
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.
Ich denke schon, dass man die evolutionäre Komponente nicht vernachlässigen sollte. Jemand der einen Compiler schreibt hat vorher jahrelang mit einer Imperativen-Sprache programmiert. Er hat das Konzept verinnerlicht und er kann gut damit umgehen. Kein Wunder, dass seine neue Sprache wieder eine imperative ist.
Badestrand schrieb:
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.
Nein. Alles hat seine Vor- und seine Nachteile. Und die sollte man auch nicht Verschweigen. Wenn man wirklich Performance braucht, so führt immer noch kein Weg an C++ vorbei. Und wenn es ganz schnell sein muss auch kein Weg an Assembler vorbei.
Ich glaube auch nicht, dass man wahnsinnig viel schneller ist. Was ich allerdings denke: Die Programme haben weniger Fehler. Und wenn man sich einmal daran gewöhnt hat, so sind sie auch erheblich leichter zu lesen, als imperative Programme.
Dafür hat man vielleicht im Schnitt einen Performance-Verlust um den Faktor 2. Aber es gibt ja Leute, die in Python oder ähnlichem programmieren. Die behaupten ja immer, dass sie das Allheilmittel gefunden haben. Aber gerade Python ist um den Faktor 30-40 langsamer. Von daher...
Badestrand schrieb:
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.
Funktionale Programmiersprachen können genauso General Purpose sein, wie C++. "Die" Lösung für alles gibt es nicht. Aber ich sehe sie auch nicht in irgendwelchen Nischen. Man kann nämlich auch anders herum argumentieren: Obwohl die ganzen Programmierer imperative Programmierung gewöhnt sind und lieber ihre imperativen Programmiersprachen verbessern, so ist das Konzept der funktionalen Programmierung trotzdem erhalten geblieben. Und es gibt immer wieder Leute, die dafür einen neuen Compiler schreiben.
Und noch was. Bezüglich C++ und funktionale Programmierung. C++ hat eine Menge an funktionalen Features. Vor allem die STL. Die setzt nämlich mit ihren Funktoren nämlich genau das um, dass man eine Funktion eine Funktion übergibt, um etwas zu tun. Oder denkt man an die IO-Streams. Die Streams sind Monaden und sie werden einfach benutzt ohne irgendwelche Zweifel.
-
knivil schrieb:
Desweiteren finde ich die Argumentation mittels Evolution und Urmenschen reichlich daneben.
Kein Wunder. Es ist das schlagende Argument dafür, warum sequentielle Notationen natürlicher sind als funktionale oder deklarative.
knivil schrieb:
Funktionale Programmierung bieten grossartige Moeglichkeiten, Ablaeufe automatisch zu parallelisieren.
bestreitet niemand. Das macht FP zu einer nützlichen, aber nicht zu einer natürlichen Notation.
-
Die Natuerlichkeit sollte aber trotzdem keine Rolle spielen, wir jagen ja auch keine Mammuts mehr. Und zur Implementation von Funktionalen Sprachen: Letztendlich muss alles auf die von Neumann Architektur laufen, da bietet sich z.B. C an (aber es gab auch mal Lisp-Rechenmaschinen).
Guck dir lieber an, was sie im Bereich Haskell machen.
Muss ich mal schauen, ich selbst beschaeftige mich schon eine Weile sehr intensiv mit FP, aber man kann nicht alles auf einmal lesen, verstehen und ausprobieren. Leider bin ich eher Anti-Microsoft, was meine Leseprioritaeten durchaus beeinflusst.
Wenn man wirklich Performance braucht, so führt immer noch kein Weg an C++ vorbei. Und wenn es ganz schnell sein muss auch kein Weg an Assembler vorbei.
Das ist nicht korrekt. Der gleiche Algorithmus bietet dem C-Kompiler viel weniger an Optimierungsmoeglichkeiten als z.B. in Scheme. Ueber Optimierung, also in Funktionaler Programmierung ueber aequivalente Umformungen, kann ein wesentlich effizienteres Programm entstehen. Diese Moeglichkeit hat der C-Kompiler nicht. Wird das neue Programm in C implementiert, ist es vermutlich etwas schneller. Ein Beispiel ist Stalin. Die Versprechungen auf der Wikipedia-Seite sind recht gross. Ausprobieren konnte ich es aber noch nicht, da der C-Source des Kompilers automatisch erzeugt wurde und gcc fuer 600.000 Zeilen Quelltext in einer Datei mehr als 1GByte Speicher braucht und anfaengt zu schwapen.
-
ProgChild schrieb:
Glaubst du Otto hatte als erstes die Teile zusammen, die er brauchte um seinen Motor zu bauen und hat sich dann überlegt, was er damit anstellt? Nein! Er wollte einen Motor bauen und hat sich dann überlegt, welche Teile er dafür braucht und diese dann beschafft.
Genau. Klassisches Top-Down/Bottom-Up Design, wie man es seit Jahrzehnten beim Softwaredesign für prozedurale Sprachen anwendet. Nichts Funktionales erkennbar.
ProgChild schrieb:
Bloß weil du nur 3-dimensionale Dinge sehen kannst, heißt das doch noch lange nicht, dass du nicht 4-dimensional denken kannst. Unsere Wirklichkeit ist 4D.
So ein Käse. Der relevante Ausschnitt unserer Wirklichkeit ist 3D, deshalb kann niemand von Natur aus in 4D denken. Wenn (mit viel Mühe und Abstraktionsvermögen), dann nur, indem er 4D-Objekte gedanklich auf 3D oder 2D projiziert und sich die Projektionen vorstellt.
4D-Denken war bisher nicht überlebensrelevant. Selbst 3D-Denken ist noch sehr anspruchsvoll für das menschliche Gehirn, wie typische Rätselbilder in IQ-Tests immer wieder beweisen.
Eher normal ist 2D-Denken, das kann jeder, weil das zum Überleben des Urmenschen fast immer ausreichte. Mehr gibt das Gehirn von Natur aus nicht her.
Höherdimensionales Denken erfordert langes Training und Schulung (bspw in der Differentialgeometrie und Topologie kann man so etwas lernen).
ProgChild schrieb:
Es gibt nämlich noch eine Zeitliche Komponente. Und ich kann mir wunderbar einen Ball vorstellen, der durch die Luft fliegt.
In 4D kannst Du das nicht. Du weißt nicht einmal, wie ein 4-dimensionaler Ball aussieht.
Du kannst Dir eine Folge von Einzelbildern in 3D vorstellen. Das ist etwas völlig Anderes, das kann man aber nur wissen, wenn man ein wenig Ahnung von Geometrie hat.
Zeichne doch mal eben einen 4-dimensionalen Torus ... aber ohne Projektionen auf 3D oder 2D
-
u_ser-l schrieb:
Kein Wunder. Es ist das schlagende Argument dafür, warum sequentielle Notationen natürlicher sind als funktionale oder deklarative.
Nein. Es ist kein Argument, sondern eine Behauptung. Den Beweis, dass da zwischen ein Zusammenhang besteht bist du uns noch schuldig geblieben. Ich habe allerdings schon genügend Gegenbeispiele geliefert.
knivil schrieb:
Guck dir lieber an, was sie im Bereich Haskell machen.
Muss ich mal schauen, ich selbst beschaeftige mich schon eine Weile sehr intensiv mit FP, aber man kann nicht alles auf einmal lesen, verstehen und ausprobieren. Leider bin ich eher Anti-Microsoft, was meine Leseprioritaeten durchaus beeinflusst.
Sie bezog sich in diesem Fall wohl nicht auf Microsoft, sondern auf die Leute, die mit Haskell im Moment arbeiten. Microsoft hat mit Haskell nichts am Hut. Die haben ja F#. Unter anderem deshalb, weil .NET zu unflexibel ist, um einen vernünftigen Haskell-Compiler darauf aufzusetzen.
u_ser-l schrieb:
Genau. Klassisches Top-Down/Bottom-Up Design, wie man es seit Jahrzehnten beim Softwaredesign für prozedurale Sprachen anwendet. Nichts Funktionales erkennbar.
Du hast nichts verstanden. Die Denkweise ist in dem Fall Top-Down. Das Ergebnis ist eine Bauanleitung für einen Motor Bottom-Up. Wenn du jetzt immer noch nicht verstehst, dass es einen Unterschied zwischen dem Denken und dem Resultat gibt, dann ist dir wohl nicht mehr zu helfen.
u_ser-l schrieb:
So ein Käse. [...] In 4D kannst Du das nicht. Du weißt nicht einmal, wie ein 4-dimensionaler Ball aussieht.
Du kannst Dir eine Folge von Einzelbildern in 3D vorstellen. Das ist etwas völlig Anderes, das kann man aber nur wissen, wenn man ein wenig Ahnung von Geometrie hat.
Du hast rein gar nichts verstanden von dem was ich geschrieben habe. Darum hast du ja auch wohl das meiste davon ignoriert.
Nochmal: Nur weil ich mir "bildlich" kein 4D-Gebilde vorstellen kann, so heißt das nicht, dass ich mir nichts 4-dimensionales vorstellen kann. Zum Beispiel kann ich mir einen 4-dimensionalen Vorgang durch etwas 3-dimensionales vorstellen, das eine zeitliche Komponente besitzt. Und ich kann mir Zeit schon als etwas kontinuierliches Vorstellen.
-
Genau. Klassisches Top-Down/Bottom-Up Design, wie man es seit Jahrzehnten beim Softwaredesign für prozedurale Sprachen anwendet. Nichts Funktionales erkennbar.
Aeh, Top-Down/Buttom-up wird auch in Funktionaler Programmierung, bei mathemathischen Beweisen etc. verwendet. Das hat nichts mit Prozeduren zu tun, sondern mit Design und Problemloesung.
Der relevante Ausschnitt unserer Wirklichkeit ist 3D
Fuer mich nicht und fuer die meisten auch nicht. Die zeitliche Komponente ist relevant und fest in unserer Vorstellung integriert. Es gibt vorher, nachher, Zeit und ich kann mittels Zeit Schlussfolgern. Z.B. wenn ich nicht um 15 Uhr am Bahnhof bin, dann faehrt mein Zug ab. Wenn ich den Ball so auf das Tor schiesse, dann hat der Torwart weniger Zeit in abzufangen, weil er grad auf seinem linken Bein steht, etc ... .
ich mir "bildlich" kein 4D-Gebilde vorstellen kann
Genau hier liegt das Problem, es ist kein Bild.
PS:
Darum hast du ja auch wohl das meiste davon ignoriert.
Das passiert oefters. Und hat was damit zu tun, das eigene Vorstellungen mit denen im Text kollidieren, Text interpretiert wird, anstatt ihn so zu nehmen wie er ist oder einfach Missverstaendnisse vorliegen. Ich selbst bin auch nicht frei davon, bin mit aber des Problems bewusst. Nachsichtig sein ist meist meine Reaktion.
-
ProgChild schrieb:
Ich habe allerdings schon genügend Gegenbeispiele geliefert.
zum Beispiel ?Ich ändere meine Ansicht, sobald ich auf ein stichhaltiges Gegenbeispiel treffe.
ProgChild schrieb:
Du hast nichts verstanden.
Nochmal: Nur weil ich mir "bildlich" kein 4D-Gebilde vorstellen kann, so heißt das nicht, dass ich mir nichts 4-dimensionales vorstellen kann.Doch, genau das heißt es. Mehr ist leider nicht drin
Nicht mit einem Gehirn, das dem Überleben in einem Universum mit "nur" 3 relevanten Raumdimensionen dient.
-
btw.
"if ... then" und "wenn ... dann" - in beiden Sprachen hat das zweite Wort sowohl eine logische (Implikation) als auch eine zeitliche/sequentielle Bedeutung.
Na, klingelt's ?
-
u_ser-l schrieb:
ProgChild schrieb:
Ich habe allerdings schon genügend Gegenbeispiele geliefert.
zum Beispiel ?Lies doch nochmal, was ich geschrieben habe. Vielleicht merkst du es dann. Ich denke mir nicht noch mehr Gegenbeispiele aus.
u_ser-l schrieb:
ProgChild schrieb:
Du hast nichts verstanden.
Nochmal: Nur weil ich mir "bildlich" kein 4D-Gebilde vorstellen kann, so heißt das nicht, dass ich mir nichts 4-dimensionales vorstellen kann.Doch, genau das heißt es. Mehr ist leider nicht drin
Das tut mir Leid für dich, das für dich nicht mehr drin ist. Unsere Realität hat nun mal eine vierte Komponente die Zeit. Akzeptiere das oder lass es bleiben. Ich habe eine Vorstellung von Zeit und Raum.
u_ser-l schrieb:
"if ... then" und "wenn ... dann" - in beiden Sprachen hat das zweite Wort sowohl eine logische (Implikation) als auch eine zeitliche/sequentielle Bedeutung.
Na, klingelt's ?
In wie fern hat das denn was damit zu tun, dass der Mensch nicht prozedural, sondern Problem-Orientiert denkt?
Du hast keine Ahnung von funktionaler Programmierung, oder? Schaue dir mal mein Beispiel mit der Summe von Zahlen an. Das Grundlegende Denken von Menschen basiert darauf ein Problem auf bekannte schon gelöste Probleme zurück zu führen. Und dieser Ablauf ist nicht prozedural.
-
u_ser-l schrieb:
Eher normal ist 2D-Denken [... usw.]
Ich glaube zu verstehen, was du meinst, aber korrigiere mich, wenn ich falsch liege. Mit einem Auge kann ich nur 2D sehen, mit 2 Augen 3D - geschenkt.
Zeitliche Komponente. Und ich kann mir wunderbar einen Ball vorstellen, der durch die Luft fliegt.
Ist der Punkt nicht, dass man mit der Vorstellung auch von ein Modell im Kopf redet? Es ist schon richtig, man kann man die Zeit nicht so sehen wie man Länge, Breite oder Tiefe sehen kann. Aber unser Gehirn ist ja auch keine Bildverarbeitungssoftware, sondern viel mehr ein Organ, dass aus gewonnen Informationen (z.B. den Bildern von den Augen) ein Modell erstellt. Und dieses Modell im Kopf beinhaltet oft sehr wohl eine zeitliche Komponente?
Wenn ich bspw. auf der Landstraße so einen Schleicher überholen möchte und gaaanz weit hinten kommt ein anderes Auto. Meine Augen nehmen jeweils 2D/3D Bilder der Situation auf. Aber nach kurzem beobachten der Situation habe ich mir ein Modell der Situation im Kopf gebildet. Und darin muss die Zeit enthalten sein, denn ich kann ja abschätzen, ob mir die Zeit zum überholen ausreichen wird, oder nicht.
Ist klar geworden worauf ich hinaus will?knivil schrieb:
ihre Forschung im Bereich der Funktionalen Programmierung ist nur verzweifelte Aufholjagt.
Na, das ist nicht ganz richtig. Allerdings merkt man auch nicht auf den ersten Blick wo Microsoft überall hintersteckt :). So wird z.B. der ghc (DER Haskell Compiler :)) federführend von Microsoftmitarbeitern entwickelt. Auch bei der Erstellung des Haskell98 Standards war Microsoft federführend. Der Vollständigkeit halber sollte man vielleicht noch erwähnen, dass es sich dabei um Microsoft Research handelt.
-
ja, das gute alte divide-and-conquer. Eigentlich eher eine Problemlösungs-Strategie als ein Äquivalent zu FP, aber es läßt sich bei gewissen Problemstellungen vorteilhaft einsetzen, und mit FP elegant formulieren, kein Zweifel. Und warum ist FP jetzt natürlicher als prozedurale oder OOP ? Weil sich bestimmte, oft abstrakte Probleme, damit eleganter formulieren lassen? Wie gesagt: FP ist eine nützliche Notation, aber deshalb noch nicht natürlich. Real-world-Probleme bestehen vorwiegend aus Zuständen und ereignisgesteuerten Zustands-Übergängen, Dinge, die mit FP mit umständlichen "Klimmzügen" zu modellieren sind. Das ist das Problem, und deshalb ist OOP oder prozedurale, jedenfalls zeitsequentielle Programmierung, natürlicher.
Wie sortiert ein Kind Spielkarten? Bestimmt nicht rekursiv mit Quicksort. Eher einfach "immer die nächstgrößte Karte nach vorne" oder vielleicht mit Bubblesort.
Das Ziege-Kohlkopf-Wolf-Problem beispielsweise läßt sich mit deklarativer Programmierung ad-hoc lösen, weil es bereits ein deklaratives Programm beschreibt. Dann ist nach Deiner Logik deklarative Programmierung natürlicher als prozedurale oder FP ?
Einerseits bestehst du so auf der Zeit-Dimension als Bestandteil menschlichen Denkens, andererseits bestehst du darauf, daß der Zeitaspekt beim menschlichen Denken natürlicherweise gar keine Rolle zu spielen braucht, weil man die Sequentialität mit FP wegabstrahiert, und nach Deiner Theorie FP natürlicher ist als zeitsequentielle Notationen. Du widersprichst Dir irgendwie selbst.