Ponieważ wszystkie te zalety są również wadami.
Programy bezpaństwowe; Brak efektów ubocznych
W rzeczywistych programach chodzi o efekty uboczne i mutacje. Gdy użytkownik naciska przycisk, dzieje się tak dlatego, że chce, aby coś się wydarzyło. Kiedy coś wpisują, chcą, aby ten stan zastąpił to, co kiedyś tam było. Kiedy Jane Smith w księgowości bierze ślub i zmienia nazwisko na Jane Jones, baza danych wspierająca proces biznesowy, który drukuje jej wypłatę, powinna lepiej polegać na obsłudze tego rodzaju mutacji. Kiedy strzelasz z karabinu maszynowego w kosmitę, większość ludzi nie modeluje go mentalnie jako budowy nowego kosmity z mniejszą liczbą punktów życia; modelują to jako mutację istniejących właściwości obcego.
Kiedy pojęcia języka programowania zasadniczo działają przeciwko modelowanej domenie, trudno uzasadnić użycie tego języka.
Konkurencja; Niezwykle dobrze gra z rosnącą technologią wielordzeniową
Problem został tylko rozwiązany. Dzięki niezmiennym strukturom danych masz tanie bezpieczeństwo wątków kosztem ewentualnej pracy z przestarzałymi danymi. Zmienne struktury danych mają tę zaletę, że zawsze pracują nad świeżymi danymi, kosztem pisania skomplikowanej logiki, aby zachować spójność danych. To nie tak, że jeden z nich jest oczywiście lepszy od drugiego.
Programy są zwykle krótsze, a w niektórych przypadkach łatwiejsze do odczytania
Z wyjątkiem przypadków, gdy są one dłuższe i trudniejsze do odczytania. Nauka czytania programów napisanych w funkcjonalnym stylu jest trudną umiejętnością; wydaje się, że ludzie są znacznie lepsi w postrzeganiu programów jako serii kroków do wykonania, takich jak przepis, niż jako seria obliczeń, które należy wykonać.
Wydajność rośnie (przykład: Erlang)
Wydajność musi znacznie wzrosnąć, aby uzasadnić ogromne koszty związane z zatrudnieniem programistów, którzy wiedzą, jak programować w funkcjonalny sposób.
I pamiętaj, że nie chcesz wyrzucać działającego systemu; większość programistów nie buduje nowych systemów od zera, a raczej utrzymuje istniejące systemy, z których większość została zbudowana w językach niefunkcjonalnych. Wyobraź sobie próbę uzasadnienia tego akcjonariuszom. Dlaczego zeskrobaliście istniejący działający system płac, aby zbudować nowy kosztem milionów dolarów? „Ponieważ programowanie funkcjonalne jest niesamowite” raczej nie zachwyci akcjonariuszy.
Programowanie imperatywne to bardzo stary paradygmat (o ile mi wiadomo) i być może nie nadaje się do XXI wieku
Programowanie funkcjonalne jest również bardzo stare. Nie rozumiem, jak ważny jest wiek tego pomysłu.
Nie zrozum mnie źle. Uwielbiam programowanie funkcjonalne, dołączyłem do tego zespołu, ponieważ chciałem pomóc wprowadzić koncepcje programowania funkcjonalnego do C # i myślę, że programowanie w niezmiennym stylu jest drogą przyszłości. Ale programowanie w funkcjonalnym stylu wiąże się z ogromnymi kosztami , których nie można po prostu odrzucić. Przejście w kierunku bardziej funkcjonalnego stylu nastąpi powoli i stopniowo w ciągu dziesięcioleci. I to właśnie będzie: przejście do bardziej funkcjonalnego stylu, a nie hurtowe obejmowanie czystości i piękna Haskell oraz rezygnacja z C ++.
Buduję kompilatory na życie i zdecydowanie popieramy funkcjonalny styl dla następnej generacji narzędzi kompilatora. Wynika to z faktu, że programowanie funkcjonalne jest zasadniczo dobrym rozwiązaniem dla problemów, z którymi mamy do czynienia. Nasze problemy dotyczą pobierania surowych informacji - ciągów i metadanych - i przekształcania ich w różne ciągi i metadane. W sytuacjach, w których występują mutacje, tak jak ktoś wpisuje IDE, przestrzeń problemowa z natury nadaje się do technik funkcjonalnych, takich jak stopniowa odbudowa tylko części drzewa, które uległy zmianie. Wiele domen nie ma tych miłych właściwości, które sprawiają, że są one oczywiście podatne na funkcjonalny styl .