spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Zitat von »drakon«

Meiner Meinung haben sich die funktionalen Sprachen nicht durchgesetzt, weil sie nicht unserem Denkmuster entsprechen und dann lässt sich darin einiges schwerer programmieren.

Damit stellt sich mir die Frage, ob den imperative Sprachen unserem "Denkmuster" entsprechen?

Hier wäre zunächst zu klären wie das "menschliche Denkmuster" funktioniert. Sind dort deduktive oder logische, regelbasierte Programmiersprachen wie Prolog nicht vielleicht doch näher am "Menschen"? Denken wir die Aufgabe nicht von den Resultaten her - sollten wir also nicht doch lieber deklarative Sprachen wie SQL verwenden? Sollten wir vielleicht nicht alle selber unsere Sprache entwickeln um das Problem effizient angehen zu können bzw. die Lösung in der Problemdomäne darstellen zu können (domänenspezifische Sprachen durch Meta Objekt Protokoll/MOF - z.B. Ruby)?

Sicher lässt sich diese Frage nicht so einfach beantworten - diese knappe Auflistung verschiedener Ansätze zeigt dies. Funktionelle Sprachen haben sicher auch hier ihren Platz.
Die imperativen Sprachen dominieren das Feld meiner Meinung nach aus zwei Gründen. Erstens funktioniert das Prinzip sehr ähnlich wie wir Befehle im Rechner verarbeiten. Dadurch sind auch reine imperative Sprachen wie C so performant. Zweitens hat sich das imperative Konzept auf viele weitere Paradigmen ausgewirkt und ist deshalb so verbreitet. Objektorientierung ist ja quasi eine Erweiterung des imperativen Paradigmas. Innerhalb aller Methoden stehen weiterhin Befehle, die in der Regel sequentiell ausgeführt werden. Methoden sind vereinfacht gesprochen Funktionen, nur haben sie einen bestimmten Sichtbarkeitsbereich (und damit eine bestimmte Bindung zu einem Objekt auf Datenbasis).

Driftet das hier nicht alles langsam ab? Ich wollte eigentlich ne Antwort zum Thema schreiben aber hatte dann doch keine lust mehr bis zum Ende zu lesen Vielleicht wird hierfür nen neuer Thread gemacht

Mit Monaden kann man nicht imperativ programmieren, es sieht nur so aus. Man kann sequentiell Befehle anordnen, die dann zu einem Konstrukt verarbeitet werden. Man kann praktisch eine Pipeline aus sequentiellen Befehlen bauen. Das Problem von funktionalen Programmiersprachen waren seither IO-Operationen und Operationen, bei denen Seiteneffekte erwünscht sind. Pure funktionale Programmierung bietet nur die Möglichkeit für IO über Monaden, die rein prinzipiell Seiteneffekte zulassen. Die Maybe-Monade ist da vielleicht nicht das beste Beispiel, viel besser sind die IO-Monaden, denn nur Funktionen mit dem Typen einer IO-Monade können IO-Operationen durchführen. Das "Do"-Konstrukt ist übrigens nur Sugar, man kann das ganze auch durchweg mit dem Bind-Operator implementieren, was dann letztendlich nicht mehr so imperativ aussieht. Der andere Grund Monaden einzuführen war Modularität.

Listen-Monaden sehen zum Beispiel in Haskell nicht mal ansatzweise imperativ aus.Monaden haben also nichts mit imperativer Programmierung zu tun, allenfalls sequentieller( wobei auch nur bedingt ).

Ein großer Vorteil von Haskell ist zum Beispiel die strikte Trennung zwischen operativen Funktionen und IO-Funktionen. So wird man praktisch zu einer sauberen Lösung mit einer strikten Trennung zwischen IO und Berechnungen gezwungen. Ein weiterer großer Vorteil sind Features wie Typklassen:



Mit Typ-Klassen kann man recht schnell und intuitiv ein Projekt um Features erweitern. Auch wenn man mit den oben gezeigten Multiparameter-Typklassen vorsichtig sein sollte. Funktionale Sprachen eignen sich auch besser für parallele Programmierung bzw. Multithreading, da das immer bedeutender wird, ist das ein weiteres Argument für Haskell.

Letztendlich ist auch der Workflow ein komplett anderer, aus eigenen Erfahrungen kann ich berichten, dass ich meist viel abstrakter an ein Problem rangehe. Mittlerweile halte ich einen Paradigmen-Wechsel für sinnvoll und notwendig, jedenfalls in Teilgebieten. Haskell entspricht meiner Meinung nach auch viel mehr der Denkweise eines Menschen, vor allem diese logischen Zusammenhänge a -> ( a -> b ) -> b sind aus meiner Sicht sehr intuitiv. Es ist vielleicht für einen imperativen Programmierer schwierig in die funktionale Programmierung reinzukommen, aber wenn es tatsächlich mal soweit sein sollte, dass Haskell eine nennenswerte Position in der Welt einnimmt, wird es für die Anfänger nicht schwieriger sein Haskell zu lernen, anstatt zum Beispiel C# oder C.