Diskussion:Monade (Informatik)

Hmm, schwierig

Einerseits muss der Artikel aufpassen, u.a. folgenden Beispielen nicht zu widersprechen, wenn er versucht, zu sagen, was eine Monade ist.

• IO, State,
• Continuations,
• Maybe und Either als Grenzfälle von Kollektionen,
• Listen,
• Bäume aller Art natürlich,
• Mengen, Multimengen, Wahrscheinlichkeitsverteilungen und Vektoren (in Haskell 98 nicht effizient als Instanzen von Monad umsetzbar, aber mathematisch Monaden).

Andererseits sind alle 3 Möglichkeiten, die Grundfunktionalität und Eigenschaften zu definieren, mal hier, mal da, sinnvoll:

• return & >>= : optimiert für Haskells do-Notation (und imperative Sicht),
• return & >=> : einfache und reguläre Darstellung der Monadengesetze,
• return, fmap & join: Anlehnung an die Definitionen aus der KT.

Das ganze zu einem konsistenten und konzisen Ganzen zu destillieren ist nicht einfach. Ich glaube, das schlecht gewählte safeDivision-Beispiel trägt seinen Teil dazu bei. :D

Stöbern in anderssprachigen Wikipedias brachte auch nur übersimplifizierenden Unsinn hervor:

• it: Una monade è una struttura dati con uno stato associato. Ja ja, klar.
• ca: En programació funcional una Mónada és un tipus que s'utilitza, no per representar dades sinó per modelar la seqüencialitat mitjançant l'encadenament d'operacions, sobre tot en llenguatges no-estrictes com Haskell on l'ordre de les operacions és indeterminat. Zu viel Betonung auf Reihenfolge, wenn ich das richtig verstehe.
• en: Naja, geht so. Aber: Verwendung des o.g. schlechten Beispiels; später: Ausufern.
• fr: Nahezu gut, aber irgendwie wird nur IO dargestellt.

Mensch, Mensch. Die Benutzung ist soo einfach. Warum die Beschreibung nicht?

Gedanken, Meinungen, Vorschläge? (nicht signierter Beitrag von Daniel5Ko (Diskussion | Beiträge) 00:35, 11. Mai 2010 (CEST))

Damit schlage ich mich auch schon lange herum. Ich fand deinen Vorschlag toll und habe mal versucht den Artikel entsprechend umzuschreiben (hauptsächlich die Definitionen und die Einleitung). Kommentare und Verbesserungen ausdrücklich erwünscht! Sobald der Entwurf stabil ist, werde ich ihn in den Artikel einarbeiten. -- Carsten Milkau (Diskussion) 15:30, 21. Okt. 2012 (CEST)

lesbarkeit...

Überarbeiten? (nicht signierter Beitrag von 132.199.175.216 (Diskussion | Beiträge) 13:17, 17. Nov. 2009 (CET))

Schon der zweite Satz sollte mindestens überdacht und, wenn möglich, in zwei Sätze getrennt werden. (nicht signierter Beitrag von 188.99.227.10 (Diskussion) 20:15, 27. Nov. 2012 (CET))

diese Formulierung "in einem „einfacheren” Typ zu Berechnungen in einem „höheren Typ”" verstehe ich nicht. Fehlt da ein Verb? Der ganze Satz, in dem die Formulierung vorkommt ist merkwürdig. (nicht signierter Beitrag von 139.18.190.55 (Diskussion) 20:15, 27. Nov. 2012 (CET)) (16:25, 30. Mai 2013 (CEST), Datum/Uhrzeit nachträglich eingefügt, siehe Hilfe:Signatur)

Maybe-Beispiel

Ist das Beispiel par x y = 1 / ((1 / x) + (1 / y)) wirklich gut gewählt? Ich kenn mich zwar in der Elektrotechnik nicht aus, aber das Ergebnis dieser Formel (ohne Maybe) wird in Haskell so ausgewertet:

ghci> let x = 0 :: Float
ghci> let y = 2 :: Float
ghci> 1 / ((1 / x) + (1 / y)) :: Float
0.0
ghci> let y = 0 :: Float
ghci> 1 / ((1 / x) + (1 / y)) :: Float
0.0

Sprich: Wenn einer der beiden Parameter 0 ist, ist auch das Ergebnis 0, was sich auch leicht nachrechnen lässt, denn bei Gleitkommazahlen gilt laut IEEE-Standard:

1/0 = Infinity; <br/>Infinity + ... = Infinity;
1/Infinity = 0;

Für den Gesamtwiderstand zweier parallelgeschalteter Widerstände scheint mir die Lösung 0 dabei durchaus zutreffend zu sein (auch soweit es sich aus der Funktion ablesen lässt), und Maybe ist dabei gar nicht nötig.

Viel besser wäre, hier ein Beispiel mit Integerdivision einzufügen; denn dann löst die Division durch 0 in Haskell einen Laufzeitfehler aus:

ghci> 8 `div` 0<br/>
*** Exception: divide by zero

--131.130.238.32 09:05, 28. Jan. 2010 (CET)

Stimmt. Unter den Umständen ist das Beispiel schlecht gewählt. Es ist ohnehin auch schlecht, dass das das einzige Beispiel ist. --Daniel5Ko 20:50, 6. Mai 2010 (CEST)

Vergleich mit OOP

"In der objektorientierten Programmierung entspricht die Typkonstruktion der Deklaration des Monadentyps, die Einheitsfunktion übernimmt die Rolle der Konstruktormethode und die Bindeoperation enthält die für die Ausführung notwendige Logik."

Dieser Satz braucht dringend weitere Erläuterung. Ist er überhaupt korrekt? Es klingt erstens danach, als ob Einheitsfunktion und Bindeoperation Elemente der Objektorientierten Programmierung wären (wenn auch umgekehrt gemeint), zweitens impliziert er, dass durch monadisches Binden alle Ausführungslogik, die in OOP in Methoden enthalten ist, ersetzt würde. Das stimmt m.E. nicht. --131.130.238.32 09:11, 28. Jan. 2010 (CET)

Zustimmung. Sehr problematische Behauptung. --Daniel5Ko 20:50, 6. Mai 2010 (CEST)

Einleitung und Beispiel

Ich bin Informatiker, und habe das vielleicht im 1. Semester mal gelernt. Aber nachvollziehen konnte ich das hier nur sehr schwer.

Ob es die Oma verstehen muss, ist fraglich, aber ich hätte erwartet, dass ich es problemlos verstehe.

Gerade die Einleitung, und das erste Beispiel (in dem das Wort Monade gar nicht vorkommt), tragen nicht viel zur Erklärung bei:

>> Programme, die im funktionalen Stil geschrieben wurden, können Monaden benutzen, um Prozeduren zu strukturieren. --87.178.192.217 10:49, 16. Mär. 2010 (CET)

da hast du leider recht. ich denke zwar monaden verstanden zu haben, aber es fällt mir schwer die wesentlichen punkte überhaupt im artikel wiederzufinden. problemlos verstehen wirst du monaden aber wahrscheinlich auch bei einem perfekten artikel nicht; ich hab schon viele gestandene informatiker erlebt die an monaden ganz schön zu knacken hatten. -- 14:42, 16. Mär. 2010 (CET)

Monaden sind wie Burritos! :D --Daniel5Ko 20:50, 6. Mai 2010 (CEST)

Definition

Ich hätte ja gerne eine andere Definitionssprache als hier dargestellt verwendet. Ich fine dies verwirrend und wenig durchschaubar. Scala wäre hier schön. (nicht signierter Beitrag von 212.79.181.167 (Diskussion) 22:07, 26. Jan. 2014 (CET))

ich hätt ja gerne alle 3 wichtigen definitionen getrennt aufgeführt:

• return und >>= weil's die häufigste definition ist
• map, return und join (flatten) wie bei containern angesprochen
• >=> mit return als monoid, weil's so schön symmetrisch ist

was meint ihr, ist das sinnvoll? -- ∂ 23:13, 15. Jul. 2010 (CEST)

Etwas ähnliches habe ich schon (ganz oben auf dieser Seite) früher diskutieren wollen. (Ich habe diesen Diskussionsbeitrag verfasst, als ich noch nicht gesehen habe, dass neues ungünstigerweise unten hingehört. ;) ) Wie dem auch sei: Ich stimme zu, dass alle 3 Definitionen sinnvoll sind. Ich bin aber auch der Meinung, dass es möglich sein sollte, mit einer davon auszukommen. Und wenn das erreicht wäre, wäre das der Nennung aller 3 Definitionen überlegen. --Daniel5Ko 23:56, 15. Jul. 2010 (CEST)

Aber: wenn's hilft und die ideale Lösung in weiter Ferne scheint: Nur zu, und alle Definitionen nennen. Späteres wieder-'raus-Nehmen ist ja immer möglich. --Daniel5Ko 00:26, 16. Jul. 2010 (CEST)

oha, das hab ich glatt übersehen. momentan weiß ich noch nicht so recht wie, aber ich werd's beizeiten mal versuchen alle drei unterzubringen. was mich bei dem thema übrigends auch noch irritiert sind die vielen unterschiedlichen bezeichnungen für die operationen: return/pure/unit, >>=/bind/flatMap, join/flatten, map/fmap/<$>, ap/<*> usw. das würde ich gern unterbringen, aber ich hab auch hier noch keine gute idee wie. -- ∂ 22:11, 16. Jul. 2010 (CEST)

Ein paar Gedanken zur Vereinfachung: Ich würde flatMap überhaupt nicht, oder höchstens in einem Halbsatz im Collections-Beispiel-Abschnitt, erwähnen (zu Collection-spezifisch, zudem gibt es weitere nah-Synonyme, z.B. SelectMany ;) ), map aus ähnlichen Gründen gleichermaßen. flatten (falls es das aus Scala ist) gehört auch in diese Kategorie und hätte zum Beispiel das weitere Synonym concat. ap/<*> würde ich ganz weglassen. Halte ich für ablenkend, und einen Link zu Brents Typklassopedia haben wir ja eh schon. Ich hoffe, das liefert dir ein paar Gründe, deine Liste(n) zu verkleinern und damit die Aufgabe zu vereinfachen. --Daniel5Ko 23:42, 16. Jul. 2010 (CEST)

Einfach mal um zu senfen, weil Daniel5Ko mich gefragt hat:

Ich schlage vor, mit return und bind zu definieren, und anschließend einen Abschnitt Andere Definitionsmöglichkeiten einzuschieben, in dem wir die anderen Möglichkeiten erklären. Etwa so, z.B. als Definitionsliste:

Definition mittels >=> und return

Man kann eine Monade auch mit >=> (dem Kleisli-Kombinator [soweit ich weis]) anstatt >>= definieren, diese Definition ist äquivalent, weil man >>= somit einfach mit

a >>= b = const a >=> b $ ()

definieren kann. Etc blabla

Schlau ist es, diese Definitionen vor die Erläuterung der Gesetze zu stellen, sodass man dann diese verwenden kann. Einfach nur meine 50ct --FUZxxl^D|M|B 15:56, 14. Jan. 2011 (CET)

Hmm, ich sehe die Gesetze eigentlich als zur Definition gehörend an. Andererseits beschreitet Brent Yorgey in seiner Typeclassopedia ebenfalls den von dir skizzierten Weg. Ich denk' mal 'ne Weile drüber nach. --Daniel5Ko 21:10, 14. Jan. 2011 (CET)

Ja das geht mir auch so; ich habe mal versucht den Artikel entsprechend umzuschreiben (hauptsächlich die Definitionen und die Einleitung). Kommentare und Verbesserungen ausdrücklich erwünscht! Sobald der Entwurf stabil ist, werde ich ihn in den Artikel einarbeiten. -- Carsten Milkau (Diskussion) 15:30, 21. Okt. 2012 (CEST)

Beispiele

Hab mal zwei Beispiele hinzugefügt (Listen und Status) Kommentare erwünscht. Bitte senfen --FUZxxl^D|M|B 14:38, 17. Jan. 2011 (CET)

Wieder etwas mehr Haskell! Ich sah das mal als Problem, weil der Artikel in dem Zustand, wie ich ihn vorgefunden hatte (und jetzt eigentlich immer noch), versuchte, ziemlich allgemein zu bleiben. Aber wahrscheinlich geht das nicht so richtig und führte bisher zu viel Herumeierei.

Ich schlage vor, wir stellen ganz auf Haskell um, und verwenden dessen Terminologie. (Wenn der Syntax-Highlighter nur ein wenig dezenter wäre! :D )

Angesichts der Tatsache, dass Monaden vorallem in Haskell verwendet werden (korrigiert mich, wenn ich Quatsch labere), die Syntax recht einfach zu lesen ist und ich es kann, finde ich die Idee ganz gut. --FUZxxl^D|M|B 11:45, 18. Jan. 2011 (CET)

Nun, man könnte eigentlich sagen, Monaden sind überall. Und mehr oder weniger unterstützt werden sie schon von einigen. Das wird nur nicht explizit erwähnt.

• Scalas for-Comprehensions werden ungetypt einfach zu flatMap-Aufrufen (entspricht Haskells >>=) und Lambdaausdrücken ersetzt (weiter unten erwähnte Implicits gab es noch nicht, als das eingeführt wurde). Dahinter kann dann alles mögliche stecken, auch Dinge, die nichts mit Collections zu tun haben.
• Ähnliches tut C# 3+ mit LINQ-Ausdrücken.
• List-Comprehensions in allen möglichen Sprachen sind lediglich verdrehte Haskell-do-Blöcke. (natürlich meist (auch in Haskell, aber das war temporär mal anders) eingeschränkt auf die Listen-Monade)

--Daniel5Ko 12:55, 18. Jan. 2011 (CET)

Ähnliches in anderen Sprachen könnte man in einem gesonderten Abschnitt behandeln, und dort zum Beispiel anmerken, dass man ohne Typklassen oder einen ähnlichen Mechanismus (z.B. Implicits in Scala) nicht weit kommt, wenn man Bibliotheksfunktionen wie Control.Monad.sequence schreiben will.

Feedback zu den Beispielen: Schonmal nicht schlecht. Etwas zu groß für meinen Geschmack, und viele der Kommentare im Code kommen mir überflüssig vor (die sollten vielleicht besser in den Text). --Daniel5Ko 15:29, 17. Jan. 2011 (CET)

Mir war klar, dass das irgendjemand anmerken würde. Ich habe versucht, die Beispiele so zu verfassen, dass nur minimale Haskellkenntnisse nötig sind, um sie zu verstehen. Also etwas mehr Kommentare. --FUZxxl^D|M|B 11:18, 18. Jan. 2011 (CET)

Okay. Ignorieren wir das erstmal :) . Was sagst du zu der Idee, den Artikel grundsätzlich zunächst auf Haskell umzustellen? Fallen dir da Bedenken ein? ach, Antwort steht ja schon da...--Daniel5Ko 12:19, 18. Jan. 2011 (CET)

Syntax und damit auch die Semantik unklar

Für Haskell-Programmmierer sind die Beispiele sicher leicht verständlich, da sie mit der Syntax vertraut sind. Da ich aber kein Haskell kann, kann ich mit den Beispielen nichts anfangen und steige schon beim 1. Beispiel aus. Was ist nun a? was macht das? was ist m? Einem Haskell-Programmierer ist sicher auch unverständlich, was es mit void *(*(**o[][8])())[]; auf sich hat, einem C-Programmierer dagegen bereiten Ausdrücke wie dieser keinerlei Schwierigkeiten. *hust hust* :-) --RokerHRO (Diskussion) 21:36, 3. Mär. 2013 (CET)

Umbenennung

Ich würde mal vorschlagen, der Artikel müsste bei Gelegenheit mal umbenannt werden. "(Typkonstruktion)" ist ziemlich bedeutungslos, und selbst wenn man den Begriff als aus gängiger FP-Praxis stammend interpretiert, wo es halt Typkonstruk*toren* gibt, ist das vermutlich zu speziell. Es gibt ja andere Implementierungsmöglichkeiten. Hat jemand 'ne Idee? Die Lösung der anglophonen Kollegen ("(functional programming)") klingt etwas weniger verkehrt, könnte aber vermutlich noch verallgemeinert werden. --Daniel5Ko 00:44, 5. Mai 2011 (CEST)

dafür, "(Funktionale Programmierung)" oder was in der art wäre auf jeden fall ein fortschritt. -- ∂ 02:19, 16. Mai 2011 (CEST)

Ich währe dafür, disesn Artikel mit dem Artikel [Monade] zusammenzupacken. Beide Artikel beschreiben eigentlich exakt das gleiche, blos aus anderer Sicht. Man könnte z.B. den Artikel um praktische Aspekte und die hier angegebenen Beispiele erweitern. Falls Umbenennung währe ich für "Monade (Informatik)". --FUZxxl^D|M|B 16:55, 16. Mai 2011 (CEST)

Ich hab' vor kurzem woanders (find' ich grad nicht wieder) argumentiert, dass eine Zusammenlegung wahrscheinlich schlecht ist. Einerseits sollte der Artikel hier sich ein wenig mehr über Haskells Typklasse Monad, über LINQ, list-Comprehensions und do-Notation etc. auslassen (tut er noch nicht, hielte ich aber für einigermaßen sinnvoll), andererseits wäre dieses ganze Zeug im KT-Artikel allein schon vom Umfang her so störend, dass die Essenz dort unterginge. Ich mein, die Definition lässt sich in ungefähr einem Satz unterbringen, und viel mehr ist im allgemeinsten Fall auch nicht wirklich zu sagen. Und das, was sich ausgehend von der Definition sagen lässt, umfasst nicht alles, was ich hier gerne sähe (und vielleicht auch mal reinschreiben werde).

Ich werd' dann in ein paar Tagen mal umbenennen, denke ich, sobald ich mich zwischen den beiden Alternativen entschieden habe. :) Ich glaub', im Moment tendiere ich zum Klammerzusatz "Informatik". Danke erstmal für's Feedback. --Daniel5Ko 00:53, 17. Mai 2011 (CEST)

Ich habe den Artikel einfach mal verschoben. Mit dem Zusatz Informatik ist es auf jeden Fall besser als mit Typkonstruktion. --FUZxxl^D|M|B 23:30, 18. Mai 2011 (CEST)

K. Hätte ich morgen oder so wahrscheinlich auch gemacht. Habe Links aus dem Artikelnamensraum auch gleich mal angepasst, sodass die automatisch erzeugte Weiterleitung demnächst womöglich gelöscht werden kann. --Daniel5Ko 23:42, 18. Mai 2011 (CEST)

Monaden Komposition

Die Umbenennung des Artikels finde ich gut aber es könnte noch so einiges mehr rein. Das sämtliche Codebeispiele in Haskell sind ist zwar konsequent aber ein paar Beispiele in anderen Sprachen IM Artikel wären meiner Meinung nach eine Bereicherung. Die Erwähnung von LINQ und Scalas for-Comprehension würde dem Artikel "gut tuen". Gerade LINQ gilt als allgemein akzeptierte Technik und in diesem Zusammenhang könnte gezeigt werden das Monade ganz praktischen Nutzen haben und nicht nur ein theoretisches Konstrukt sind. Besonders interessant finde ich die Komposition von Monaden. Zum einen gibt es das Konzept der Monad Transformer zum anderen die Komposition von Monaten über Co-Produkte. Hierzu zwei Referenzen: http://www.cs.ru.nl/~W.Swierstra/Publications/DataTypesALaCarte.pdf http://isi.uni-bremen.de/~cxl/habil/papers/icfp02.pdf In den englischen Wikibooks gibt es bereits einen Eintrag zum Thema Monad Transformer. (nicht signierter Beitrag von Wikitester2501 (Diskussion | Beiträge) 21:22, 3. Apr. 2012 (CEST))

Einleitung seit 2 Jahren schwierig und unklar? :-(

Ich geb zu, ich hab nach der Einleitung und den mir unklaren Beispielen aufgehört, weiter verstehen zu wollen, was eine Monade nun eigentlich ist, was das soll und wofür man das nun eigentlich braucht und wieso:

1. Eine Monade ist ein abstrakter Datentyp. → Ok, verstehe ich. (Falls nicht, ist ADT ja verlinkt)
2. Wesentliche Eigenschaft von Monaden [ah, jetzt kommt das wichtigste!] ist die Fähigkeit der Übertragung von Werten und Berechnungen in einem „einfacheren” Typ zu Berechnungen in einem „höheren Typ” → Hier steige ich schon aus. Was ist ein einfacher Typ, was ist ein höherer Typ? Ich schwimme, aber vielleicht kommt ja gleich ein knackiges Beispiel…
3. Der Hauptnutzen von Monaden ist es, Ein- und Ausgabeoperationen, zustandsbehaftete Berechnungen und Nichtdeterminismus (auch als Iteration über Kollektionen und ihren Kombinationen interpretierbar) und anderes auszudrücken. → Ich weiß nun zwar noch immer nicht, was Monaden sind, aber man braucht sie für I/O und zustandsbehaftete Berechnungen. Na gut, in imperativen Programmiersprachen kann man beides auch ohne Monaden machen, von daher hilft mir dieser Satz immernoch nicht zu verstehen, was Monaden denn nun eigentlich sind. Ich les erstmal ratlos weiter…
4. Dann kommt ein Abstecher in die Mathematik, der mir als Nichtmathematiker aber auch nicht weiterhilft.
5. Der nächste Satz erklärt nur, wer Monaden einsetzt, aber noch immer weiß ich nicht, was das nun eigentlich ist. Ah, da kommt die Definition. Prima…
6. Leider verstehe ich die Definition nicht. Zu viele mir neue, unbekannte Fachbegriffe auf einmal. :-( Ah, es kommt ein Beispiel. Sehr gut. Das wird bestimmt helfen!
7. Pustekuchen. Das Beispiel in einer mir unbekannten Syntax versteht man anscheinend nur, wenn man die vorangegangene Definition verstanden hat. Verdammt. Ich komme so nicht weiter.
8. Ich überfliege die Beispiele auf der Suche nach einem Beispiel, das ich verstehe, etwa die oben angekündigten I/O-Operationen oder zustandsbehafteten Operationen, aber ich finde nichts dergleichen.
9. Ich breche frustriert ab. :-(

Wer kann mich (und andere Nicht-Haskell-Programmmierer) erleuchten? --RokerHRO (Diskussion) 21:53, 3. Mär. 2013 (CET)

Hier ist der Anfang einer längeren Serie von Blog-Posts. Die ersten paar (also ca. 5) habe ich gelesen und für nicht allzu schlecht befunden.

Hier ist ein mE. sehr guter Artikel, der versucht darzustellen, was dat janze soll.

Bitte mal lesen, so viel wie möglich verstehen, und dabei festhalten, welche Gedankengänge besonders hilfreich (und klauenswert! ;) ) waren.

Beides ist Haskell-Code-frei (aber nicht Mathematik-frei - wäre eh 'ne schlechte Idee: Mathematik ist äußerst hilfreich und man muss kein "Mathematiker" (so mit akademischem Grad oder wie auch immer definiert) sein, um sinnvollerweise Mathematik betreiben und benutzen zu können/zu sollten.)

--Daniel5Ko (Diskussion) 01:57, 6. Apr. 2013 (CEST)

Danke für deine Antwort. Ich wollte aber die Antwort auf meine Fragen hier in diesem Artikel finden (und damit einigermaßen sicher sein, dass das, was ich hier lese, halbwegs glaubwürdig ist) und nicht „irgendwo im Netz“ (wo ich als Laie die inhaltliche und didaktische Qualität überhaupt nicht beurteilen kann).

Daher traue ich mir nicht zu, die von dir angegebenen Quellen auszuwerten und mit ihrer Hilfe den Artikel zu verbessern. :-( --RokerHRO (Diskussion) 10:55, 30. Apr. 2013 (CEST)

Nachtrag: Ich hab den ersten Beitrag überflogen: Englisch und Textwüste. Sowas senkt die Motivation, das durchzulesen deutlich und verstärkt den Wunsch nach einem verständlichen Artikel in der deutschen Wikipedia. :-/ Zudem wird als erstes Beispiel das Singleton-Pattern genommen, das ich (und nicht nur ich) eher als Anti-Pattern sehe. Das ist ebenfalls nicht hilfreich, mit frohem Mute weiterzulesen. Ich versuch es trotzdem:

Ein Konstrukt wie Nullable<T> kenne ich von libmysql++, wo es einfach ein struct{T data; bool is_null;} ist, angereichert mit ein paar Methoden usw. (ggf. mit einer Spezialisierung, dass Nullable< Nullable<T> > eben das gleiche ist, wie Nullable<T>). Dieses Konstrukt hab ich verstanden und erkenne seinen Nutzen. :-)

Was mir irgendwie noch fehlt ist ein nachvollziehbares (aber nicht zu triviales) Beispiel, an dem man versteht, wozu man Monaden braucht bzw. wofür sie nützlich sind, und warum es gut ist, dieses Konzept zu verallgemeinern und einen eigenen Namen dafür zu kreieren.

--RokerHRO (Diskussion) 13:05, 30. Apr. 2013 (CEST)

Zum Namen: der ist eigentlich irrelevant, war aber schon da - zusammen mit haufenweiser wiederverwendbarer Theorie - als er etwa via Moggi Einzug in die Informatik und via Haskell in Programmiersprachen fand.

Zum wozu: Ich hätte ja gedacht, der Artikel hinter dem zweiten Link, also Why do monads matter, bringt ein paar verständliche Antworten. Hast du den gelesen? Kommt mir irgendwie nicht so vor... Wie dem auch sei - aus meiner Sicht ist u.a. ein ebenfalls wichtiger Punkt, dass die Verwendung von Monaden besonders nutzbringend syntaktisch unterstützt werden kann, ohne sich dabei auf eine bestimmte Monade festzulegen.

Zum nachvollziehbaren (aber nicht zu trivialen) Beispiel: Wie wär's mit Parser-Kombinatoren à-la Parsec? Continuations - a.k.a. verallgemeinerte Quantoren - wären vielleicht auch nett. In der zweiten Bedeutung gehören dazu Auswahlfunktionale wie in [1] beschrieben.

--Daniel5Ko (Diskussion) 02:22, 2. Mai 2013 (CEST)

Nein, hab ich nicht. <trotzig>…und ich will ihn auch nicht lesen müssen.</trotzig> ;-)

Laut WP:DS ist diese Diskussionsseite dazu da, den Artikel zu verbessern. Aus diesem Grund hab ich die Diskussion hier gestartet: Ich möchte einen Artikel, der mir all meine o.g. Fragen beantwortet. Ich möchte nicht auf der Diskussionsseite Links genannt bekommen, die mir die Fragen vielleicht beantworten könnten. Mag sein, dass das kleinlich ist, aber wir wollen hier eine Enzyklopädie erstellen und kein Q&A-Webforum oder eine Linksammlung, oder? :-)

Von daher möchte ich eigentlich nur Antworten wie: Okay, ich hab den Artikel überarbeitet und hoffe, er beantwortet jetzt all deine Fragen…, gerne vorher noch mit ein paar Rückfragen, die zum Erreichen dieses Ziels nötig sind.

Verstehst du, worauf ich hinaus will? --RokerHRO (Diskussion) 20:12, 2. Mai 2013 (CEST)

Ich habe einfach die Prämisse genommen: Okay, der Artikel ist vll. auch völlige Grütze. Also schauen wir mal, was andere so geschrieben haben, und ob RokerHRO mehr damit anfangen kann. Wenn das so ist, kann man ggf. vielleicht auch ermitteln, warum das so ist. Das dient natürlich der Artikelverbesserung. --Daniel5Ko (Diskussion) 00:21, 3. Mai 2013 (CEST)

Ja, du möchtest, dass andere den Artikel statt deiner bearbeiteten. Täte ich auch gerne, allerdings habe ich zur Zeit ein wenig zu tun und finde den Artikel obendrein garnicht so schlimm. Eventuell komme ich in den nächsten Wochen mal dazu. --FUZxxl^D|M|B 18:09, 4. Mai 2013 (CEST)

Einleitung nun seit 3 Jahren schwierig und unklar. Ich kam vom Artikel Future (Programmierung) her wo auf Monade bezug genommen wird. Delphi XE-7 hat nun auch Futures und ich wollte nachsehen was das ist. Freimatz (Diskussion) 14:22, 10. Sep. 2014 (CEST)

Ich glaube, dass das nur in zweiter Linie ein Problem des Artikels ist. Monaden sind notorisch schwierig zu erklären; Tutorials dafür sind so ein bischen der Running-Gag der Haskell-Gemeinschaft. Man kann sicher einiges am Artikel verbessern, ich habe persönlich aber keine Ahnung, wie man den Einleitungssatz besser formulieren könnte. Schlecht ist er, keine Frage. --FUZxxl^D|M|B 22:50, 10. Sep. 2014 (CEST)

Der Artikel Quantenphysik besteht ja auch nicht nur aus dem Satz "Quantenphysik ist zu schwierig für WP, aber hier sind ein paar Links, auf englisch, lest euch das mal durch…"

Man kann es ja wenigstens versuchen, den Artikel schrittweise zu verbessern. Ich erwarte ja gar nicht, dass ihn jemand am Stück komplett neu schreibt.

Ich helfe bei der stückweisen Verbesserung auch gerne mit, wo ich kann. So dachte ich, ich hätte einen Anfang damit gemacht, indem ich konkret auf die Schwachpunkte hingewiesen habe, bzw. beschrieben habe, wie der Artikel auf mich wirkt beim Lesen. Ich hatte gehofft, das würde denen, die mehr über Monaden wissen als ich, helfen, den Artikel zu verbessern. --RokerHRO (Diskussion) 10:29, 9. Mär. 2015 (CET)

Bildungsmangel

""Der Name Monade stammt aus der Kategorientheorie""

Man muß schon sehr ungebildet sein, um so einen Unsinn zu schreiben.

Daß der Begriff schon in der Kategorientheorie mißbraucht wurde,

ist keine Abstammung! Aber wer Leibnitz nur als Keks kennt, ..... (nicht signierter Beitrag von 84.139.124.80 (Diskussion) 09:27, 3. Jan. 2014 (CET))

kannst du mir dann vielleicht den zusammenhang zwischen Monade (Philosophie) und Monade (Kategorientheorie) erklären? -- ∂ 16:27, 3. Jan. 2014 (CET)

Fehler?

Sollte das Listenbeispiel unter Behälter nicht

data [a] = [] | a:[]

lauten, also ohne a in der hinteren eckigen Klammer? (nicht signierter Beitrag von 80.133.154.230 (Diskussion) 07:59, 17. Sep. 2015 (CEST))

Nein, sollte nicht: Das [a] bezeichnet hier den Typen [a] und nicht das Objekt [a]. Die Syntax [] bezeichnet im Kontext eines Objektes die leere Liste, im Kontext eines Typen hingegen braucht der Typ [] einen Parameter: In einem Typkonstruktor müssen stets alle Parameter benutzter Typen vollständig erfüllt sein, damit genau bekannt ist, was gemeint ist. Würde man den Parameter am Ende weglassen, dann könnte man zum Beispiel die folgenden beiden Typdeklarationen nicht unterscheiden:

data Foo a = Empty | [a]
data foo a = Empty | [Int]

Schöne Grüße, --FUZxxl^D|M|B 22:40, 17. Sep. 2015 (CEST)

Defekter Weblink

Dieser Baustein verhindert die automatische Archivierung dieses Abschnitts und seiner Unterabschnitte.

Der folgende Weblink wurde von einem Bot („GiftBot“) als nicht erreichbar erkannt.
Ausführliche Erläuterungen und Hilfe zur korrekten Behebung dieses Fehlers finden sich auf Wikipedia:Defekte Weblinks. Ist ein von einem Bot als defekt gemeldeter externer Link doch erreichbar, dann bitte berichten – wie auch sonstige Probleme.

• http://labs.mudynamics.com/2009/05/13/monadic-parser-in-javascript/
  • Vielleicht ist eine archivierte Version geeignet: archive.orghttp://giftbot.dwl.invalid/http://labs.mudynamics.com/2009/05/13/monadic-parser-in-javascript/

– GiftBot (Diskussion) 18:10, 17. Jan. 2016 (CET)

weitere defekter Weblink: Monads in Ruby. Zserik (Diskussion) 16:10, 13. Feb. 2018 (CET)

des war nix

[2] enthält eine menge redundanzen. so viele "gesetze" gibt's nämlich nicht, sondern einige lassen sich aus den anderen ableiten. das war vorher besser. -- ∂ 09:13, 17. Apr. 2016 (CEST)

Dem schließ ich mich an. Ich habe nichts mit Haskell am Hut, aber viel mit OOP. Der Einleitungssatz in der von dir verlinkten früheren Version ist nicht optimal, aber auf jeden Fall verständlicher formuliert. Wenn sich hier niemand äußert, werde ich den erst mal wieder reinsetzen. Der status quo ist unerträglich.

Es wäre besser, wenn ein Haskell-Schreiberling sich dem Artikel annehmen könnte. Mir ist die Syntax suspekt. --¸.·´¯`·.¸><((^((º> Visie (Diskussion) 01:07, 6. Jun. 2016 (CEST)--¸.·´¯`·.¸><((^((º> Visie (Diskussion) 01:07, 6. Jun. 2016 (CEST)

State Monad

Der Artikel ist durch die ausschließliche Verwendung von Haskell recht schlecht verständlich. Vor einer Weile habe ich mal mit Haskell begonnen und wollte jetzt über diese Seite das Thema Monade nochmal auffrischen, bin aber bei State komplett ausgestiegen.

Hier wird zuviel implizites Wissen und kognitive Transformation vorausgesetzt, als dass der Abschnitt für die breite Masse der Leser verständlich wird.

Ich musste mich mit einem Ausdruck hinsetzen und per Bleistift zig Dinge noch mal erschließen, die mir als Erläterung im Text fehlten. Hab dann doch meine Bibliothek durchforstet und entdeckt, dass ich in "Real World Haskell" vor Jahren ähnliche Anmerkungen an den Rand geschrieben hatte, allerdings war der dortige Text schon hilfreicher.

Was für Einsteiger fehlt:

• Warum heißt die Monade "State", obwohl sie eine Funktion kapselt, die einen Statusübergang darstellt. Wäre StateTransition nicht korrekter?

Insbesondere für Leser aus der Java OO Ecke, die mal in Scala hineingeschaut haben und inzwischen Optional und List als Container Monade kennen, ist die funktionsorientierte Monade fremd.

• Hinweis, dass Monaden generell M a definiert sind, und wieso wir nun State s a, also zwei Typparameter vorfinden. (Real World Haskell führt hier Typ-Currying vor, und plötzlich wird M a sichtbar).

• Die Implementierung von >>= ist in ihrer jetzigen Form nur schwer zugänglich, weil sie zu viel Haskell voraussetzt. Die Funktionsweise wird einem nicht mit Haskell vertrauten Leser nicht deutlich und auch nicht textuell erklärt.

• Die Hochzähl-Funktion ändert in Folge des Umbaus ihren Charakter von einer Funktion, die zwei Parameter zu einem Resulttupel mappt hin zu einer Funktion, die eine Funktion liefert, die dies tut.

Darauf wird der Leser aber nicht explizit hingewiesen.

• Es fehlt abschließend ein Beispiel, wie das gesamte Konstrukt denn angewendet wird, von der ersten Initialisierung mit einem konkreten Startwert bis hin zum Erhalt und der Auswertung des Endzustands.

State Monad - schöne Theorie, was mach ich jetzt in der Praxis damit? Gemsmith (Diskussion) 11:22, 15. Apr. 2018 (CEST)

Artikel ist komplett unverständlich

Hallo,

ich bin relativ gut im C++ programmieren und setze mich zur Zeit mit funktionaler Programmierung auseinander. Allerdings habe ich absolut keine Ahnung von Haskell. Ich habe diesen Artikel gelesen um zu verstehen was eine Monade ist, und ich muss sagen, ich bin kein Stück im Verständnis weiter gekommen. Die Formulierungen sind viel zu technisch, und die ständigen Haskell Beispiele helfen in keinster Weise, da der Syntax mir völlig fremd ist. Der Artikel Monade (Kategorientheorie) ist in meinen Augen auch nicht wirklich gut, hat mich aber zumindest ein kleines bisschen erraten lassen was eine Monade sein könnte.

Da mir (offensichtlich) das Verständnis fehlt, kann ich den Artikel leider nicht verbessern. Ich würde mir aber wünschen, dass bei den Erklärungen nachgebessert wird, und vor allem die Beispiel mit lesbarem Pseudocode ergänzt werden. (Wie es ihn zum Beispiel bei Quicksort gibt.) Denn es ist nicht wirklich hilfreich, wenn man erst Haskell lernen muss um diesen Artikel verstehen zu können...

JAS (Diskussion) 11:19, 24. Jun. 2019 (CEST)

Willkommen im Club! So wie dir ging es mir im März 2013 auch schon, siehe meinen obigen Diskussionsbeitrag. --RokerHRO (Diskussion) 22:05, 24. Jun. 2019 (CEST)

Ich bin zwar nicht wirklich gut in der Materie, und es liegt schon mehrere Jahrzehnte zurück, dass ich mich da mal vertieft eingearbeitet hatte, aber eins kann ich zu dem soeben gemachten Vorschlag sagen: „Beispiel mit lesbarem Pseudocode ergänzt“ wird und kann nicht funktionieren.

Weil, die Methodik beruht auf dem, für das Haskell (und ggf. Verwandtschaft) quasi ein Monopol hat: Einer Umkehrung der Vorgehensweise gegenüber dem, was man normalerweise zur Problemlösung anstellt, und wofür dann „Beispiel mit lesbarem Pseudocode“ verwendet würde. „Quicksort“ mit Monade gibt es, ist bloß leider nicht mehr wiederzuerkennen. Weil, „lesbarer Pseudocode“ kommt aus der „imperativen Programmierung“ und genau die wird hier nicht angefasst. Haben wir übrigens längst: Haskell (Programmiersprache) #Quicksort.

Die „Monade“ zu verstehen und das Konzept und Grundprinzip „Funktionale Programmierung“ zu verstehen ist praktisch identisch. Hat man das zweite kapiert, ist die Monade relativ klar und nur noch Begrifflichkeit; „Monade“ verstehen ohne Funktionale Programmierung muss scheitern.

Ich mache seit Mitte der 1980er mit Lambdas und LISP und sowas rum, und ich weiß, dass es eine riesige Hürde für den Einstieg ist. Dafür kann dann der arme Artikel aber nix; der wird ohne das Hintergrundverständnis nicht einfacher. Ist wie aktuelle Atomphysik, Artikel über Spin und Quarks und Strings bleiben nebulös, wenn man das Gesamtbild nicht ansatzweise als Grundlage hat.

VG --PerfektesChaos 23:35, 24. Jun. 2019 (CEST)

Monaden außerhalb Haskells

Folgender Satz ist m.E. falsch. Das ginge doch mit Generics und Typeconstraints, oder habe ich da eine Funktionalität übersehen?

"In allen drei Sprachen ist es nicht möglich, als Benutzer Funktionalität zu definieren, die mit allen Monaden umgehen kann, wie etwa Haskells sequence :: forall m a. Monad m => [m a] -> m [a]." --Diaspomod (Diskussion) 18:37, 9. Aug. 2019 (CEST)

Sehr unzugänglich

ich bin Entwickler und auch mathematisch sowie philosophisch vorgebildet, aber trotzdem ist der Artikel - besonders im ersten Teil - schwer zugänglich. Das liegt m.E. daran, dass zur Illustration Haskell verwendet wird, das nun nicht jeder kennt. Damit werfen die - sicherlich gut gemeinten - Haskell-Beispiele mehr Fragen auf als sie beantworten. Wenn man schon solche formalen Beispiele bringen möchte, dann bitte allgemeinverständlich, d.h. mathematisch notiert. --88.153.219.221 12:31, 9. Sep. 2019 (CEST)

Einer von vielen Artikeln

die (und ich meine damit beileibe nicht nur hier thematisch passende!) sich an Leute wenden, die sie vermutlich nicht oder kaum brauchen. Stolpert man aus irgend welchen Gründen und „unbeleckt“ darüber, so kann man damit absolut nichts anfangen. Z. B. weil die „Geheimsprache“, die an allen Ecken und Enden verwendet wird, in der Def:Legio:Sect->prefakt nullum ≠ sextrim ≥!≤ Expressio!! del 42 maxim redukt!

So, das war jetzt für die „hier Beleckten“. Sollen sie doch sehen, wie sie dies erklärt bekommen! (nicht signierter Beitrag von 84.166.41.143 (Diskussion) 15:14, 23. Sep. 2022 (CEST))