Czy programowania funkcjonalnego można użyć do opracowania pełnej aplikacji dla przedsiębiorstw?

Właśnie zaczynam się uczyć programowania funkcjonalnego (FP). Pochodzę ze świata OOP, w którym wszystko jest przedmiotem, a większość z nich jest zmienna. Trudno mi się skupić na tym, że funkcje nie mają skutków ubocznych.

Jeśli coś nie jest modyfikowalne, w jaki sposób typowe obiekty, takie jak Pracownik lub Osoba reprezentowane w FP.

Czy FP można wykorzystać do stworzenia pełnoprawnej aplikacji dla przedsiębiorstw?

Pytanie nie brzmi Czy można używać FP w Enterprise? ale czy powinniśmy używać FP w Enteprise?

Oczywiście, że możesz. Możesz opracować dowolną aplikację z dowolnym językiem programowania, dlatego nazywają się „Turing complete”.

Teraz na pytanie „Czy powinno się go używać w Enterprise?” To zależy od ciebie lub twoich pracodawców, FP może być bardzo przydatny w niektórych aplikacjach, a właściwie jest dość często używany: Haskell w branży

Teraz możesz zapytać: „Dlaczego więc nie używa się więcej?” głównie dlatego, że inne języki Imperative / OO są bardziej powszechne, a firmy odmawiają przejścia na bardziej „egzotyczny” język, ponieważ są przyzwyczajeni do Java lub C ++.

Kilka lat temu zacząłem uczyć się języków FP. .

IMO, niektóre mocne strony języków FP to:

• Zwykle są bardzo zwięzłe, ale zachowują wyraźną semantykę.
• Możesz użyć stylu deklaratywnego i nie musisz zbyt dużo myśleć o szczegółach implementacji.
• System typu bogatego, taki jak Haskell, może bardzo wcześnie wykryć wiele błędów logicznych (w czasie kompilacji). O ile mi wiadomo (właściwie nie bardzo), SML i Ocaml oferują podobne zalety.

Do tej pory uważałem, że przejście na paradygmat FP jest dość ekscytujące i niezbyt trudne, jeśli poświęcisz mu wystarczająco dużo czasu. (Ale ile czasu spędziłem na nauce języka C lub C ++? Całkiem sporo!)

Myślę więc, że z technicznego punktu widzenia sensowne jest stworzenie pełnej aplikacji dla przedsiębiorstw przy użyciu funkcjonalnego języka programowania.

Niestety ten paradygmat nie jest głównym nurtem: większość firm ma tendencję do przyjmowania tylko sprawdzonych technologii, więc będą trzymać się z dala od FP, dopóki nie będą miały wystarczających dowodów na to, że faktycznie działa, że ​​jest wystarczająca liczba programistów, narzędzi, bibliotek, frameworków. Dlatego jest (o wiele) trudniej znaleźć pracę, w której można teraz programować FP na pełny etat.

Być może obecna sytuacja ulegnie zmianie, jeśli rosnące wykorzystanie procesorów wielordzeniowych zachęci do większych inwestycji w języki FP, które wydają się dość mocne do pisania współbieżnego oprogramowania.

Ponadto, istnieje tendencja do wprowadzania niektórych funkcji FP do głównych, niefunkcjonalnych języków, takich jak C #, C ++, aby programiści mogli używać niektórych FP bez konieczności całkowitego przełączania paradygmatu. Być może za dziesięć lat języki te będą zawierać wystarczającą liczbę funkcji FP, aby przejście na język czysto funkcjonalny będzie o wiele łatwiejsze.

Nie sądzę, że to koniecznie najlepszy pomysł. Ale zależy to od charakteru konkretnej aplikacji.

Bardzo wierzę w filozofię Erica Evansa opisaną w jego książce „ Domain-Driven Design” , że powinieneś stworzyć model domeny, który jest reprezentacją problemu, który może pomóc w jego rozwiązaniu. Evans sugeruje znalezienie języka programowania, który będzie pasował do konkretnego problemu, np. Wymienia Fortran jako sposób rozwiązywania problemów natury matematycznej. Lub nawet tworzenie specjalistycznych języków specyficznych dla domeny dla danego problemu.

Gdy uda ci się stworzyć dobry model domeny, przekonasz się, że kod prezentacji jest cienką powłoką na warstwie domeny.

Problem z aplikacją korporacyjną polega na tym, że ten typ aplikacji (jeśli można uogólnić na temat aplikacji korporacyjnych) często obejmuje modyfikowanie stanu podmiotów, których tożsamość jest ważna, oraz utrwalanie zmodyfikowanych podmiotów w bazie danych. Ten bardzo ogólny rodzaj problemu jest o wiele lepiej rozwiązany przez IMHO przy użyciu modelu obiektowego niż modelu funkcjonalnego.

Nie oznacza to, że istnieją obszary aplikacji korporacyjnej, których nie można lepiej rozwiązać za pomocą paradygmatu funkcjonalnego. Na przykład moduł analizy ryzyka aplikacji bankowej lub moduł planowania trasy w aplikacji wysyłkowej. Być może niektóre aplikacje korporacyjne mogłyby zostać w pełni zaimplementowane przy użyciu funkcjonalnego paradygmatu.

Ogólnie jednak myślę, że obiektowy paradygmat pozwala na tworzenie bardziej przydatnych modeli domen dla większości aplikacji korporacyjnych.

Edytować

Ze względu na pewne głosy poparcia zwróciłem uwagę na tę odpowiedź - a ponieważ ją napisałem, nauczyłem się znacznie więcej o FP - i nie jestem całkowicie pewien, czy zgadzam się z moją własną odpowiedzią. Niektóre języki funkcjonalne bardzo ładnie opisują przypadki użycia. Ale musisz nauczyć się zupełnie innego sposobu myślenia.

Tak, może. Google trochę, a znajdziesz prawdziwe oprogramowanie zakodowane w czysto funkcjonalnych językach.

Jeśli chodzi o twoje pytanie dotyczące obiektów biznesowych, myślę, że twoim prawdziwym problemem jest niezmienność. W takim przypadku zastanów się, że zwracasz nową „Osobę” za każdym razem, gdy ją mutujesz, jeśli używasz języka rozkazującego.

Pamiętaj, że tę technikę można również wdrożyć za pomocą imperatywnych języków!

Programowanie funkcji (FP), podobnie jak programowanie obiektowe (OOP), to paradygmaty. Reprezentują różne wzorce lub podejścia do problemów programistycznych. Te różne podejścia nie wykluczają możliwości tworzenia skalowalnego, łatwego w utrzymaniu i rozszerzalnego oprogramowania. Nie oznacza to, że podejścia są równoważne dla wszystkich rodzajów problemów; nie są. Pewne problemy dopasowują się lepiej (lub gorzej) do konkretnych paradygmatów, na przykład FP nie byłby moim pierwszym wyborem dla programu, który ma zależną sekwencję operacji z efektami ubocznymi. Jednak takie programy mogą i zostały napisane i napisane dobrze.

Tak, FP można stosować w aplikacjach korporacyjnych. Clojure jest jednym z przykładów języka FP z sukcesem w przedsiębiorstwie: http://cognitect.com/clojure#successstories

Reprezentowanie stanu może być wyzwaniem w FP, a zmiana paradygmatów w celu dopasowania FP może być trochę zniekształceniem umysłu. Niektóre języki FP całkowicie wykluczają działania niepożądane i stan mutacji. Clojure pozwala na oba, ale zniechęca lub izoluje te paradygmaty.

Krótko mówiąc, reprezentacja stanu może być bardzo podobna do OO. To modyfikacja stanu jest zupełnie inna. Na przykład w stanie FP mogą być reprezentowane przez listy i mapy. Lista pracowników może wyglądać następująco:

[[name: "James Brown" address: "Barnwell, SC"]
 [name: "Elvis Presley" address: "Tupelo, MS"]]

Znam dwa sposoby radzenia sobie ze zmianą stanu w FP. Jednym z nich jest funkcjonalne programowanie reaktywne. W tym paradygmacie wszystkie stany są obsługiwane tylko na najwyższym poziomie ... na przykład widok HTML aplikacji ma stan w widoku (np. Imię i nazwisko osoby, adres itp.). Teraz, kiedy klikniesz „aktualizuj nazwę”, wywoływana jest funkcja, która obsługuje wszystkie czynności związane z aktualizacją nazwy oprócz faktycznej zmiany nazwy. To może zabrzmieć dziwnie ... ale trzymaj się mnie. Zmieniona nazwa zostanie następnie zwrócona przez funkcję, a widok (lub trwały magazyn danych itp.) Pokaże nową nazwę. Lub alternatywnie zostanie zwrócona cała nowa struktura ze zaktualizowaną nazwą. Czym więc jest ta funkcja? Sprawdza poprawność nazwy i zwraca nową nazwę, jeśli jest poprawna, błąd, jeśli nie jest, i ewentualnie nowy link do widoku lub nawigacji. W przypadku czegoś bardziej złożonego niż zmiana nazwy może to zrobić znacznie więcej.

Tak więc dla FRP obiekt zwrócony przez funkcję jest nowym stanem i może być przekazany bezpośrednio do widoku lub cokolwiek na wysokim poziomie. W niektórych przypadkach FRP przejmuje cały stan, przekazuje go do funkcji i odzyskuje cały stan.

W tym paradygmacie kontener lub środowisko musi obsługiwać aktualizację wyświetlacza, bazy danych lub cokolwiek innego wymagającego aktualizacji z nowego stanu. Możesz więc wyobrazić sobie strukturę, która rysuje aplikację na ekranie. Gdy użytkownik kliknie, wywoływane są funkcje i zwracany jest nowy stan. Struktura następnie aktualizuje ekran, przerysowując wszystko lub inteligentnie przerysowując części wyświetlacza. Zobacz http://blog.getprismatic.com/om-sweet-om-high-functional-frontend-engineering-with-clojurescript-and-react/

Clojure wykorzystuje drugi paradygmat, z którym się zetknąłem, a mianowicie izolowanie zmian stanu, ale niekoniecznie ograniczanie ich do najwyższego poziomu. W Clojure wszystkie zmienne stany muszą być „wstrzymane” (chyba że używasz obiektów Java dla stanu) przez atom, agenta lub referencję. Sposób, w jaki to działa, to obiekt trzymany, wskazywany lub do którego odwołuje się (jakkolwiek chcesz to nazwać) atom / agent / ref jest niezmienny, ale atom / agent / ref może zmienić się, wskazując nowy obiekt. W tym przypadku używasz specjalnych metod dla atomu / agenta / ref, które mówią „zaktualizuj obiekt tutaj, wykonując takie a takie i ponownie przypisując atom / agent / ref do nowego obiektu”.

Dlaczego warto zadać pytanie? Ponieważ niezmienny obiekt, do którego odwołują się te konstrukcje Clojure, może zostać przekazany do funkcji, która coś robi, a podczas działania tej funkcji jego odwołanie do obiektu jest gwarantowane, że się nie zmieni. Oznacza to, że atom / agent / ref nie jest przekazywany do funkcji, ale przekazywany przez nich niezmienny obiekt. Atomy, agenci i referencje mają specjalne właściwości, które obsługują aktualizacje i współbieżność w bezpieczny sposób i stanowią część języka. Zobacz http://clojure.org/state

Mam nadzieję, że to pomoże. Proponuję przeczytać więcej o stanie Clojure i FRP, aby lepiej zrozumieć, w jaki sposób pracownicy i osoby mogą być reprezentowane w FP. Chociaż rzeczywista reprezentacja byłaby podobna do programowania obiektowego ... to zmienność jest naprawdę inna.