Dlaczego obecny entuzjazm dla programowania funkcjonalnego? [Zamknięte]

Ostatnio słyszałem wiele entuzjazmu na temat funkcjonalnych języków programowania, w odniesieniu do Scali, Clojure i F #. Niedawno zacząłem studiować Haskell, aby nauczyć się paradygmatu FP.

Uwielbiam to, jest naprawdę fajne i pasuje do mojego tła matematycznego.

Ale czy to naprawdę będzie miało znaczenie? Oczywiście nie jest to nowy pomysł.

Oto moje pytania:

1. Co przyczyniło się do ostatniego entuzjazmu FP? Czy jest to tylko nuda z OO, czy też coś się zmieniło, aby FP była bardziej potrzebna niż wcześniej?
2. Czy to wskazuje na przyszłość PR? A może to moda, jak bazy danych zorientowane obiektowo?

Innymi słowy, czy ktoś może mi pomóc zrozumieć, skąd to się bierze i dokąd zmierza?

Jedną z głównych innowacji w FP, która spowodowała „eksplozję” zainteresowania, są monady.

W styczniu 1992 roku Philip Wadler napisał artykuł zatytułowany The Essence of Functional Programming, który wprowadził monady do programowania funkcjonalnego jako sposób radzenia sobie z IO.

Głównym problemem w czystych, leniwych, funkcjonalnych językach programowania była użyteczność w radzeniu sobie z IO. Jest jednym z członków „Niezręcznej drużyny” w programowaniu, ponieważ „lenistwo i skutki uboczne są z praktycznego punktu widzenia niezgodne. Jeśli chcesz używać leniwego języka, musi to być język czysto funkcjonalny; jeśli chcesz użyć efektów ubocznych, lepiej użyj surowego języka. ” Odniesienie

Problem z IO przed monadami polegał na tym, że utrzymanie czystości nie było możliwe w przypadku programów, które faktycznie byłyby przydatne do czegokolwiek. Przez IO rozumiemy wszystko, co dotyczy zmiany stanu, w tym uzyskiwanie danych wejściowych i wyjściowych od użytkownika lub środowiska. W czystym programowaniu funkcjonalnym wszystko jest niezmienne, aby umożliwić lenistwo i czystość (wolne od skutków ubocznych).

Jak monady rozwiązują problem IO? Cóż, bez zbytniego dyskutowania o monadach, w zasadzie pobierają „Świat” (środowisko wykonawcze) jako dane wejściowe do monady i wytwarzają nowy „Świat” jako wynik, a wynik: wpisz IO a = Świat -> (a, Świat).

Dlatego też FP coraz częściej wchodzi do głównego nurtu, ponieważ największy problem, IO (i inne) został rozwiązany. Jak wiadomo, odbywa się również integracja z istniejącymi językami OO. LINQ to na przykład monady.

Aby uzyskać więcej informacji, polecam przeczytać o monadach i artykułach wymienionych w mojej odpowiedzi.

Jednym z głównych problemów podczas programowania tradycyjnych języków, takich jak C, Java, C #, asembler itp., Jest trudna sekwencja kroków, które należy wykonać, aby wykonać dane zadanie, ponieważ najpierw trzeba przygotować wszystkie zależności i ICH zależności wcześniej

Przykład: aby wykonać A, musisz mieć obecne B i C, a B zależy od D i E, co daje coś w rodzaju

• re
• mi
• do
• b
• ZA

ponieważ musisz mieć przygotowane składniki, zanim będziesz mógł ich użyć.

Języki funkcjonalne, zwłaszcza leniwe, przewracają ten język do góry nogami. Pozwalając A powiedzieć, że potrzebuje B i C, i pozwolić środowisku uruchomieniowemu języka dowiedzieć się, kiedy uzyskać B i C (co z kolei wymaga D i E), które wszystkie są oceniane, gdy są potrzebne do oceny A, możesz stworzyć bardzo małe i zwięzłe bloki konstrukcyjne, które dają małe i zwięzłe programy. Leniwe języki pozwalają również na korzystanie z nieskończonych list, ponieważ obliczane są tylko faktycznie używane elementy i bez konieczności przechowywania całej struktury danych w pamięci przed użyciem.

Naprawdę fajna sztuczka polega na tym, że ten automatyczny mechanizm „och, potrzebuję B i C” jest skalowalny, ponieważ nie ma ograniczeń - jak w programie sekwencyjnym - co do tego, gdzie i kiedy ta ocena może się zdarzyć, więc może się zdarzyć na w tym samym czasie, a nawet na różnych procesorach lub komputerach.

Że dlatego Języki funkcjonalne są interesujące - bo «co zrobić, gdy» mechanizm zostaje przejęty przez system wykonawczego w przeciwieństwie do programatora posiadającego to zrobić ręcznie. Jest to tak ważna różnica, jak automatyczne odśmiecanie pamięci dla Javy do C, i jeden z głównych powodów, dla których łatwiej jest pisać solidne, skalowalne, wielowątkowe oprogramowanie w Javie niż w C. Jeszcze łatwiej jest pisać solidne, skalowalne oprogramowanie wielowątkowe w językach funkcjonalnych ...

Na przełomie lat 80. i 90. komputery stały się wystarczająco mocne, by obsługiwać OOP w stylu Smalltalk. W dzisiejszych czasach komputery mają wystarczającą moc do FP. FP programuje na wyższym poziomie i dlatego często - choć przyjemniej jest programować - nie jest to najbardziej efektywny sposób rozwiązania określonego problemu. Ale komputery są tak szybkie, że Cię to nie obchodzi.

Wielordzeniowe prorgamming może być łatwiejsze dzięki czysto funkcjonalnym językom programowania, ponieważ jesteś zmuszony izolować kod zmieniający stan.

Również granice języków programowania są dziś zatarte. Nie musisz rezygnować z jednego paradygmatu, jeśli chcesz użyć innego. Możesz robić FP w najpopularniejszych językach, więc bariera wejścia jest niska.

Dzisiejsze zapotrzebowanie na przetwarzanie rozproszone.

FP wykorzystuje funkcje jako bloki konstrukcyjne, które nie mają stanu, więc wywoływanie ich n razy przy tych samych parametrach powinno zawsze zwracać tę samą wartość, nie mają skutków ubocznych.

W ten sposób możesz wysłać tę samą funkcję do wielu komputerów, aby wykonywać i wykonywać pracę równolegle.

W paradygmacie OO jest to nieco trudniejsze, ponieważ bloki konstrukcyjne są obiektami, które są prawie z definicji stanowe. W przypadku kilkukrotnego wywołania tej samej metody należy zachować ostrożność podczas synchronizacji danych wewnętrznych, aby uniknąć uszkodzenia danych. Chociaż nadal jest to możliwe, paradygmat FP działa lepiej niż OO w niektórych scenariuszach, w których obliczenia muszą być rozproszone.

Pojawienie się FP (i do pewnego stopnia NoSQL) następuje po opowieściach o niesamowitych wynikach obliczeniowych w setkach tysięcy komputerów pracujących równolegle i jak łatwo jest.

Ale prawdopodobnie jest to tylko niszowa aplikacja wymagająca takiej konfiguracji. Dla wielu, wielu innych aplikacji / systemów, procedury i OO działają dobrze.

Zaraz więc poszerzymy nasze horyzonty programistyczne i ponownie przyjrzymy się koncepcjom, które kiedyś uważaliśmy, że nie wykroczą poza środowisko akademickie.

Nauczyłem się programować w Lisp lata temu, a wtedy nie wiedziałem, że to nawet FP. Do tej pory prawie o tym zapomniałem, ale na pewno pomogę mi bardzo łatwo zrozumieć pojęcia takie jak rekurencja.

Przechodzimy do epoki, w której przetwarzanie wielordzeniowe nie jest po prostu czymś wykonywanym w zapleczach laboratoriów naukowych lub na specjalistycznym sprzęcie. Odbywa się to teraz za pomocą procesorów towarowych. Programowanie funkcjonalne, przynajmniej większość wariantów, na które byłem narażony, ogólnie stara się narzucić pogląd na wolne od skutków ubocznych, bezpaństwowe jednostki obliczeniowe. Jest to kwintesencja paradygmatu pracy wielordzeniowej, ponieważ nie trzeba utrzymywać stanu między procesorami.

Jest to tylko jeden z powodów, ale cholernie dobry powód, aby zobaczyć funkcjonalne programowanie.

Myślę, że główną odpowiedzią na to pytanie jest „ujawnienie”.

Programowanie funkcjonalne nie jest niczym nowym, uczyłem się Haskell na uniwersytecie około 12 lat temu i bardzo mi się podobało. Ale rzadko używam tego języka w mojej pracy zawodowej.

Ostatnio w głównym strumieniu zyskuje na popularności kilka języków, które wykorzystują podejście oparte na wielu paradygmatach; F # , JavaScript jest najlepszym przykładem.

W szczególności JavaScript, szczególnie gdy jest używany z funkcjonalnym językiem frameworkowym, takim jak jQuery lub Prototype , staje się językiem codziennym dla wielu osób ze względu na całą pracę nad dynamicznymi nowoczesnymi stronami internetowymi. Ta ekspozycja na funkcjonalny styl sprawia, że ​​ludzie zdają sobie sprawę z mocy, jaką przyznaje, zwłaszcza gdy można wrócić do stylu imperatywnego.

Po ujawnieniu ludzie wypróbowują pełniejsze wersje funkcjonalnych języków i zaczynają wykorzystywać je do codziennych zadań.

Ponieważ F # staje się językiem pierwszej klasy w Visual Studio 2010 i jQuery (i in.) Stają się tak ważne, realistyczne staje się używanie tych języków, a nie tylko coś niejasnego do grania lub tworzenia izolowanych programów.

Pamiętaj, że kod musi być łatwy w utrzymaniu - krytyczna masa programistów musi używać języków i obsługiwać je, aby firmy mogły czuć się bezpiecznie podczas ich używania.

W tej rozmowie Anders Hejlsberg wyjaśnia swój pogląd na ten temat.

[EDYTOWAĆ]

Przepraszamy, link był nieprawidłowy. Teraz wskazuje właściwe miejsce.

Niezwykle krótkie podsumowanie niektórych punktów jednogodzinnej rozmowy:

Języki funkcjonalne pozwalają na bardziej deklaratywny styl programowania niż języki proceduralne, więc programy napisane w języku FL zwykle koncentrują się bardziej na tym, co zamiast na tym, jak . Ze względu na ich elegancką strukturę matematyczną FL są również łatwiejsze do optymalizacji i transformacji przez kompilatory, co umożliwia również łatwe metaprogramowanie i budowę wbudowanych DSL. Wszystko to razem sprawia, że ​​programy funkcyjne są bardziej zwięzłe i samodokumentujące niż programy proceduralne.

Ponadto, w obliczu ery manycore w najbliższej przyszłości, języki programowania muszą być w stanie wykorzystywać wielowątkowość / przetwarzanie na różne sposoby. Wielowątkowość na maszynach z jednym rdzeniem była w istocie mechanizmem dzielenia czasu, co odzwierciedlała architektura systemów. Wielowątkowość na maszynach Manycore będzie zupełnie inna. Języki funkcjonalne nadają się szczególnie do paralelizacji, ponieważ przeważnie unikają stanu, więc nie trzeba się martwić o integralność współdzielonych danych zmiennych (ponieważ zwykle nie ma współdzielonych danych zmiennych).

Myślę, że ma to związek z ścisłą korelacją między paradygmatem programowania funkcjonalnego a programowaniem w Internecie.

Ruby on Rails przyniósł ulgę całemu funkcjonalnemu programowaniu, ponieważ oferuje bardzo szybką ścieżkę do funkcjonalnej aplikacji internetowej (heh heh). Istnieje ciekawa dyskusja na temat SO , a jedna szczególna odpowiedź wyróżnia się:

Programowanie funkcjonalne bardzo dobrze pasuje do aplikacji internetowych. Aplikacja internetowa odbiera żądanie HTTP i generuje wynik HTML. Można to uznać za funkcję od żądań do stron.

Porównaj z aplikacjami komputerowymi, w których zwykle mamy długi proces, stanowy interfejs użytkownika i przepływ danych w kilku kierunkach. Jest to bardziej odpowiednie dla OO, który martwi się obiektami z przekazywaniem stanu i wiadomości.

Biorąc pod uwagę, że programowanie funkcjonalne istnieje od wieków, zastanawiam się, dlaczego nie widzę wielu ogłoszeń o pracy szukających programistów Lisp do projektów sieciowych typu greenfield.

Programowanie funkcjonalne daje mi takie samo mrowienie: „ wow, to jest nowe ”, jak wtedy, gdy wiele lat temu zacząłem bawić się przedmiotami.

Zdaję sobie sprawę z tego, że FP nie jest jak dotąd nową koncepcją, ale nie było też OO, kiedy nastąpił prawdziwy przełom w latach dziewięćdziesiątych, kiedy „wszyscy” nagle odeszli od programowania proceduralnego. Było to w dużej mierze spowodowane terminowym sukcesem Javy, a później C #.

Wyobrażam sobie, że to samo stanie się z FP, gdy kolejna partia języków zacznie się rozprzestrzeniać w ten sam sposób. Chociaż mają już, przynajmniej w niektórych kręgach, języki takie jak Scala i F #.

Oto moje pytania: 1. Co przyczyniło się do ostatniego entuzjazmu FP? Czy jest to tylko nuda z OO, czy też coś się zmieniło, aby FP była bardziej potrzebna niż wcześniej? 2. Czy świadczy to o przyszłości PR? A może to moda, jak bazy danych zorientowane obiektowo?

Inni podali dobry powód techniczny.

Myślę, że głównym powodem, dla którego FP zyskuje na popularności wśród przeciętnych deweloperów i menedżerów, jest obietnica umożliwienia lepszego wykorzystania wielordzeniowych procesorów. Ze wszystkiego, co przeczytałem, FP umożliwia łatwiejsze (niełatwe) programowanie równoległe.

Jego przyszłe powszechne zastosowanie będzie możliwe, jeśli obietnica będzie prawdziwa i zostanie spełniona.

Myślę, że jest to połączenie dwóch trendów:

1. Funkcje funkcjonalne dodawane do głównych języków (np. C #).
2. Tworzone są nowe języki funkcjonalne.

Prawdopodobnie istnieje naturalny limit dla pierwszego trendu, ale domyślam się, że każdy nowy język będzie musiał obsługiwać programowanie funkcjonalne, przynajmniej jako opcja, aby być traktowanym poważnie.

Kiedyś ludzie pisali programy do uruchamiania na pulpicie przy użyciu rodzimych interfejsów API systemu operacyjnego, a te interfejsy API były (ogólnie) pisane w języku C, więc w większości przypadków, jeśli chcesz napisać program dla rodzimych interfejsów API, napisał ten program w C.

Myślę, że nową innowacją w ciągu ostatnich 10 lat jest różnorodność interfejsów API, na które warto zwrócić uwagę, szczególnie w takich sprawach, jak tworzenie stron internetowych, w których interfejsy API platformy są nieistotne (ponieważ tworzenie strony internetowej zasadniczo wymaga manipulacji ciągami). Ponieważ nie kodujesz bezpośrednio do Win32 API lub POSIX API, daje to ludziom swobodę wypróbowania funkcjonalnych języków.

Jest schludny, sprytny i łaskocze twój mózg. W porządku.

Jest to także IMHO, klasyczny modwagon. Rozwiązanie szukające problemu.

To tak, jak wszystkie te start-upowe firmy założone przez inżynierów oszołomionych ulubionym pomysłem, które płoną jasno przez chwilę, ale są cicho wyprzedzane przez firmy oparte na dostarczaniu tego, co jest potrzebne.

To nowy pomysł, który chciałbym zobaczyć, programowanie oparte na potrzebach, a nie programowanie oparte na pomysłowych pomysłach. Może to brzmi przyziemnie, ale myślę, że w rzeczywistości może być dość kreatywne i sprytne.

Zdecydowanie z powodu F #, chociaż czasami trudno jest powiedzieć, która jest przyczyną, a która skutkiem.