Dlaczego języki funkcjonalne? [Zamknięte]

Widzę tu wiele dyskusji na temat funkcjonalnych języków i innych rzeczy. Dlaczego miałbyś używać jednego zamiast „tradycyjnego” języka? Co robią lepiej? W czym są gorsze? Jaka jest idealna funkcjonalna aplikacja do programowania?

Języki funkcjonalne używają innego paradygmatu niż języki imperatywne i obiektowe. Używają funkcji bez skutków ubocznych jako podstawowego elementu składowego w języku. Umożliwia to wiele rzeczy i utrudnia wiele rzeczy (lub w większości przypadków różni się od tego, do czego ludzie są przyzwyczajeni).

Jedną z największych zalet programowania funkcjonalnego jest to, że kolejność wykonywania funkcji wolnych od skutków ubocznych nie jest ważna. Na przykład w Erlang służy to do włączenia współbieżności w bardzo przejrzysty sposób. A ponieważ funkcje w językach funkcjonalnych zachowują się bardzo podobnie do funkcji matematycznych, łatwo jest je przetłumaczyć na języki funkcjonalne. W niektórych przypadkach może to zwiększyć czytelność kodu.

Tradycyjnie jedną z dużych wad programowania funkcjonalnego był również brak efektów ubocznych. Bardzo trudno jest napisać użyteczne oprogramowanie bez IO, ale IO jest trudne do wdrożenia bez efektów ubocznych w funkcjach. Dlatego większość ludzi nigdy nie czerpała więcej korzyści z programowania funkcjonalnego niż obliczanie pojedynczego wyjścia z pojedynczego wejścia. W nowoczesnych językach o mieszanym paradygmacie, takich jak F # lub Scala, jest to łatwiejsze.

Wiele współczesnych języków ma elementy z funkcjonalnych języków programowania. C # 3.0 ma wiele funkcjonalnych funkcji programowania i możesz również programować funkcjonalnie w Pythonie. Myślę, że powody popularności programowania funkcjonalnego wynikają głównie z dwóch powodów: Współbieżność staje się prawdziwym problemem w normalnym programowaniu, ponieważ dostajemy coraz więcej komputerów wieloprocesorowych; a języki stają się bardziej dostępne.

Nie sądzę, żeby było jakieś pytanie o funkcjonalne podejście do programowania „nadrabiania zaległości”, ponieważ jest używane (jako styl programowania) przez około 40 lat. Ilekroć programista OO pisze czysty kod, który faworyzuje niezmienne obiekty, kod ten zapożycza koncepcje funkcjonalne.

Jednak języki, które wymuszają funkcjonalny styl, otrzymują obecnie dużo wirtualnego atramentu i pytanie, czy te języki staną się dominujące w przyszłości, jest pytaniem otwartym. Podejrzewam, że hybrydowe, wieloparadowe języki, takie jak Scala lub OCaml , prawdopodobnie będą dominować nad „purystycznymi” językami funkcjonalnymi w taki sam sposób, w jaki czysty język OO (Smalltalk, Beta itp.) Wpłynął na programowanie głównego nurtu, ale się nie skończył jako najczęściej używane notacje.

Wreszcie, nie mogę się powstrzymać od wskazania, że ​​wasze komentarze dotyczące FP są wysoce zbieżne z uwagami, które usłyszałem od programistów proceduralnych nie tak wiele lat temu:

• „Przeciętny” programista (mityczny, IMHO) tego nie rozumie.
• Nie jest powszechnie nauczany.
• Każdy program, który możesz za jego pomocą napisać, może zostać napisany w inny sposób przy użyciu aktualnych technik.

Podobnie jak graficzne interfejsy użytkownika i „kod jako model biznesu” były koncepcjami, które pomogły OO w szerszym uznaniu, wierzę, że zwiększone wykorzystanie niezmienności i prostszej (masywnej) równoległości pomoże większej liczbie programistów dostrzec korzyści, jakie oferuje funkcjonalne podejście . Ale o ile nauczyliśmy się w ciągu ostatnich 50 lat, które składają się na całą historię cyfrowego programowania komputerowego, myślę, że wciąż musimy się wiele nauczyć. Za dwadzieścia lat programiści będą ze zdumieniem patrzeć na prymitywny charakter narzędzi, których obecnie używamy, w tym obecnie popularnych języków OO i FP.

Najważniejszym plusem jest dla mnie wrodzona równoległość, zwłaszcza, że ​​odchodzimy teraz od większej liczby MHz w kierunku coraz większej liczby rdzeni.

Nie sądzę, że stanie się to kolejnym paradygmatem programowania i całkowicie zastąpi metody typu OO, ale myślę, że dojdziemy do tego, że musimy albo napisać część naszego kodu w języku funkcjonalnym, albo nasze języki ogólnego przeznaczenia rosną, aby zawierać bardziej funkcjonalne konstrukty.

Nawet jeśli nigdy nie pracujesz profesjonalnie w języku funkcjonalnym, zrozumienie programowania funkcjonalnego sprawi, że będziesz lepszym programistą. To da ci nowe spojrzenie na twój kod i ogólnie programowanie.

Mówię, że nie ma powodu, aby się tego nie uczyć.

Myślę, że języki, które dobrze sobie radzą z mieszaniem stylu funkcjonalnego i imperatywnego, są najbardziej interesujące i mają największe szanse powodzenia.

Zawsze jestem sceptycznie nastawiony do Next Big Thing. Wiele razy Next Big Thing jest czystym przypadkiem historii, będąc tam we właściwym miejscu we właściwym czasie, bez względu na to, czy technologia jest dobra, czy nie. Przykłady: C ++, Tcl / Tk, Perl. Wszystkie wadliwe technologie, wszystkie szalenie udane, ponieważ były postrzegane albo jako rozwiązanie problemów dnia, albo prawie identyczne z zakorzenionymi standardami, albo z obydwoma. Programowanie funkcjonalne może być naprawdę świetne, ale to nie znaczy, że zostanie przyjęte.

Ale można powiedzieć, dlaczego ludzie są podekscytowani na temat programowania funkcjonalne: wiele, wiele programiści mieli swego rodzaju „nawrócenie”, w którym okazuje się, że za pomocą języka funkcjonalnego czyni je dwukrotnie wytwórczych (a może dziesięć razy produktywne) podczas produkcji kod, który jest bardziej odporny na zmiany i ma mniej błędów. Ci ludzie myślą o programowaniu funkcjonalnym jako tajnej broni; dobrym przykładem tego sposobu myślenia jest Beating the Averages Paula Grahama . Aha, a jego aplikacja? Aplikacje internetowe e-commerce.

Od początku 2006 r. Pojawiło się również sporo szumu na temat programowania funkcjonalnego i równoległości. Ponieważ ludzie tacy jak Simon Peyton Jones martwią się paralelizmem od co najmniej 1984 roku, nie wstrzymuję oddechu, dopóki funkcjonalne języki nie rozwiążą problemu wielordzeniowego. Ale to wyjaśnia niektóre dodatkowe szumy w tej chwili.

Ogólnie rzecz biorąc, amerykańskie uniwersytety źle radzą sobie z nauczaniem programowania funkcjonalnego. Istnieje silny rdzeń wsparcia w nauczaniu programowania wstępnego za pomocą Scheme , a Haskell również cieszy się tam wsparciem, ale jest bardzo niewiele w nauczaniu zaawansowanej techniki dla funkcjonalnego programisty. Uczyłem taki kurs na Harvardzie i zrobię to jeszcze tej wiosny w Tufts. Benjamin Pierce prowadził taki kurs w Penn. Nie wiem, czy Paul Hudak zrobił cokolwiek w Yale. Europejskie uniwersytety wykonują znacznie lepszą pracę; na przykład programowanie funkcjonalne jest podkreślane w ważnych miejscach w Danii, Holandii, Szwecji i Wielkiej Brytanii. Nie mam pojęcia, co dzieje się w Australii.

Nie widzę tutaj nikogo wspominającego o słoniu w pokoju, więc myślę, że to zależy ode mnie :)

JavaScript jest językiem funkcjonalnym. W miarę jak coraz więcej osób robi bardziej zaawansowane rzeczy z JS, zwłaszcza wykorzystując lepsze punkty jQuery, Dojo i innych frameworków, FP zostanie wprowadzone przez tylne drzwi programisty.

W połączeniu z zamknięciami FP sprawia, że ​​kod JS jest naprawdę lekki, ale nadal czytelny.

Pozdrawiam, PS

Większość aplikacji jest na tyle prosta, że ​​można je rozwiązać w zwykły sposób

1. Sposoby OO nie zawsze były „normalne”. Standardem tej dekady był marginalizowany koncept ostatniej dekady.

2. Programowanie funkcjonalne to matematyka. Paul Graham o Lisp (zastępstwo programowania funkcjonalnego dla Lisp):

Krótkie wyjaśnienie, dlaczego ten język lat 50. nie jest przestarzały, brzmi: nie była to technologia, tylko matematyka, a matematyka się nie starzeje. Właściwą rzeczą do porównania Lisp nie jest sprzęt z lat 50., ale powiedzmy algorytm Quicksort, który został odkryty w 1960 r. I nadal jest najszybszym rodzajem ogólnego zastosowania.

Założę się, że nie wiedziałeś, że programujesz funkcjonalnie, kiedy używałeś:

• Formuły Excel
• Kompozytor kwarcowy
• JavaScript
• Logo (grafika Turtle)
• LINQ
• SQL
• Underscore.js (lub Lodash), D3

Przeciętny programista korporacyjny, np. Większość ludzi, z którymi pracuję, nie zrozumie go, a większość środowisk pracy nie pozwoli ci się w nim programować

To tylko kwestia czasu. Twój przeciętny programista korporacyjny uczy się, czymkolwiek jest obecnie Wielka Rzecz. 15 lat temu nie rozumieli OOP. JEŚLI FP łapie na twoje „średnie programistów korporacyjnych” pójdą.

Tak naprawdę nie jest nauczany na uniwersytetach (czy jest obecnie?)

Bardzo się różni. Na mojej uczelni SML jest pierwszym językiem, w którym studenci poznają język. Wierzę, że MIT uczy LISP jako kursu pierwszego roku. Te dwa przykłady mogą oczywiście nie być reprezentatywne, ale uważam, że większość uniwersytetów przynajmniej oferuje niektóre opcjonalne kursy na temat PR, nawet jeśli nie stanowią one obowiązkowej części programu nauczania.

Większość aplikacji jest na tyle prosta, że ​​można je rozwiązać w zwykły sposób

Jednak tak naprawdę nie jest to kwestia „dość prosta”. Czy rozwiązanie byłoby prostsze (lub bardziej czytelne, solidne, eleganckie, wydajne) w FP? Wiele rzeczy jest „wystarczająco prostych, aby rozwiązać je w Javie”, ale wciąż wymaga ogromnej ilości kodu.

W każdym razie pamiętajcie, że zwolennicy FP twierdzili, że od następnych dziesięcioleci jest to kolejna wielka rzecz. Być może mają rację, ale pamiętajcie, że nie mieli racji, gdy zgłosili to samo 5, 10 lub 15 lat temu.

Jedną rzeczą, która zdecydowanie liczy na ich korzyść, jest to, że ostatnio C # zrobił ostry zwrot w kierunku FP, do tego stopnia, że ​​praktycznie zmienia pokolenie programistów w programistów FP, nawet ich nie zauważając . To może po prostu utorować drogę dla „rewolucji” FP. Może. ;)

Człowiek nie może zrozumieć doskonałości i niedoskonałości swojej wybranej sztuki, jeśli nie widzi wartości w innych sztukach. Przestrzeganie zasad pozwala na rozwój tylko do pewnego stopnia techniki, a następnie uczeń i artysta muszą dowiedzieć się więcej i szukać dalej. Sensowne jest studiowanie innych sztuk, a także strategii.

Kto nie nauczył się czegoś więcej o sobie, obserwując działania innych? Aby nauczyć się miecza, przestudiuj gitarę. Aby nauczyć się pierwszej nauki handlu. Już samo studiowanie miecza spowoduje, że będziesz miał wąskie umysły i nie pozwoli ci rosnąć na zewnątrz.

- Miyamoto Musashi, „Księga pięciu pierścieni”

Jedną z kluczowych cech funkcjonalnego języka jest koncepcja pierwszorzędnych funkcji. Chodzi o to, że możesz przekazać funkcje jako parametry do innych funkcji i zwrócić je jako wartości.

Programowanie funkcjonalne polega na pisaniu kodu, który nie zmienia stanu. Głównym tego powodem jest to, że kolejne wywołania funkcji dadzą ten sam wynik. Możesz pisać kod funkcjonalny w dowolnym języku, który obsługuje funkcje najwyższej klasy, ale istnieją pewne języki, takie jak Haskell, które nie pozwalają na zmianę stanu. W rzeczywistości nie powinieneś wywoływać żadnych efektów ubocznych (takich jak drukowanie tekstu) - co brzmi, jakby mogło być całkowicie bezużyteczne.

Zamiast tego Haskell stosuje inne podejście do IO: monady. Są to obiekty, które zawierają żądaną operację We / Wy, która ma zostać wykonana przez najwyższy poziom interpretera. Na każdym innym poziomie są po prostu obiektami w systemie.

Jakie zalety zapewnia programowanie funkcjonalne? Programowanie funkcjonalne umożliwia kodowanie z mniejszym potencjałem błędów, ponieważ każdy element jest całkowicie izolowany. Ponadto użycie funkcji rekurencyjnych i pierwszorzędnych pozwala na proste dowody poprawności, które zwykle odzwierciedlają strukturę kodu.

Nie sądzę, aby najbardziej realistyczni ludzie sądzili, że programowanie funkcjonalne się przyda (staje się głównym paradygmatem takim jak OO). W końcu większość problemów biznesowych nie jest dość problemami matematycznymi, ale owłosionymi imperatywnymi zasadami przenoszenia danych i wyświetlania ich na różne sposoby, co oznacza, że ​​nie jest to dobre dopasowanie do czysto funkcjonalnego paradygmatu programowania (krzywa uczenia się monady znacznie przekracza OO).

OTOH, programowanie funkcjonalne sprawia, że ​​programowanie jest przyjemnością. Sprawia, że ​​doceniasz nieodłączne, ponadczasowe piękno zwięzłych wyrażeń leżących u podstaw matematyki wszechświata. Ludzie mówią, że nauka programowania funkcjonalnego sprawi, że będziesz lepszym programistą. Jest to oczywiście bardzo subiektywne. Osobiście też nie uważam, że to całkowicie prawda.

To sprawia, że ​​czujesz się lepiej.

Muszę być gęsty, ale wciąż tego nie rozumiem. Czy są jakieś przykłady małych aplikacji napisanych w funkcjonalnym języku, takim jak F #, w którym możesz spojrzeć na kod źródłowy i zobaczyć, jak i dlaczego lepiej było zastosować takie podejście niż, powiedzmy, C #?

Zwracam uwagę, że wszystko, co mówiłeś o językach funkcjonalnych, większość ludzi mówiła o obiektowych langaugach około 20 lat temu. Wtedy bardzo często słyszano o OO:

* The average corporate programmer, e.g. most of the people I work with, will not understand it and most work environments will not let you program in it
* It's not really taught at universities (or is it nowadays?)
* Most applications are simple enough to be solved in normal IMPERATIVE ways

Zmiana musi skądś pochodzić. Znacząca i ważna zmiana nastąpi samodzielnie, niezależnie od tego, czy osoby przeszkolone we wcześniejszych technologiach uznają, że zmiana nie jest konieczna. Czy uważasz, że zmiana na OO była dobra pomimo wszystkich ludzi, którzy byli przeciwko temu w tym czasie?

F # może się uchwycić, ponieważ Microsoft go naciska.

Zawodowiec:

• F # będzie częścią kolejnej wersji programu Visual Studio
• Microsoft już od jakiegoś czasu buduje społeczność - ewangelistów, książki, konsultantów współpracujących z głośnymi klientami, znaczącą ekspozycję na konferencjach MS.
• F # to język pierwszej klasy .Net i jest to pierwszy język funkcjonalny, który ma naprawdę duże podstawy (nie to, że mówię, że Lisp, Haskell, Erlang, Scala, OCaml nie mają wielu bibliotek, po prostu nie są tak kompletne jak .Net jest)
• Silne poparcie dla równoległości

Contra:

• F # jest bardzo trudny do uruchomienia, nawet jeśli jesteś dobry w C # i .Net - przynajmniej dla mnie :(
• prawdopodobnie trudno będzie znaleźć dobrych programistów F #

Daję F # 50:50 szansę, aby stać się ważnym. Inne języki funkcjonalne nie będą dostępne w najbliższej przyszłości.

Myślę, że jednym z powodów jest to, że niektórzy uważają, że najważniejszą częścią akceptacji języka jest to, jak dobry jest ten język . Niestety, rzeczy rzadko są tak proste. Na przykład argumentowałbym, że największym czynnikiem akceptacji Pythona nie jest sam język (chociaż jest to dość ważne). Największym powodem, dla którego Python jest tak popularny, jest ogromna standardowa biblioteka i jeszcze większa społeczność bibliotek stron trzecich.

Języki takie jak Clojure lub F # mogą być wyjątkiem od tej reguły, biorąc pod uwagę, że są one oparte na JVM / CLR. W rezultacie nie mam na nie odpowiedzi.

Większość aplikacji można rozwiązać w [wstaw swój ulubiony język, paradygmat itp. Tutaj].

Chociaż jest to prawda, do rozwiązania różnych problemów można użyć różnych narzędzi. Funkcjonalna pozwala tylko na kolejną abstrakcję na wysokim (wyższym poziomie), która pozwala na bardziej efektywne wykonywanie naszych zadań, jeśli jest właściwie używana.

Wydaje mi się, że ludzie, którzy nigdy nie uczyli się Lisp lub Scheme jako licencjat, teraz to odkrywają. Podobnie jak w przypadku wielu rzeczy w tej dziedzinie, istnieje tendencja do szumu i tworzenia wysokich oczekiwań ...

To przejdzie.

Programowanie funkcjonalne jest świetne. Jednak nie przejmie świata. C, C ++, Java, C # itp. Nadal będą dostępne.

Myślę, że z tego wyniknie większa umiejętność posługiwania się wieloma językami - na przykład wdrażanie rzeczy w funkcjonalnym języku, a następnie zapewnianie dostępu do tych rzeczy w innych językach.

Podczas czytania „The Next Mainstream Programming Language: A Game Developers Perspective” autorstwa Tim Sweeney, Epic Games, moją pierwszą myślą było - musiałem nauczyć się Haskell.

PPT

Wersja HTML Google

Od pewnego czasu wszystko kręci się w funkcjonalnym kierunku. Dwie fajne nowe dzieci z ostatnich kilku lat, Ruby i Python, są radykalnie bliżej języków funkcjonalnych niż to, co pojawiło się przed nimi - do tego stopnia, że ​​niektórzy Lisperowie zaczęli wspierać jedno lub drugie jako „wystarczająco blisko”.

A przy masowo równoległym sprzęcie wywierającym presję ewolucyjną na wszystkich - i językach funkcjonalnych w najlepszym miejscu do radzenia sobie ze zmianami - nie jest to tak duży skok, jak kiedyś sądzić, że Haskell lub F # będą kolejną wielką rzeczą.

Czy śledziłeś ostatnio ewolucję języków programowania? Każda nowa wersja wszystkich głównych języków programowania wydaje się zapożyczać coraz więcej funkcji programowania funkcjonalnego.

• Zamknięcia, funkcje anonimowe, funkcje przekazywania i zwracania jako wartości były kiedyś egzotycznymi funkcjami znanymi tylko hakerom Lisp i ML. Ale stopniowo C #, Delphi, Python, Perl, JavaScript, dodały obsługę zamknięć. Niemożliwe jest, aby jakikolwiek nadchodzący język był traktowany poważnie bez zamknięć.

• Kilka języków, w szczególności Python, C # i Ruby, ma natywną obsługę interpretacji list i generatorów list.

• ML był pionierem programowania generycznego w 1973 r., Ale wsparcie dla generyków („polimorfizm parametryczny”) stało się standardem branżowym w ciągu ostatnich 5 lat. O ile dobrze pamiętam, Fortran wspierał generics w 2003 r., Następnie Java 2004, C # w 2005 r., Delphi w 2008 r. (Wiem, że C ++ obsługuje szablony od 1979 r., Ale 90% dyskusji na temat STL C ++ zaczyna się od „tutaj są demony” .)

Co sprawia, że ​​te funkcje są atrakcyjne dla programistów? Powinno to być oczywiste: pomaga programistom pisać krótszy kod . Wszystkie języki w przyszłości będą wspierać - przynajmniej - zamknięcia, jeśli chcą pozostać konkurencyjne. Pod tym względem programowanie funkcjonalne jest już w głównym nurcie.

Większość aplikacji jest na tyle prosta, że ​​można je rozwiązać w zwykły sposób

Kto powiedział, że nie może używać programowania funkcjonalnego również do prostych rzeczy? Nie każdy program funkcjonalny musi być kompilatorem, argumentem twierdzącym lub masowo równoległym przełącznikiem telekomunikacyjnym. Regularnie używam F # do skryptów typu ad hoc, oprócz moich bardziej skomplikowanych projektów.

Jest to przydatne narzędzie, ponieważ jest najlepszym narzędziem do kontrolowania złożoności. Zobacz:
- slajdy 109-116 z Simon Peyton-Jones mówią „A Taste of Haskell”
- „The Next Mainstream Programming Language: A Game Developers Perspective” Tim Sweeney

Kwestia Dlaczego programowanie funkcjonalne ma znaczenie

Zgadzam się z pierwszym punktem, ale czasy się zmieniają. Korporacje odpowiedzą, nawet jeśli spóźnią się z przysposobieniem, jeśli zauważą, że można uzyskać przewagę. Życie jest dynamiczne.

Uczyli Haskell i ML w Stanford pod koniec lat 90. Jestem pewien, że miejsca takie jak Carnegie Mellon, MIT, Stanford i inne dobre szkoły prezentują to uczniom.

Zgadzam się, że większość aplikacji „udostępniających relacyjne bazy danych w Internecie” będzie działać w tym duchu przez długi czas. Java EE, .NET, RoR i PHP opracowały całkiem dobre rozwiązania tego problemu.

Znalazłeś coś ważnego: może to być problem, którego nie da się łatwo rozwiązać innymi środkami, które poprawią funkcjonalne programowanie. Co by to było?

Czy potężny wielordzeniowy sprzęt i przetwarzanie w chmurze będą je wspierać?

Ponieważ FP ma znaczące zalety pod względem wydajności, niezawodności i łatwości konserwacji. Wielordzeniowy może być zabójczą aplikacją, która w końcu dostaje duże korporacje, mimo dużej ilości starszego kodu, a nawet duże komercyjne języki, takie jak C #, nabierają wyraźnego funkcjonalnego smaku z powodu wielu podstawowych obaw - skutki uboczne po prostu nie pasują do współbieżności i równoległości.

Nie zgadzam się, że „normalni” programiści tego nie zrozumieją. Będą, tak jak w końcu zrozumieli OOP (co jest równie tajemnicze i dziwne, jeśli nie bardziej).

Ponadto większość uniwersytetów uczy FP, wiele wręcz uczy go jako pierwszego kursu programowania.

Wow - to ciekawa dyskusja. Moje własne przemyślenia na ten temat:

FP sprawia, że ​​niektóre zadania są stosunkowo proste (w porównaniu do języków bez FP). Języki bez FP już zaczynają czerpać pomysły z FP, więc podejrzewam, że ten trend będzie się utrzymywał i zobaczymy więcej połączenia, które powinno pomóc ludziom ułatwić przejście do FP.

Nie wiem, czy to się przyda, czy nie, ale z moich badań wynika, że ​​funkcjonalny język jest prawie na pewno wart nauki i uczyni cię lepszym programistą. Samo zrozumienie referencyjnej przejrzystości znacznie ułatwia podejmowanie decyzji projektowych, a wynikające z nich programy są znacznie łatwiejsze do uzasadnienia. Zasadniczo, jeśli napotkasz problem, to raczej jest to problem z wyjściem pojedynczej funkcji, a nie problemem z niespójnym stanem, który mógł być spowodowany przez dowolną z setek klas / metod / funkcji w imparatywnym języku z efektami ubocznymi.

Bezpaństwowy charakter map FP bardziej naturalnie na bezpaństwowy charakter sieci, a zatem języki funkcjonalne łatwiej dostosowują się do bardziej eleganckich, RESTFULOWANYCH aplikacji internetowych. Porównaj ze strukturami JAVA i .NET, które muszą uciekać się do strasznie brzydkich HACKÓW, takich jak VIEWSTATE i SESSION, aby utrzymać stan aplikacji, i utrzymać (czasami dość nieszczelną) abstrakcję stanowego imperatywnego języka na zasadniczo bezstanowej funkcjonalnej platformie, takiej jak sieć.

Ponadto, im bardziej bezstanowa jest Twoja aplikacja, tym łatwiej można jej poddać się przetwarzaniu równoległemu. Ogromnie ważne dla sieci, jeśli Twoja witryna zyskuje popularność. Nie zawsze proste jest dodanie dodatkowego sprzętu do witryny, aby uzyskać lepszą wydajność.

Uważam, że przyniesie to teraz, gdy Microsoft pchnie go znacznie dalej do głównego nurtu. Dla mnie jest atrakcyjny ze względu na to, co może dla nas zrobić, ponieważ jest to nowe wyzwanie i ze względu na możliwości pracy, których żałuje w przyszłości.

Po opanowaniu będzie to kolejne narzędzie, które pomoże nam zwiększyć produktywność jako programistów.

Punktem omawianym w dyskusji jest to, że najlepsze systemy typów znajdują się we współczesnych językach FP. Co więcej, kompilatory mogą automatycznie wnioskować o wszystkich (lub przynajmniej większości) typach.

Interesujące jest to, że spędzając połowę czasu na pisaniu nazw typów podczas programowania Java, Java nie jest zdecydowanie bezpieczna dla typów. Chociaż nigdy nie możesz pisać typów w programie Haskell (z wyjątkiem dokumentacji sprawdzanej przez kompilator), a kod jest w 100% bezpieczny.

Oprócz innych odpowiedzi, sformułowanie rozwiązania w kategoriach czysto funkcjonalnych zmusza do lepszego zrozumienia problemu. I odwrotnie, myślenie w funkcjonalnym stylu rozwinie lepsze * umiejętności rozwiązywania problemów.

* Albo dlatego, że paradygmat funkcjonalny jest lepszy, albo dlatego, że zapewni dodatkowy kąt ataku.