Großflächiges Design in Haskell?

Don gab Ihnen die meisten der oben genannten Details, aber hier sind meine zwei Cents, die ich von der Ausführung wirklich komplizierter Stateful-Programme wie System-Daemons in Haskell habe.

1. Am Ende leben Sie in einem Monadentransformatorstapel. Unten ist IO. Darüber hinaus ordnet jedes Hauptmodul (im abstrakten Sinne, nicht im Sinne von Modul in einer Datei) seinen erforderlichen Status einer Ebene in diesem Stapel zu. Wenn Sie also Ihren Datenbankverbindungscode in einem Modul versteckt haben, schreiben Sie alles so, dass es über einen MonadReader-Verbindungstyp m => ... -> m ... erfolgt, und dann können Ihre Datenbankfunktionen ihre Verbindung immer ohne Funktionen von anderen erhalten Module müssen sich ihrer Existenz bewusst sein. Es kann vorkommen, dass eine Ebene Ihre Datenbankverbindung enthält, eine andere Ihre Konfiguration, eine dritte Ihre verschiedenen Semaphoren und MVARs für die Auflösung von Parallelität und Synchronisation, eine andere Ihre Protokolldatei-Handles usw.

2. Finden Sie Ihre Fehlerbehandlung heraus first. Die größte Schwäche für Haskell in größeren Systemen ist derzeit die Fülle an Fehlerbehandlungsmethoden, einschließlich mieser Methoden wie "Vielleicht" (was falsch ist, weil Sie keine Informationen darüber zurückgeben können, was schief gelaufen ist) nur fehlende Werte bedeuten). Überlegen Sie sich zunächst, wie Sie vorgehen sollen, und richten Sie Adapter aus den verschiedenen Fehlerbehandlungsmechanismen ein, die Ihre Bibliotheken und anderer Code in Ihrem endgültigen Mechanismus verwenden. Dies wird Ihnen später eine Welt der Trauer ersparen.

Nachtrag (aus Kommentaren entnommen; danke an Lii & liminalisht ) -
Weitere Diskussion über verschiedene Möglichkeiten, ein großes Programm in Monaden in einem Stapel aufzuteilen:

Ben Kolera gibt eine praktische Einführung in dieses Thema, und Brian Hurt erörtert Lösungen für das Problem, lift monadische Aktionen in Ihre benutzerdefinierte Monade zu integrieren. George Wilson zeigt, wie Sie mit mtl Code schreiben, der mit jeder Monade funktioniert, die die erforderlichen Typklassen implementiert, und nicht mit Ihrer benutzerdefinierten Monadenart. Carlo Hamalainen hat einige kurze, nützliche Notizen geschrieben, die Georges Vortrag zusammenfassen.

Das Entwerfen großer Programme in Haskell unterscheidet sich nicht wesentlich von anderen Sprachen. Beim Programmieren im Großen und Ganzen geht es darum, Ihr Problem in überschaubare Teile zu unterteilen und diese zusammenzufügen. Die Implementierungssprache ist weniger wichtig.

Das heißt, in einem großen Design ist es schön, das Typensystem zu nutzen, um sicherzustellen, dass Sie Ihre Teile nur auf die richtige Weise zusammenfügen können. Dies kann neue Typen oder Phantomtypen umfassen, um Dinge, die den gleichen Typ zu haben scheinen, unterschiedlich zu machen.

Wenn es darum geht, den Code im Laufe der Zeit zu überarbeiten, ist Reinheit ein großer Segen. Versuchen Sie daher, den Code so weit wie möglich rein zu halten. Reiner Code lässt sich leicht umgestalten, da er keine versteckte Interaktion mit anderen Teilen Ihres Programms aufweist.

Mit dieses Buch habe ich das erste Mal strukturierte Funktionsprogrammierung gelernt. Es ist vielleicht nicht genau das, wonach Sie suchen, aber für Anfänger in der funktionalen Programmierung ist dies möglicherweise einer der besten ersten Schritte, um die Strukturierung funktionaler Programme zu erlernen - unabhängig von der Skala. Auf allen Abstraktionsebenen sollte das Design immer klar strukturiert sein.

Das Handwerk der funktionalen Programmierung

http://www.cs.kent.ac.uk/people/staff/sjt/craft2e/

Ich schreibe gerade ein Buch mit dem Titel "Functional Design and Architecture". Es bietet Ihnen einen vollständigen Satz von Techniken zum Erstellen einer großen Anwendung unter Verwendung eines rein funktionalen Ansatzes. Es beschreibt viele Funktionsmuster und -ideen beim Erstellen einer SCADA-ähnlichen Anwendung 'Andromeda' zur Steuerung von Raumschiffen von Grund auf neu. Meine Hauptsprache ist Haskell. Das Buch umfasst:

• Ansätze zur Architekturmodellierung anhand von Diagrammen;
• Anforderungsanalyse;
• Embedded DSL Domain Modellierung;
• Externes DSL Design und Implementierung;
• Monaden als Subsysteme mit Effekten;
• Freie Monaden als funktionale Schnittstellen;
• Pfeilförmige eDSLs;
• Umkehrung der Kontrolle mit freien monadischen eDSLs;
• Software-Transaktionsspeicher;
• Linsen;
• Zustand, Leser, Verfasser, RWS, ST-Monaden;
• Unreiner Zustand: IORef, MVar, STM;
• Multithreading und gleichzeitige Domänenmodellierung;
• GUI;
• Anwendbarkeit von Mainstream-Techniken und Ansätzen wie UML, SOLID, GRASP;
• Interaktion mit unreinen Subsystemen.

Sie können sich mit dem Code für das Buch hier und dem 'Andromeda' Projektcode vertraut machen.

Ich rechne damit, dieses Buch Ende 2017 fertig zu stellen. Bis dahin können Sie meinen Artikel "Design und Architektur in der funktionalen Programmierung" (Rus) lesen hier .

[~ # ~] Update [~ # ~]

Ich habe mein Buch online geteilt (erste 5 Kapitel). Siehe Beitrag auf Reddit

Gabriels Blogpost Skalierbare Programmarchitekturen könnte eine Erwähnung wert sein.

Haskell-Designmuster unterscheiden sich in einer wichtigen Hinsicht von den gängigen Designmustern:

• Konventionelle Architektur : Kombinieren Sie mehrere Komponenten des Typs A, um ein "Netzwerk" oder eine "Topologie" des Typs B zu generieren

• Haskell-Architektur : Kombinieren Sie mehrere Komponenten des Typs A, um eine neue Komponente desselben Typs A zu erzeugen, deren Charakter sich nicht von ihren Substituenten unterscheidet

Es fällt mir oft auf, dass eine anscheinend elegante Architektur häufig aus Bibliotheken herausfällt, die dieses schöne Gefühl der Homogenität auf eine Art von unten nach oben aufweisen. In Haskell wird dies besonders deutlich: Muster, die traditionell als "Top-Down-Architektur" betrachtet werden, werden in Bibliotheken wie mvc , Netwire und Cloud Haskell) erfasst . Das heißt, ich hoffe, diese Antwort wird nicht als Versuch interpretiert, einen der anderen in diesem Thread zu ersetzen, sondern nur, dass strukturelle Entscheidungen idealerweise von Domain-Experten in Bibliotheken abstrahiert werden können und sollten. Die eigentliche Schwierigkeit beim Aufbau großer Systeme besteht meiner Meinung nach darin, diese Bibliotheken anhand ihrer architektonischen "Güte" im Vergleich zu all Ihren pragmatischen Bedenken zu bewerten.

Wie liminalisht in den Kommentaren erwähnt, The category design pattern ist ein weiterer Beitrag von Gabriel zum Thema, ähnlich.

Ich habe den Artikel " Teaching Software Architecture Using Haskell " (pdf) von Alejandro Serrano als nützlich für groß angelegte Überlegungen angesehen Struktur in Haskell.

Vielleicht müssen Sie einen Schritt zurückgehen und überlegen, wie Sie die Beschreibung des Problems überhaupt in ein Design umsetzen können. Da Haskell so hoch ist, kann es die Beschreibung des Problems in Form von Datenstrukturen, die Aktionen als Prozeduren und die reine Transformation als Funktionen erfassen. Dann hast du ein Design. Die Entwicklung beginnt, wenn Sie diesen Code kompilieren und konkrete Fehler zu fehlenden Feldern, fehlenden Instanzen und fehlenden monadischen Transformern in Ihrem Code finden, da Sie beispielsweise einen Datenbankzugriff aus einer Bibliothek ausführen, die eine bestimmte Statusmonade innerhalb eines IO Prozedur. Und voila, da ist das Programm. Der Compiler füttert Ihre mentalen Skizzen und gibt Kohärenz für das Design und die Entwicklung.

Auf diese Weise profitieren Sie von Anfang an von der Hilfe von Haskell, und die Codierung ist natürlich. Ich würde mich nicht darum kümmern, etwas "Funktionales" oder "Reines" oder genug Allgemeines zu tun, wenn Sie ein konkretes gewöhnliches Problem im Sinn haben. Ich denke, Überentwicklung ist die gefährlichste Sache in der IT. Anders verhält es sich, wenn das Problem darin besteht, eine Bibliothek zu erstellen, die eine Reihe verwandter Probleme zusammenfasst.