FP do symulacji i modelowania

Zaraz rozpocznę projekt symulacji / modelowania. Wiem już, że OOP służy do tego rodzaju projektów. Jednak badanie Haskella skłoniło mnie do rozważenia zastosowania paradygmatu FP do modelowania układu komponentów. Pozwól mi rozwinąć:

Załóżmy, że mam komponent typu A, charakteryzujący się zestawem danych (parametr taki jak temperatura lub ciśnienie, PDE i niektóre warunki brzegowe itp.) Oraz komponent typu B, charakteryzujący się innym zestawem danych (różnym lub ten sam parametr, różne PDE i warunki brzegowe). Załóżmy również, że funkcje / metody, które zostaną zastosowane do każdego komponentu, są takie same (na przykład metoda Galerkina). Zmienny stan obiektu zostałby zastosowany do parametrów niestałych.

Gdybym miał zastosować podejście OOP, stworzyłbym dwa obiekty, które enkapsulowałyby dane każdego typu, metody rozwiązywania PDE (dziedziczenie byłoby tu użyte do ponownego użycia kodu) i rozwiązanie PDE.

Z drugiej strony, gdybym miał zastosować podejście FP, każdy komponent byłby podzielony na części danych i funkcje, które działałyby na dane w celu uzyskania rozwiązania dla PDE. Parametry niestałe byłyby przekazywane jako funkcje czegoś innego (na przykład czas) lub wyrażane przez pewnego rodzaju zmienność (emulacja zmienności itp.) To podejście wydaje mi się prostsze, zakładając, że liniowe operacje na danych byłyby trywialne.

Podsumowując, czy wdrożenie podejścia FP byłoby faktycznie prostsze i łatwiejsze w zarządzaniu (dodaj inny typ komponentu lub nową metodę rozwiązania pde) w porównaniu do OOP?

Pochodzę z środowisk C ++ / Fortran, a ponadto nie jestem profesjonalnym programistą, więc popraw mnie na wszystko, co popełniłem źle.

Dobre pytanie, myślałem podobnie. Historycznie, paradygmat OO powstał z potrzeby symulacji komputerowej - zobacz historię Simuli - i pomimo wczesnych języków OO, takich jak Smalltalk , tworzonych przez ludzi, którzy wiedzieli, co robią (tj. Alan Kay), OO jest obecnie prawdopodobnie nadmiernie wykorzystywany i wprowadza o wiele za dużo przypadkowej złożoności .

Ogólnie rzecz biorąc, programy w stylu FP będą krótsze, łatwiejsze do testowania i łatwiejsze do modyfikacji niż programy OO. Jak to ujął Rob Harrop w swoim wystąpieniu: Czy przyszłość jest funkcjonalna? , nigdy nie możesz być prostszy niż funkcje i dane; oba komponują się nieskończenie, aby stworzyć wszelkie potrzebne abstrakcje. Tak więc jednym ze sposobów udzielenia odpowiedzi na pytanie (czy po prostu go odtwarzam? :) jest pytanie, jaka jest funkcja najwyższego poziomu i jak wyglądają dane wejściowe najwyższego poziomu -> dane wyjściowe? Następnie możesz zacząć rozkładać funkcje „alfa” i typy danych na następną warstwę abstrakcji i powtarzać w razie potrzeby.

Inną perspektywą (nie całkiem odpowiedzi) na twoje pytanie jest spojrzenie na ten wątek (wyłączenie odpowiedzialności, zacząłem go) na StackOverflow, niektóre odpowiedzi są bardzo interesujące: /programming/3431654/how-does- funkcjonalne programowanie-zastosowanie-do symulacji

Moje własne zdanie w tym momencie jest takie, chyba że modelujesz sytuację, w której naprawdę istnieją dyskretne obiekty, które oddziałują tylko w określony sposób (np. Model sieci komputerowej) - a zatem odwzorowują bezpośrednio możliwości czystego komunikatu przelotny paradygmat język OO - łatwiej jest przejść na FP. Zauważ, że nawet w społeczności programistów gier - gdzie symulacje są bardzo rozpowszechnione, a wymagania dotyczące wydajności są najważniejsze - doświadczeni programiści odchodzą od paradygmatu OO i / lub używają większej liczby FP, np. Patrz ta dyskusja HN lub komentarze Johna Carmacka na temat FP

IMHO na prawie każde zadanie o rozsądnej złożoności nie można obiektywnie odpowiedzieć na pytanie „styl FP lub styl OOP lepszy wybór”. Zazwyczaj w takiej sytuacji pytaniem nie jest „ani FP, ani OOP”, ale jak połączyć najlepsze części obu paradygmatów w celu rozwiązania problemu.

Problem, który naszkicowałeś powyżej, wydaje się bardzo matematyczny, i przypuszczam, że będziesz potrzebować kilku operacji na macierzach. OOP jest bardzo dobry do modelowania abstrakcyjnych typów danych, a rachunek macierzowy można łatwo zaimplementować jako „obiekty macierzy” za pomocą operacji na macierzach. Zaimplementowanie tego w sposób, w którym wszystkie operacje na macierzach są częścią klasy macierzy, pomaga utrzymać razem rzeczy, które do siebie należą, dzięki czemu zachowana jest dobra ogólna struktura.

Z drugiej strony, PDE są równaniami funkcji, a rozwiązaniem może być znowu funkcja. Zatem zastosowanie funkcjonalnego podejścia do tego rodzaju „komponentów” może wydawać się tutaj naturalne. Funkcje te mogą mieć parametry macierzy, pokazujące jeden przykład połączenia OOP i FP. Innym przykładem może być implementacja klasy macierzy, która wykorzystuje narzędzia funkcjonalne do mapowania określonej operacji na każdy element macierzy. Także tutaj nie jest to „OOP kontra FP”, ale „OOP w połączeniu z FP”, który przynosi najlepsze wyniki.