W przypadku jakich typowych problemów programowanie funkcjonalne nie jest dobre? [Zamknięte]

22

Programowanie funkcjonalne jest deklaratywnym paradygmatem. Jedną z mocnych stron FP jest unikanie skutków ubocznych. Mówi się, że w przypadku niektórych problemów FP nie jest dobrym dopasowaniem.

W przypadku jakich typowych problemów programowanie funkcjonalne nie jest dobrze dopasowane?

Jonas
źródło
Uff! Przez chwilę myślałem, że powiedziałeś „jest wadliwym paradygmatem”. Potem wróciłem i sprawdziłem.
Mark C
1
Myślę, że dokładniej jest powiedzieć, że skutki uboczne są izolowane (w każdym razie w Haskell), niż można tego uniknąć. Monady pozwalają na zmiany stanu, a jedna jest nawet nazywana „stanem”.
Larry Coleman,
Jak wyjaśnił Larry Coleman, nie jest prawdą, że programowanie funkcjonalne unika skutków ubocznych, ale że zniechęca do ich stosowania, aw niektórych językach wyraźnie je izoluje. Przeczytaj np. Rozdział 7 research.microsoft.com/en-us/um/people/simonpj/papers/…
Giorgio

Odpowiedzi:

17

Aplikacje o bardzo stanowym charakterze. Gry wideo są dobrym przykładem, ponieważ modelują prawdziwy świat. Znacznie bardziej sensowne jest myślenie o zmianie stanu świata zamiast odbudowywaniu go z poprzedniego stanu za każdym razem, gdy coś się zmienia.

Konkretnym przykładem może być zmiana zdrowia potwora po zastrzeleniu. O wiele rozsądniej jest po prostu zmienić jego zdrowie niż zastąpić go całkowicie nowym potworem, który jest taki sam pod każdym względem, z wyjątkiem tego, że ma mniej zdrowia. Tego rodzaju zmiany składają się prawie na wszystko w świecie gry, a robienie tego w czysto funkcjonalny sposób nie jest bardzo intuicyjne. Wyobrażam sobie, że mogą występować poważne kary za wydajność, przynajmniej jeśli robisz to w czysto funkcjonalnym języku.

(Na marginesie, niektóre problemy w grach są bardzo dobrze dostosowane do programowania funkcjonalnego, takie jak AI. Hybrydowy język funkcjonalny / imperatywny byłby doskonale dopasowany do takich przypadków.)

Matt Olenik
źródło
9
Artykuł Kolejne języki programowania głównego nurtu: Perspektywa twórcy gry opowiada się za pl, szczególnie dla rozwoju gier, w którym zachowanie czysto funkcjonalne jest domyślne, a zmiany stanu są śledzone według typów, aby uniknąć błędów. Więc nie wszyscy uważają, że paradygmat funkcjonalny jest z natury nieodpowiedni do programowania gier.
sepp2k 16.10.10
1
@ sepp2k, dzięki za link. Cieszę się, że perspektywa argumentowana przez kogoś, kto stworzył prawdziwe gry.
Matt Olenik
3
@ sepp2k czekaj, czy coś przeoczyłem? Po dokładniejszym zapoznaniu się z prezentacją wydaje się, że Sweeney argumentował za tym, aby większość silnika podstawowego była napisana za pomocą czysto funkcjonalnego kodu, a większość logiki gry była napisana bezwzględnie (lub przynajmniej pozwalała na to) i używała STM, aby pomóc w współbieżności . Wydaje mi się to bardzo rozsądne.
Matt Olenik
@Matt: Nie, masz rację, mówi on, że część logiki gry będzie zawierała stan zmienny. Nie wyklucza to jednak, że język śledzi zmienność według typów (co proponuje w sekcji „rozważania”). Oczywiście „śledzenie stanu przez typy” nie jest równoznaczne z „funkcjonalnym”, więc mogłem sformułować mój poprzedni komentarz nieco zbyt optymistycznie.
sepp2k
@ sepp2k racja, rozumiem, co masz na myśli.
Matt Olenik
17

Wbudowane programowanie w czasie rzeczywistym dotyczy efektów ubocznych. Współdziałając z cyfrowymi i analogowymi urządzeniami io, timerami, portami szeregowymi i równoległymi, wszystko, co interesujące, odbywa się poprzez wywoływanie funkcji z efektami ubocznymi.

AShelly
źródło
3
Cóż, jeśli masz na myśli interfejs sprzętowy, wątpię w coś innego niż C / C ++, to dobry wybór. Jednak na tej warstwie czasami używa się takich języków, jak Erlang, szczególnie w systemach telekomunikacyjnych. Erlang to funkcjonalny język zaprojektowany dla krytycznych i odpornych na uszkodzenia wbudowanych systemów czasu rzeczywistego.
Jonas,
@Jonas: Erlang może zminimalizować mutację, ale przekazywanie wiadomości jest silnie uzależnione od IO, co jest oczywiście efektem ubocznym.
Jon Harrop,
11

Twierdziłbym, że programowanie GUI nie nadaje się do programowania funkcjonalnego. GUI są na ogół bardzo stanowe i o wiele łatwiej jest modelować je / zarządzać przy użyciu stanu, a nie przy użyciu efektów ubocznych. Z pewnością możliwe jest użycie funkcjonalnego języka programowania dla GUI ... ale prawdopodobnie nie jest to dobry pomysł.

Jak zauważono w innej odpowiedzi, grami często łatwiej zarządzać poprzez śledzenie stanu i chociaż można napisać grę w funkcjonalnym języku, często jest to łatwiejsze i wydajniejsze w języku „stanowym” (tj. Obiektowym język).

mipadi
źródło
-1: Mówisz o czystości i ignorujesz użycie pierwszorzędnych funkcji, np. Wywołania zwrotne w kodzie GUI są znacznie łatwiejsze w przypadku nieczystych języków FP niż w językach OOP.
Jon Harrop,
4
@Jon Harrop: Pierwszorzędne funkcje nie są unikalne dla funkcjonalnych języków programowania. Nadal twierdzę, że styl FP nie jest odpowiedni dla GUI.
mipadi
1
Zależy, kogo zapytasz. Dla większości funkcjonalnych programistów funkcje najwyższej klasy są samą definicją programowania funkcjonalnego.
Jon Harrop
@Jon Harrop: Większość programistów funkcjonalnych powiedziałoby, że programowanie funkcjonalne to metoda opisywania programów jako składu i oceny funkcji matematycznych. Funkcje pierwszej klasy są ważną częścią tego paradygmatu, ale same funkcje pierwszej klasy nie tworzą funkcjonalnego języka programowania (ani programu funkcjonalnego). Funkcjonalny paradygmat programowania dąży do zminimalizowania użycia struktur danych państwowych i zmiennych, a nawet nieczyste języki FP zachęcają do tego stylu. FP dotyczy zarówno stylu programowania, jak i indywidualnych funkcji, takich jak funkcje najwyższej klasy, i ...
mipadi
... Nie uważam, że ten paradygmat szczególnie nadaje się do programowania GUI - języki obiektowe lepiej pasują do GUI, ogólnie mówiąc.
mipadi
5

Aplikacje biznesowe oparte na danych. Interfejs użytkownika i proste operacje na danych nie wymagają FP.

Branimir
źródło
2
I każda inna aplikacja do przeglądania danych. Większość gier dotyczy stanu i jego zmiany, więc nie przekładają się dobrze na funkcjonalny styl.
Jon Purdy,
18
Naprawdę? Zawsze myślałem, że FP będzie do tego szczególnie dobre . Czy 99% tych aplikacji wybiera, agreguje i wyświetla dane? To w zasadzie filter, reducei map. Rzucać w niektórych sort, partition, groupBy. W końcu najczęściej używanym językiem programowania do pisania takich aplikacji jest Excel, który jest językiem funkcjonalnym.
Jörg W Mittag,
3
Aplikacje biznesowe oparte na danych i proste operacje danych brzmią jak bardzo dobre dla FP i słyszałem, że FP jest popularny do takich rzeczy. Np. Zobacz Adventures fa funkcjonalny programista na Wall Street
Jonas,
1
-1: Wymieniłeś niektóre aplikacje, w których FP się wyróżnia.
Jon Harrop,
2

Nie można łatwo odrzucić żadnego zestawu problemów, który sam nie nadaje się do programowania funkcjonalnego.

Wiele zależy od faktycznego języka używanego do programowania funkcjonalnego i jego funkcji.

Jednym z przykładów jest wspomniany już Erlang dla systemów wbudowanych w czasie rzeczywistym.

Pełnia stanu również nie jest dobrym kryterium w stosunku do programowania funkcjonalnego, istnieje kilka skutecznych sposobów zaimplementowania w funkcjonalnych językach programowania, aby sobie z tym poradzić.

Często wymienia się także skutki uboczne w stosunku do programowania funkcjonalnego. Każdy program, który nie jest całkowicie solipsystyczny, ma skutki uboczne. Tak więc każdy język FP w świecie rzeczywistym ma jakiś sposób, aby sobie z tym poradzić, to tylko kwestia tego, jak elegancko ująć w skutki uboczne świata.

Nie ma potrzeby stosowania dowolnych efektów ubocznych, takich jak zmienne globalne.

Istnieją jednak zestawy problemów, które ułatwiają dostęp do programowania funkcjonalnego, ponieważ nie zmieniają tak dobrze twojego sposobu patrzenia na problem. Ale kiedy uda ci się pomyśleć, że funkcjonalne, coraz więcej zestawów problemów jest otwartych na mniej skutków ubocznych.

Nawet podczas programowania C zawsze dobrym pomysłem jest ograniczenie w jak największym stopniu arbitralnych skutków ubocznych, takich jak zmienne globalne.

Peer Stritzinger
źródło
Stanowe aplikacje, takie jak aplikacje GUI, są w rzeczywistości trudne do zrobienia w funkcjonalny sposób, czy masz jakieś zalecenia?
Jonas
Jeśli masz jakieś abstrakcje procesów / wątków (np. Jak w Erlang), możesz przekazać swój stan w procesie.
Peer Stritzinger
3
Aplikacje GUI są zwykle budowane wokół pętli zdarzeń. Możesz całkiem dobrze napisać pętlę zdarzeń w funkcjonalnym języku. Jeśli jest to bardziej skomplikowane, prawdopodobnie dodasz wątki / procesy do przetwarzania w tle. Ale jeśli masz jakieś abstrakcje procesów / wątków (np. Jak w Erlang), możesz łatwo przekazać swój stan w procesie. Przydatne mogą być również kontynuacje. Myślę, że po prostu przyzwyczaja się do robienia rzeczy w funkcjonalny sposób, aby nawet opanować GUI. Jednym z powodów, dla których programowanie GUI jest dziś uważane za trudne, jest to, że większość zestawów narzędzi nie jest przeznaczona do użytku funkcjonalnego.
Peer Stritzinger
1
@Jonas: w Haskell użyłbyś monady IO, monady państwowej lub kombinacji.
Larry Coleman,
1
@Jonas: zależy to od twojej definicji przydatności. Przykład wikibook używa wxHaskell, podczas gdy Real World Haskell używa gtk2hs. Nie próbowałem też, ponieważ moja aplikacja Haskell jest oparta na wierszu poleceń.
Larry Coleman,