Jaki jest dobry sposób projektowania / struktury dużych programów funkcjonalnych, zwłaszcza w Haskell?
Przeszedłem kilka samouczków (Napisz do mnie jako ulubiony program, a Real World Haskell jest na drugim miejscu) - ale większość programów jest stosunkowo niewielka i ma jeden cel. Ponadto nie uważam niektórych z nich za szczególnie eleganckie (na przykład obszerne tabele odnośników w WYAS).
Chcę teraz pisać większe programy z większą ilością ruchomych części - pozyskiwanie danych z różnych źródeł, czyszczenie, przetwarzanie na różne sposoby, wyświetlanie ich w interfejsach użytkownika, utrwalanie, komunikowanie się w sieci itp. W jaki sposób jedna najlepsza struktura takiego kodu, aby była czytelna, łatwa w utrzymaniu i dostosowywana do zmieniających się wymagań?
Istnieje dość duża literatura zajmująca się tymi pytaniami dla dużych programów imperatywnych zorientowanych obiektowo. Pomysły takie jak MVC, wzorce projektowe itp. Są przyzwoitymi receptami na realizację ogólnych celów, takich jak rozdzielenie obaw i ponowne wykorzystanie w stylu OO. Ponadto nowsze języki rozkazujące nadają się do refaktoryzacji w stylu „projektu w miarę dorastania”, do którego moim zdaniem nowicjusz Haskell wydaje się mniej odpowiedni.
Czy istnieje odpowiednik literatury dla Haskell? W jaki sposób najlepiej wykorzystać do tego celu zoo egzotycznych struktur kontrolnych w programowaniu funkcjonalnym (monady, strzały, aplikacje itp.)? Jakie najlepsze praktyki możesz polecić?
Dzięki!
EDYCJA (jest to kontynuacja odpowiedzi Dona Stewarta):
@dons wspomniał: „Monady przechwytują kluczowe projekty architektoniczne rodzajów”.
Myślę, że moje pytanie brzmi: jak myśleć o kluczowych projektach architektonicznych w czysto funkcjonalnym języku?
Rozważ przykład kilku strumieni danych i kilku etapów przetwarzania. Potrafię pisać modułowe parsery dla strumieni danych do zestawu struktur danych, a każdy etap przetwarzania mogę zaimplementować jako czystą funkcję. Kroki przetwarzania wymagane dla jednego elementu danych będą zależeć od jego wartości i innych ”. Po niektórych krokach powinny pojawić się skutki uboczne, takie jak aktualizacje GUI lub zapytania do bazy danych.
Jaki jest „właściwy” sposób, aby ładnie powiązać dane i kroki analizy? Można napisać dużą funkcję, która robi właściwe dla różnych typów danych. Lub można użyć monady, aby śledzić, co zostało przetworzone do tej pory i aby każdy krok przetwarzania uzyskał to, czego potrzebuje dalej od stanu monady. Lub można napisać w dużej mierze osobne programy i wysyłać wiadomości (nie podoba mi się ta opcja).
Slajdy, które podłączył, mają punkt Rzeczy, których potrzebujemy: „Idiomy do mapowania projektu na typy / funkcje / klasy / monady”. Jakie są idiomy? :)
