Warum ich Monaden nicht verstehe
Seit einiger Zeit stelle ich fest, dass ich für viele Sachen einfach zu doof bin. Ich gebe auch zu, dass mich das ärgert. Mittlerweile bin ich aber fast dahinter gekommen, warum ich dafür zu doof bin. Und genau das ist (vieleicht!) meine Chance.
Ich mache jetzt auch keinen Versuch, Monaden mit dem was ich davon mitbekommen habe zu erklären. Ich weiss ja nich nicht einmal genau, was ich mit Monaden anfangen könnte, wenn ich sie verstehen würde. Jetzt wäre natürlich die Frage angebracht, warum ich mich mit etwas rumärgere, wenn ich nich nicht mal weiss was ich davon haben könnte. Allerdings habe mir die Frage auch nicht gestellt, als ich 1980 das Buch “Programmierung des Z80″ gekauft hatte, um Z80-Maschinensprache zu lernen. Erst als ich das einigermassen konnte, habe ich meinen ersten Computer gekauft. Vorher hatte ich einmal in der Woche die Gelegenheit Mittwochs abends mit einem Einplatinencomputer zu arbeiten. Dort konnte ich dann meine Ideen ausprobieren. Später hatte ich selber einen Einplatinencomputer, den “Micro-Professor” (lächerlicher Name [nebenbei]). Dazu muss man allerdings wissen, dass zu dieser Zeit Hobby-Computer mit dem selben Nimbus verkauft wurden, wie Spielzeug-Dampfmaschinen in den Jahrzehnten vorher: Der Filius sollte ein kleiner James Watt werden.
Ohne also zu Wissen, wozu das Programmieren eines Computers gut ist, habe ich also einfach mal damit angefangen. Dann habe ich festgestellt, dass mir Microprozessoren etwas rätselhaft erscheinen. Ich musste mir irgendwie klar machen, wie das Funktionieren des Mikroprozessors aus dem Schalten seiner Transistoren verstanden kann. Nicht in allen Details, aber nachdem ich Multiplexer, Tore, FlipFlops und Halbaddierer verstanden hatte war ich soweit zufrieden. Zum Lieferumfang des Einplatinencomputers gehörte auch eine vollständiger Assembler-Abdruck des Betriebssystems, dass man dann lesen konnte. Das hat mir viel dabei geholfen zu lernen, wie eine Tastatur oder ein Display angesteuert wird und wie die Magnetische Aufzeichung von Daten auf Cassetten funktioniert. (Keine Angst ich komme auf mein Problem mit den Monaden zurück!).
Später hatte ich nochmal ein ähnliches Problem im Zusammenhang mit objektorientierter Programmierung. Borland Pascal 5.5 war auf den Markt gekommen und wartete mit einen OOP-Zusatz auf. Lange habe ich jene grausligen Tutorials über Vererbung und virtuelle Methoden (damals als ‘Message’ bezeichnet) gelesen, in so sinnfällige Sätze stehen wie “Die Klasse ‘Biene’ ist von der Klasse ‘Fluginsekt’ abgeleitet und hat zusätzlich die Eigenschaft ‘Stachel’ … blah blah blah und versteht neben der ererbten Botschaft ‘flieg!’ auch noch die Botschaft ‘Stich!’ …. bla bla bla. Das hat mir NICHT weitergeholfen. Erstens deswegen nicht, weil ich zuerst nicht wusste was der ganze Mist übrhaupt soll, zweitens deswegen nicht, weil ich nicht verstand wie der Compiler das überhaupt fertigbringt, das er ja den Aufruf der Botschaft ‘Flieg!’ nicht in den Code compilieren kann. Und jetzt kommt der entscheidende Punkt: erst als ich vollständig verstanden habe, dass dieser eine Sprungleiste für jede Klasse anlegt, diese beim vererben in die neue Klasse kopiert, einzelne Einträge bedarfsweise überschreibt und die Prozeduraufrufe als indirekte Unterprogrammsprünge über einen Index in diese Sprungleiste kompiliert hatte ich verstanden …
Noch ein Beispiel? Danach dann wieder zurück zu denen Monaden, zu denen ich leider immer noch nichts verwertbares sagen kann….
Ich hatte meinen ersten Job, in dem ich zwei Jahre lang die Federführung über die Weiterentwicklung eines Compilers für die Programmiersprache Dylan zu übernehmen hatte. Ich hatte vorher schon zwei Compilerbau-Projekte für Spezialsprachen abgewickelt und fühlte mich einigermassen gerüstet. Der Compiler machte in bestimmten zusammenhängen Fehler in der Behandlung von Closures. Das Problem war: Zu der Zeit wusste ich nicht mal was eine Closure wirklich ist. Mir war zwar aus Lisp 1.5 das Konzept der Dynamischen Bindung und die Assoc-Listen bekannt, aber nicht wie man bei einer mit Lexikalischer Bindung arbeitenden Programiersprache erreichen soll, dass eine Variable nach dem abräumen des Stacks für eine innere Funktion, die exportiert wurde, noch zur Verfügung stehen kann. Bei Lisp 1.5 fällt der Zugriff auf die alte Variablenbindung nämlich einfach dadurch ab, dass die A-Liste von Aufruf zu Aufruf weitergereicht und ggf ergänzt wird.
Die Lösung des Problems für Lexikalische Bindung ist einfach die, dass man feststellt, welche freien Variablen die zurückgelieferte Funktion verwendet und aus diesen Variablenbindungen und der Funktion ein neues Gebilde zusammenpappt (die “Closure” eben!) und dann diese anstatt der reinen Funktion als Wert zurück an den Aufrufer liefert. So banal ist eine Closure, so habe ich es dann auch umgesetzt und die Nutzer des Compilers - etwa 20 Entwickler - waren zufrieden damit - Auch wenn nicht alle davon Closures wissentlich verwendet haben. Aber auch hier: Ich habe erst dann verstanden was das Konzept Closure bedeutet, als ich gelernt habe was sich technisch dahinter verbirgt und nicht aufgrund irgendeines abstrakten Geseihers. Und ich zweifle auch daran, dass ich heute Closures verwenden würde wenn ich ich versucht hätte, sie als Konzept der reinen mathematischen Logik zu verstehen. Informatik ist am Ende immer eine Tun-Wissenschaft, die Neue Konzepte und Ideen aufbauend auf vorhandenen umsetzt und keine Sammlungen von esoterischen Einfällen. Auch wenn man auf Besprechungen und Kozeptpräsentationen leicht zu einer anderen Überzeugung kommen möchte.
Zurück zu den Monaden, die mich derzeit wie ein bisschen zwicken und jucken. Man findet im Internet viel Material darüber, allerdings hat bisher nichts davon mir bisher ein “Ah!” entlocken können. Ich weiss ja schon lange dass man immer große Hoffnungen auf die Amerikanischen Internet-Autoren setzen kann, da diese sich immer sehr viel Mühe geben auch verstanden zu werden. Die Europäer sind da öfter anders drauf. Nicht selten versuchen diese nicht ernsthaft, etwas zu erklären, sondern suchen die Bewunderung unter der Leserschaft. Im speziellen Fall der Monaden gibt es übrigens fast keinen Beitrag in dem nicht erwähnt ist, daß das Internet voll von Beiträgen zu Monaden ist. Und - ja - ich kann diese Ansicht teilen und um so größer ist meine Frustration darüber, dass diese Materie nicht in meinen Kopf will. Die Programmiersprache, die ich derzeit am besten kenne ist Perl und versuche gerade meine Kenntnisse in Common Lisp zu vervollständigen. Was mir am besten helfen würde, wäre ein konstruktive Einführung, in der Monaden in Common Lisp oder Perl implementiert und erläutert würden. Ich füchte aber, dass ich am Ende der langen Weg gehen und Haskell lernen muss. Sobald ich dann die Monaden verstanden habe, gelobe ich, keinen Blogbeitrag über Monaden zu schreiben. Denn die Eingeweihten und Versteher der Monaden, beklagen sich an allen Ecken und Enden darüber, dass jeder, bei dem der Groschen gefallen ist, anschließend darüber bloggt.
Werde ich nicht tun, versprochen!