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

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?

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.)

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.

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).

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

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.