Monaden sind in der Welt der funktionalen Programmierung insbesondere in Haskell ein oft missverstandenes Konzept. Viele Entwickler und Einsteiger in Haskell kämpfen mit der richtigen Einordnung von Monaden und den damit verbundenen Begrifflichkeiten. Insbesondere kursieren zahlreiche falsche Annahmen darüber, was eine Monade ist oder eben nicht ist. Ein besseres Verständnis dieser Grenzen und Klarstellungen hilft, Monaden richtig anzuwenden und vermeidet häufige Verwirrungen. Dieser Text befasst sich mit den zentralen Missverständnissen rund um Monaden und definiert eindeutig, was Monaden nicht sind – basierend auf den Erkenntnissen und Diskussionen aus HaskellWiki von 2020. Zunächst ist es wichtig zu verstehen, dass Monaden keine Spracheigenschaft von Haskell sind. Sie sind kein eigenes Feature, das extra in die Sprache eingebaut wurde. Vielmehr sind Monaden als Abstraktion innerhalb von Haskell definiert. Das bedeutet, dass Haskell selbst ohne Monaden funktionieren würde.
Die Nutzung von Monaden, beispielsweise im Umgang mit Ein- und Ausgabe (IO), ist zwar mittlerweile Standard, aber nicht zwingend erforderlich für die Funktionalität der Sprache. IO wird in Haskell definiert durch die Konstruktion eines Monaden-Typs, doch theoretisch könnte man auch eine andere Lösung wählen, die ähnliche Möglichkeiten bietet, ohne explizit auf Monaden zurückzugreifen. Ein häufiger Irrtum ist die Annahme, dass Monaden etwas mit Unreinheit (Impurity) zu tun hätten. Diese Vorstellung ist verkehrt. Monaden an sich sind weder rein noch unrein. Die Unreinheit ergibt sich nur dann, wenn Monaden wie die IO-Monade verwendet werden, die neben der eigentlichen Funktionalität auch Seiteneffekte bedienen. Diese IO-Monade kann man als unrein ansehen, weil sie den Effekt hat, mit der Außenwelt zu kommunizieren. Das ist jedoch kein generelles Merkmal aller Monaden.
In Wirklichkeit sind Monaden pure Abstraktionen, die Eingaben, Ausgaben oder Zustände auf einer rein funktionalen Ebene modellieren und kapseln. Ebenso falsch ist die Behauptung, Monaden seien ausschließlich um das Management von Zustand oder State zuständig. Es stimmt zwar, dass man mit Monaden State-Übergänge gut modellieren kann – und die State-Monade ist hierfür ein klassisches Beispiel. Doch Monaden beschränken sich keineswegs darauf. Es existiert eine Vielzahl von Monaden, die keinerlei Zustand speichern oder verändern, zum Beispiel die Identity-Monade, die Reader-Monade, die List-Monade oder die Exception-Monade. Monaden sind also wesentlich grundlegender und nicht auf einen bestimmten Zweck beschränkt wie State-Management. Des Weiteren sollte man Monaden nicht mit Striktheit in Verbindung bringen.
Die grundlegenden Operationen einer Monade – sogenannten bind (>>=) und return – müssen strikt genommen nicht strikt sein, im Gegenteil, sie sind im Haskell-Kontext sogar nicht-strikt. Dennoch gibt es spezifische Operationen einzelner Monaden, die teilweise streng ausgewertet werden, etwa die IO-Monade. Andere, wie die Listen-Monade, sind nicht strikt. Diese Variabilität verdeutlicht, dass Striktheit eine Eigenschaft der konkreten Monade ist und nicht der Monade als abstraktes Konzept. Monaden sind auch keine Werte im herkömmlichen Sinne. Sie sind vielmehr Abstraktionen, die das Verhalten oder die Beziehung zwischen Werten beschreiben. Ein Vergleich macht dies klar: So wenig wie Addition oder Multiplikation selbst Zahlen sind, sind Monaden keine Werte, sondern Beschreibungen von Operationen und Zusammenhängen zwischen Werten in einem bestimmten Kontext.
Man kann Monaden als Funktoren verstehen, die zusätzliche Struktur und Operationen auf Werte anwenden ohne deren reinen Charakter zu verletzen. Ebenfalls wichtig ist der Unterschied zwischen Monaden und Applicative Functors. Monaden ersetzen nicht die Applicative Functors, vielmehr sind Monaden eine Erweiterung davon. Jeder Monad ist außerdem ein Applicative Functor. Es ist guter Stil, dort, wo nur eine Applicative benötigt wird, nicht sofort den bind-Operator (>>=) zu verwenden. Applicative Functors können viele Anwendungsfälle abdecken, vor allem wenn Sequenzierung ohne Abhängigkeit von Zwischenergebnissen ausreicht. Das Monadenkonzept erlaubt hingegen das Einfließen von früheren Ergebnissen in die Auswertung späterer Schritte. Das macht Monaden mächtiger, aber auch komplexer. Ein weiterer weitverbreiteter Irrtum ist, dass Monaden grundsätzlich zur Steuerung der Reihenfolge von Operationen dienen.
Monaden werden zwar oft benutzt, um die Reihenfolge von Berechnungen festzulegen – vor allem im Zusammenhang mit IO oder State – doch ist dies keine notwendige Eigenschaft aller Monaden. Es existieren nämlich kommutative Monaden, die keinerlei Reihenfolge an Vorgaben besitzen, wie die Reader-Monade. Das bewirkt, dass Reihenfolge und Sequenzierung zwar typische Anwendungen von Monaden sind, jedoch nicht zu ihrer essenziellen Definition gehören. Die Vorstellung, Monaden seien komplizierte abstrakte Konstrukte, ist teilweise berechtigt, aber es lohnt sich, sie als mehr als nur ein Werkzeug zum „Reihenfolgen-Schieben“ oder „Status-Verbergen“ zu betrachten. Sie sind vielmehr eine hochgradig generische und elegante Kategorientheorie-basierte Abstraktion, die komplexe Beziehungen zwischen Werten und Effekten modelliert. Dabei ist das Verhältnis zur Kategorientheorie als Monoidobjekt in der Kategorie der Endofunktoren ausschlaggebend.
„return“ entspricht dem Einselement und „join“ einer Verknüpfung – das ist zwar abstrakt, beschreibt aber präzise die Essenz einer Monade. Für Programmierer, die den tieferen Sinn von Monaden verstehen wollen, ist es sinnvoll, den Unterschied zwischen „Binding“ und „Assignment“ zu reflektieren. Equational reasoning in Haskell unterscheidet sich hier fundamental von konventioneller imperativer Programmierung. Monaden erlauben Bindungen an Namen, die Werte repräsentieren, ohne unmittelbar deren Reihenfolge oder strikte Auswertung festzulegen. Dies ist grundlegend für das reine Lisp-ähnliche Berechnungsmodell, das Haskell verfolgt. Abschließend lässt sich sagen, dass Monaden in Haskell ein vielschichtiges Konzept darstellen, das weit über einfache praktische Anwendungen hinausgeht.
Sich von falschen Vorstellungen zu lösen, wie Monaden Unreinheit erzeugen, ausschließlich für Zustand zuständig sind oder primär der Reihenfolge dienen, schafft eine solide Basis für tieferes Verständnis und sinnvollere Programmierpraxis. Monaden sind keine Werte, sie sind kein Sprachfeature, sie sind weder strikt noch zwangsläufig impure – sondern abstrakte Bauklötze für strukturierte Programmierung in einem rein funktionalen Umfeld. Das Erkennen dieser Tatsachen öffnet den Blick für neue kreative Anwendungen und vermindert die Frustration vieler Einsteiger in die funktionale Programmierung. Wer Monaden also richtig verstehen will, sollte sich zunächst von diesen Missverständnissen befreien und ihre wahre Natur als elegante Abstraktion begreifen.
