Duży projekt w Haskell? [zamknięte]

Don dał ci większość powyższych szczegółów, ale oto moje dwa centy od robienia naprawdę nitty-gritty stateful programów, takich jak demony systemowe w Haskell.

1. W końcu żyjesz w stosie transformatorów monad. Na dole jest IO. Powyżej, każdy główny moduł (w sensie abstrakcyjnym, a nie w sensie modułu w pliku) mapuje swój niezbędny stan do warstwy w tym stosie. Więc jeśli masz kod połączenia z bazą danych ukryty w module, piszesz to wszystko, aby być nad typem Monadreader Connection m=>... - >m ... a wtedy funkcje bazy danych zawsze mogą uzyskać połączenie bez funkcji z innych modułów, które muszą być świadome jego istnienia. Możesz skończyć z jedną warstwą zawierającą połączenie z bazą danych, inną konfigurację, trzecią różne semafory i mvary do rozdzielczości równoległości i synchronizacji, inną obsługę plików dziennika itp.

2. Najpierw Oblicz obsługę błędów . The greatest słabością w tej chwili dla Haskell w większych systemach jest mnóstwo metod obsługi błędów, w tym nędznych, takich jak Maybe (co jest złe, ponieważ nie możesz zwrócić żadnych informacji o tym, co poszło nie tak; Zawsze używaj albo zamiast Maybe, chyba że naprawdę masz na myśli brakujące wartości). Najpierw dowiedz się, jak to zrobić, i skonfiguruj Adaptery z różnych mechanizmów obsługi błędów używanych w bibliotekach i innych kodach do ostatecznego. To uratuje ci świat smutku później.

Dodatek (wydobyty z komentarzy; dzięki Lii & liminalisht) -
więcej dyskusji na temat różnych sposobów cięcia dużego programu na monady w stosie:

Ben Kolera daje wielkie praktyczne wprowadzenie do tego tematu, a Brian Hurt omawia rozwiązania problemu lift ing monadic działań w niestandardowych monad. George Wilson pokazuje jak używać mtl do pisania kodu, który działa z dowolnym monad, który implementuje wymagane typeklasy, a nie Niestandardowy rodzaj monad. Carlo Hamalainen napisał kilka krótkich, przydatnych notatek podsumowujących przemówienie George ' a.

Projektowanie dużych programów w Haskell nie różni się tak bardzo od robienia tego w innych językach. Programowanie w dużym stopniu polega na rozbiciu problemu na łatwe do opanowania kawałki i dopasowaniu ich do siebie; język implementacji jest mniej ważny.

To powiedziawszy, w dużym projekcie miło jest spróbować i wykorzystać system typów, aby upewnić się, że możesz dopasować swoje elementy do siebie tylko w sposób, który jest poprawny. Może to obejmować typy newtype lub phantom, aby rzeczy, które wydają się niech ten sam typ będzie inny.

Jeśli chodzi o refaktoryzację kodu, czystość jest wielkim dobrodziejstwem, więc staraj się utrzymać jak najwięcej kodu w czystości. Czysty kod jest łatwy do refaktoryzacji, ponieważ nie ma ukrytej interakcji z innymi częściami programu.

Nauczyłem się strukturalnego programowania funkcyjnego za pierwszym razem z tą książką . Może to nie być dokładnie to, czego szukasz, ale dla początkujących w programowaniu funkcyjnym może to być jeden z najlepszych pierwszych kroków, aby nauczyć się struktury programów funkcjonalnych-niezależnie od skali. Na wszystkich poziomach abstrakcji projekt powinien zawsze mieć wyraźnie ułożone struktury.

Rzemiosło funkcjonalne Programowanie

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

Obecnie piszę książkę o tytule "Functional Design and Architecture". Zawiera kompletny zestaw technik, jak zbudować dużą aplikację przy użyciu czystego podejścia funkcjonalnego. Opisuje wiele wzorców funkcjonalnych i pomysłów podczas budowania aplikacji podobnej do SCADA "Andromeda" do sterowania statkami kosmicznymi od podstaw. Moim głównym językiem jest Haskell. Okładka książki:

• podejścia do modelowania architektury za pomocą diagramów;
• Wymagania analiza;
• Embedded DSL domain modelling;
• zewnętrzny projekt i wykonanie DSL;
• monady jako podsystemy z efektami;
• darmowe monady jako funkcjonalne interfejsy;
• arrowised eDSLs;
• odwrócenie sterowania za pomocą darmowych monadycznych edsl;
• Pamięć Transakcyjna Oprogramowania;
• soczewki;
• State, Reader, Writer, RWS, ST monads;
• Stan nieczysty: IORef, MVar, STM;
• wielowątkowość i współbieżność domeny modelowanie;
• GUI;
• zastosowanie technik i podejść głównego nurtu, takich jak UML, SOLID, GRASP;
Interakcja z nieczystymi podsystemami.

Możesz zapoznać się z kodem do książki tutaj {[38] } oraz kodem projektu'Andromeda' .

Spodziewam się skończyć tę książkę pod koniec 2017 roku. Do tego czasu możecie przeczytać mój artykuł" Design and Architecture in Functional Programming " (Rus) tutaj .

UPDATE

Udostępniłem moją książkę online (pierwsze 5 rozdziałów). Zobacz post na Reddit

Gabriel ' s blog post skalowalne architektury programów może być warta wzmianki.

Wzorce projektowe Haskell różnią się od wzorców projektowych głównego nurtu w jednym ważny sposób:

• Architektura konwencjonalna : połączenie kilku elementów Typ A do generowania "sieci" lub "topologii" typu B

• Haskell architecture : połącz ze sobą kilka elementów typu A, aby wygenerować nowy komponent tego samego typu A, nie do odróżnienia w znak z jego części zastępczych

Uderza mnie często, że pozornie elegancka architektura często wypada z bibliotek, które wykazują to ładne poczucie jednorodności, w oddolny sposób. W Haskell jest to szczególnie widoczne-wzorce, które tradycyjnie byłyby uważane za "architekturę odgórną", zwykle są przechwytywane w bibliotekach takich jak mvc[23]}, Netwire i Cloud Haskell . To znaczy, mam nadzieję, że ta odpowiedź nie będzie interpretowana jako próba zastąpienia któregokolwiek z pozostałych w tym wątku, tylko że wybory strukturalne mogą i powinny być idealnie abstrakcyjne w bibliotekach przez ekspertów domeny. Prawdziwą trudnością w budowaniu dużych systemów, moim zdaniem, jest ocena tych bibliotek pod kątem ich architektonicznej "dobroci" wobec wszystkich Twoich pragmatycznych obaw.

Jako liminalisht wspomina w komentarzach, Kategoria design pattern jest kolejnym post by Gabriel on the topic, in a similar vein.

I have found the paper "Teaching Software Architecture Using Haskell " (pdf) by Alejandro Serrano przydatne do myślenia o wielkoskalowej strukturze w Haskell.

Być może trzeba cofnąć się o krok i pomyśleć, jak przetłumaczyć opis problemu na projekt w pierwszej kolejności. Ponieważ Haskell jest tak wysoki poziom, może uchwycić opis problemu w postaci struktur danych, działań jako procedur i czystej transformacji jako funkcji. Więc masz projekt. Rozwój rozpoczyna się, gdy skompilujesz ten kod i znajdziesz konkretne błędy dotyczące brakujących pól, brakujących instancji i brakujących transformatorów monadycznych w Twoim Kod, ponieważ na przykład wykonujesz dostęp do bazy danych z biblioteki, która wymaga pewnego stanu w ramach procedury IO. I voila, jest program. Kompilator karmić swoje szkice psychiczne i daje spójność do projektowania i rozwoju.

W ten sposób od samego początku korzystasz z pomocy Haskella, a kodowanie jest naturalne. Nie chciałbym robić czegoś "funkcjonalnego" lub "czystego" lub wystarczająco ogólnego, jeśli to, co masz na myśli, jest konkretnym zwykłym problemem. I myślę, że nadinżynieria jest w tym najniebezpieczniejszą rzeczą. Rzeczy są inne, gdy problemem jest stworzenie biblioteki, która abstrakcyjna zestaw powiązanych problemów.