Dlaczego języki funkcyjne? [zamknięte]

Myślę, że nie ma żadnych wątpliwości co do funkcjonalnego podejścia do programowania "łapania się", ponieważ jest ono używane (jako styl programowania) od około 40 lat. Ilekroć programista oo pisze czysty kod, który faworyzuje niezmienne obiekty, kod ten zapożycza pojęcia funkcjonalne.

Jednak języki, które wymuszają styl funkcjonalny, w dzisiejszych czasach zyskują wiele Wirtualnego atramentu i czy te języki staną się dominujące w przyszłości, jest kwestią otwartą. Moje własne podejrzenia są takie, że hybrydowe, wielowymiarowe języki takie jak Scala Czy OCaml prawdopodobnie będzie dominował nad "purystycznymi" językami funkcyjnymi w taki sam sposób, jak czysty język OO (Smalltalk, Beta itp.) miały wpływ na programowanie głównego nurtu, ale nie znalazły się jako najczęściej używane notacje.

Wreszcie, nie mogę się oprzeć wskazaniu, że Twoje komentarze re FP są bardzo równoległe do uwag, które słyszałem od programistów proceduralnych nie tak wiele lat temu:

• (mityczny, IMHO) "Przeciętny" programista tego nie rozumie.
Nie jest szeroko nauczany.
• każdy program, który można za jego pomocą napisać, może być napisany w inny sposób przy użyciu obecnych technik.

Tak jak graficzne interfejsy użytkownika i "Kod jako model biznesu" były koncepcjami, które pomogły OO stać się bardziej doceniane, wierzę, że zwiększone wykorzystanie niezmienności i prostsze (masowe) równoległość pomoże więcej programistów zobaczyć korzyści które oferuje podejście funkcjonalne. Ale tyle, 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ąż mamy wiele do nauczenia się. Za dwadzieścia lat Programiści ze zdumieniem spojrzą wstecz na prymitywną naturę narzędzi, których obecnie używamy, w tym popularnych obecnie języków OO i FP.

Głównym plusem jest dla mnie jego nieodłączna paralelizm, zwłaszcza że teraz oddalamy się od większej liczby MHz i zmierzamy do coraz większej liczby rdzeni.

Nie sądzę, aby stał się on kolejnym paradygmatem programowania i całkowicie zastąpił metody typu oo, ale myślę, że dojdziemy do punktu, w którym musimy albo napisać część naszego kodu w języku funkcyjnym, albo nasze języki ogólnego przeznaczenia urosną do bardziej funkcjonalnych konstrukcji.

Nawet jeśli nigdy nie pracujesz zawodowo w języku funkcyjnym, zrozumienie programowania funkcyjnego uczyni cię lepszym programistą. Da ci to nowe spojrzenie na Twój kod i programowanie w ogóle.

Mówię, że nie ma powodu, by tego nie nauczyć.

Myślę, że języki, które dobrze mieszają styl funkcjonalny i imperatywny, są najciekawsze i najbardziej prawdopodobne, że odniosą sukces.

Zawsze jestem sceptyczny co do następnej wielkiej rzeczy. Wiele razy następną wielką rzeczą jest czysty przypadek historii, bycie 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ż postrzegano je albo jako rozwiązanie problemów dnia, albo jako niemal identyczne z zakorzenionymi standardami, albo oba. Programowanie funkcyjne może być naprawdę świetne, ale to nie znaczy, że będzie adoptowany.

Ale ja mogę powiedzieć ci, dlaczego ludzie są podekscytowani na temat programowania funkcyjnego: wielu, wielu programistów doświadczyło swego rodzaju "doświadczenia konwersji", w którym odkrywają, że używanie języka funkcjonalnego sprawia, że są dwa razy bardziej produktywni (a może dziesięć razy bardziej produktywni), jednocześnie tworząc kod, który jest bardziej odporny na zmiany i ma mniej błędów. Ci ludzie myślą o programowaniu funkcyjnym jako tajnej broni; dobrym przykładem tego sposobu myślenia jest Paul Graham pokonywanie średnich . A jego podanie? Aplikacje internetowe E-commerce.

Od początku 2006 r. pojawiły się również informacje o programowaniu funkcyjnym i paralelizmie. Ponieważ ludzie tacy jak Simon Peyton Jones martwią się o równoległość od co najmniej 1984 roku, nie wstrzymuję oddechu, dopóki języki funkcjonalne nie rozwiążą problemu wielordzeniowego. Ale to wyjaśnia trochę dodatkowego szumu właśnie teraz.

Ogólnie Rzecz Biorąc, amerykańskie uczelnie są kiepska praca w nauczaniu programowania funkcyjnego. Istnieje silne wsparcie dla nauczania programowania intro przy użyciu Scheme, a Haskell również cieszy się pewnym wsparciem, ale jest bardzo niewiele w sposobie nauczania zaawansowanych technik dla programistów funkcyjnych. Uczyłem takiego kursu na Harvardzie i zrobię to ponownie tej wiosny w Tufts. Benjamin Pierce prowadził taki kurs w Penn. Nie wiem, czy Paul Hudak robił coś w Yale. Uniwersytety Europejskie to na przykład programowanie funkcjonalne jest podkreślane w ważnych miejscach w Danii, Holandii, Szwecji i WIELKIEJ BRYTANII. Mam mniej poczucia tego, co dzieje się w Australazji.

Nie widzę tu nikogo, kto by wspominał o słoniu w pokoju, więc myślę, że to zależy ode mnie:)

JavaScript jest językiem funkcyjnym. Ponieważ coraz więcej osób robi bardziej zaawansowane rzeczy z JS, szczególnie wykorzystując drobniejsze punkty jQuery, Dojo i innych frameworków, FP zostanie wprowadzony przez tylne drzwi programisty.

W połączeniu z zamknięciami, FP sprawia, że kod JS jest naprawdę lekki, a jednocześnie czytelny.

Cheers, PS

Większość aplikacji jest na tyle prosta, że można ją rozwiązać w normalny sposób

1. Oo sposoby nie zawsze były " normalne."Standard tej dekady był marginalizowaną koncepcją ostatniej dekady.

2. Programowanie funkcyjne to matematyka. Paul Graham on Lisp (zastępcze Programowanie funkcyjne dla Lispu):

Więc krótkie wyjaśnienie dlaczego to 1950. język nie jest przestarzały jest to, że nie była to technologia, lecz matematyka i matematyka nie jest czerstwy. Prawo rzecz, do której można porównywać Lisp to nie Lata 50-te sprzęt, ale powiedzmy, Quicksort algorytm, który został odkryty w 1960 i nadal jest najszybszy sortowanie ogólnego przeznaczenia.

Założę się, że nie wiedziałeś, że używasz programowania funkcyjnego:

• Formuły Excel
• Quartz Composer
• Javascript
• Logo (grafika żółwia)
• LINQ
• SQL
• podkreślenie.js (lub Lodash), D3

Przeciętny programista korporacyjny, np. większość ludzi, z którymi pracuję, będzie nie rozumiem tego i większość pracy środowiska nie pozwolą Ci zaprogramować in it

To nie jest tak naprawdę nauczane na uniwersytetach. (lub jest teraz?)

Bardzo się różni. Na mojej uczelni, SML jest bardzo pierwszy język studenci są wprowadzane do. Wierzę, że MIT uczy Lispu jako kursu pierwszego roku. Te dwa przykłady mogą oczywiście nie być reprezentatywne, ale uważam, że większość uniwersytetów przynajmniej oferuje pewne fakultatywne kursy na temat PR, nawet jeśli nie stanowią one obowiązkowej części programu nauczania.

Większość aplikacji jest na tyle prosta, aby be solved in normal oo ways

It ' s not really ale to kwestia "dość prosta". Czy rozwiązanie byłoby prostsze (lub bardziej czytelne, solidne, eleganckie, wydajne) W FP? Wiele rzeczy jest "na tyle prostych, że można je rozwiązać w Javie", ale wciąż wymaga to godawful ilości kodu.

W każdym razie, należy pamiętać, że zwolennicy FP twierdzą, że to była następna wielka rzecz od kilku dziesięcioleci. Być może mają rację, ale pamiętaj, że nie byli, gdy złożyli to samo żądanie 5, 10 lub 15 lat temu.

Jedna rzecz, która na ich korzyść zdecydowanie liczy się jednak to, że ostatnio C# Ostro skręcił w kierunku FP, do tego stopnia, że praktycznie zmienia pokolenie programistów w programistów FP, nawet nie zauważając. To może utorować drogę do "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 w technice, a następnie uczeń i artysta muszą uczyć się więcej i szukać dalej. Warto studiować inne sztuki, a także strategie.

Któż nie nauczył się czegoś więcej o sobie obserwując działania innych? Aby nauczyć się miecza, ucz się gry na gitarze. Aby nauczyć się pierwszej nauki handlu. Na po prostu studiować miecz uczyni cię wąskim umysłem i nie pozwoli Ci rosnąć na zewnątrz.

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

Jedną z kluczowych cech języka funkcjonalnego jest pojęcie funkcji pierwszej klasy. Chodzi o to, że można przekazywać funkcje jako parametry innym funkcjom i zwracać je jako wartości.

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

Haskell zamiast tego stosuje inne podejście do IO: monads. Są to obiekty, które zawierają żądaną operację IO do wykonania przez najwyższy poziom interpretera. Na każdym innym poziomie są po prostu obiektami w systemie.

Jakie korzyści daje programowanie funkcjonalne? Funkcjonalne programowanie pozwala na kodowanie z mniejszym potencjałem błędów, ponieważ każdy komponent jest całkowicie izolowany. Ponadto użycie funkcji rekurencyjnych i pierwszorzędnych pozwala na proste dowody poprawności, które zazwyczaj odzwierciedlają strukturę kodu.

Nie wydaje mi się, aby większość realistów uważała, że programowanie funkcjonalne będzie się chwalić (staje się głównym paradygmatem jak OO). W końcu większość problemów biznesowych to nie dość matematyczne problemy, ale bezwzględne Zasady przenoszenia danych i wyświetlania ich na różne sposoby, co oznacza, że nie jest to dobre dopasowanie do czystego paradygmatu programowania funkcyjnego (krzywa uczenia się monad znacznie przekracza OO.)

OTOH, Programowanie funkcyjne jest tym, co sprawia, że programowanie jest zabawne. To sprawia, że doceniasz nieodłączne, ponadczasowe piękno zwięzłych wyrażeń leżących u podstaw matematyki wszechświata. Ludzie mówią, że uczenie się programowania funkcyjnego uczyni cię lepszym programistą. Jest to oczywiście bardzo subiektywne. Osobiście też nie sądzę, żeby to była do końca prawda.

To czyni cię lepszym czującym bytem.

Muszę być gęsty, ale nadal tego nie rozumiem. Czy są jakieś rzeczywiste przykłady małych aplikacji napisanych w funkcjonalnym języku, takim jak F#, gdzie można spojrzeć na kod źródłowy i zobaczyć, jak i dlaczego lepiej było użyć takiego podejścia niż, powiedzmy, C#?

F # może się załapać, bo Microsoft na to naciska.

Pro:

• F # będzie częścią kolejnej wersji Visual Studio
[5]}Microsoft od jakiegoś czasu buduje społeczność-ewangelistów, książki, konsultantów, którzy pracują z klientami o wysokim profilu, znaczną ekspozycją na konferencjach MS.
• F # to język. Net pierwszej klasy i jest to pierwszy funkcjonalny język, który ma naprawdę duże podstawy (nie mówię, że Lisp, Haskell, Erlang, Scala, OCaml nie ma wielu bibliotek, po prostu nie są tak kompletne jak. Net)
• silne poparcie dla paralelizmu

Contra:

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

Więc daję 50: 50 szansę, aby F # stać się ważne. Inne języki funkcyjne nie dotrą do niego w najbliższej przyszłości.

Chciałbym zauważyć, że wszystko, co powiedziałeś o językach funkcyjnych, większość ludzi mówiła o języku zorientowanym obiektowo około 20 lat temu. Wtedy bardzo często było słychać 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ć. Istotna i ważna zmiana nastąpi sama w sobie 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 przeciw?

Myślę, że jednym z powodów jest to, że niektórzy ludzie uważają, że najważniejszą częścią tego, czy język zostanie zaakceptowany, jest to, jak dobry jest język . Niestety, rzeczy rzadko są tak proste. Na przykład twierdzę, że największym czynnikiem stojącym za akceptacją Pythona nie jest sam język (chociaż to jest dość ważne). Największym powodem, dla którego Python jest tak popularny, jest ogromna biblioteka standardowa i jeszcze większa społeczność 3rd party biblioteki.

Języki takie jak Clojure lub F# mogą być wyjątkiem od reguły w tym zakresie, biorąc pod uwagę, że są zbudowane 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ż to prawda, różne narzędzia mogą być używane do rozwiązywania różnych problemów. Funkcjonalny tylko pozwala na kolejny wysoki (wyższy?) poziom abstrakcji, który pozwala na bardziej efektywne wykonywanie naszych zadań przy prawidłowym użytkowaniu.

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

To minie.

Programowanie funkcyjne jest świetne. Jednak nie zawładnie światem. C, C++, Java, C#, itp. nadal będzie w pobliżu.

Co z tego wyniknie, myślę, że jest to bardziej zdolność cross-language - na przykład implementowanie rzeczy w funkcjonalnym języka, a następnie daje dostęp do tych rzeczy w innych językach.

Czytając" The Next Mainstream Programming Language: A Game Developer 's Perspective" Tima Sweeneya, Epic Games, moja pierwsza myśl brzmiała - nauczyłem się Haskella.

PPT

Wersja HTML Google

Rzeczy od jakiegoś czasu poruszają się w kierunku funkcjonalnym. Dwa nowe, fajne dzieci z ostatnich kilku lat, Ruby i Python, są radykalnie bliższe językom funkcyjnym niż to, co było przed nimi - tak bardzo, że niektórzy Lisperzy zaczęli wspierać jeden lub drugi jako " wystarczająco blisko."

I z masowo równoległym sprzętem, który wywiera ewolucyjną presję na wszystkich - i funkcyjnymi językami w najlepszym miejscu, aby poradzić sobie ze zmianami - nie jest to tak daleko, jak kiedyś było myśleć, że Haskell lub F # będzie następną wielką rzeczą.

Śledziłeś ostatnio ewolucję języków programowania? Każde nowe wydanie wszystkich głównych języków programowania wydaje się zapożyczać coraz więcej funkcji z programowania funkcyjnego.

• Zamknięcia, funkcje anonimowe, przekazywanie i zwracanie funkcji jako wartości były kiedyś egzotycznymi funkcjami znanymi tylko hakerom Lispu I ML. Stopniowo jednak C#, Delphi, Python, Perl, Javascript, dodały wsparcie dla zamknięć. Nie jest to możliwe dla każdego języka up-and-coming do być traktowane poważnie bez zamknięć.

• Wiele języków, w szczególności Python, C# i Ruby, posiada natywne wsparcie dla kompilacji list I GENERATORÓW list.

• ML jest pionierem w programowaniu generycznym w 1973 roku, ale wsparcie dla generyków ("parametryczny polimorfizm") stało się standardem przemysłowym dopiero w ciągu ostatnich 5 lat. Jeśli dobrze pamiętam, Fortran obsługiwał generics w 2003, następnie Java 2004, C# w 2005, Delphi w 2008. (Wiem, że C++ ma obsługiwane szablony od 1979 roku, ale 90% dyskusji na STL C++zaczyna się od "here there be demons".)

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ć-co najmniej-zamknięcia, jeśli chcą pozostać konkurencyjni. Pod tym względem programowanie funkcjonalne jest już w głównym nurcie.

Większość aplikacji jest na tyle prosta, aby być rozwiązane w normalne oo sposoby

Kto powiedział, że nie można używać programowania funkcyjnego do prostych rzeczy? Nie każdy program funkcjonalny musi być kompilatorem, programowalnym lub masowo równoległym przełącznikiem telekomunikacyjnym. Oprócz bardziej skomplikowanych projektów regularnie używam F# do skryptów ad hoc throwaway.

Łapie się, ponieważ jest to najlepsze narzędzie do kontrolowania złożoności. Zobacz:
- slajdy 109-116 z Simon Peyton-Jones talk "A Taste of Haskell"
- "The Next Mainstream Programming Language: A Game Developer 's Perspective" - Tim Sweeney

Dlaczego Programowanie Funkcyjne Ma Znaczenie

Zgadzam się z pierwszym punktem, ale czasy się zmieniają. Korporacje zareagują, nawet jeśli są późnymi adopcjami, jeśli zobaczą, że można mieć 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 "expose relational databases on the web" będzie działać w tym duchu przez długi czas. Java EE, . NET, RoR i PHP rozwinęły kilka całkiem dobrych rozwiązań tego problemu.

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

Czy masowy sprzęt wielordzeniowy i cloud computing popchną ich do przodu?

Ponieważ FP ma znaczące korzyści pod względem wydajności, niezawodności i łatwości konserwacji. Wiele rdzeni może być zabójczą aplikacją, która w końcu sprawia, że duże korporacje przełączają się pomimo dużych ilości starszego kodu.Co więcej, nawet duże języki komercyjne, takie jak C#, nabierają wyraźnego funkcjonalnego smaku w wyniku wielu podstawowych problemów - efekty uboczne po prostu nie pasują dobrze do współbieżności i równoległości.

Nie zgadzam się, że "normalni" Programiści tego nie zrozumieją. Oni will, tak jak w końcu zrozumieli OOP (który jest równie tajemniczy i dziwny, jeśli nie bardziej).

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

Wow-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 none-FP). Języki None-FP już zaczynają brać pomysły z FP, więc podejrzewam, że ten trend będzie się utrzymywał i zobaczymy więcej połączenia, które powinno ułatwić ludziom przejście do FP.

Nie wiem, czy się załapie, czy nie, ale z moich badań wynika, że język funkcjonalny jest prawie na pewno wart nauki i uczyni cię lepszym programistą. Samo zrozumienie przejrzystości odniesienia sprawia, że wiele decyzji projektowych jest o wiele łatwiejszych - a wynikające z nich programy o wiele łatwiejsze do rozumowania. Zasadniczo, jeśli napotkasz problem, to zwykle jest to problem tylko z wyjściem pojedynczej funkcji, a nie problem ze stanem niespójnym, który może zostały spowodowane przez którąkolwiek z setek klas / metod/funkcji w języku przekazującym z efektami ubocznymi.

Bezpaństwowa natura FP mapuje bardziej naturalnie bezpaństwową naturę sieci, a tym samym języki funkcjonalne łatwiej nadają się do bardziej eleganckich, spokojnych aplikacji internetowych. Kontrast z frameworkami JAVA i. Net, które muszą uciekać się do strasznie brzydkich hacków, takich jak ViewState i klucze sesji, aby utrzymać stan aplikacji i utrzymać (czasami dość nieszczelny) abstrakcja państwowego języka imperatywnego, na zasadniczo bezpaństwowej platformie funkcjonalnej, takiej jak sieć.

A także, im bardziej bezpaństwowa Aplikacja, tym łatwiej nadaje się do przetwarzania równoległego. Niezwykle ważne dla sieci, jeśli Twoja strona stanie się popularna. Nie zawsze jest łatwo po prostu dodać więcej sprzętu do witryny, aby uzyskać lepszą wydajność.

Moim zdaniem to się załapie teraz, gdy Microsoft wypchnął go znacznie dalej do głównego nurtu. Dla mnie jest to atrakcyjne 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óre ma pretensje do przyszłości.

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

Pominięto punkt w dyskusji, że najlepsze systemy typów znajdują się we współczesnych językach FP. Co więcej, Kompilatory mogą automatycznie wywnioskować wszystkie (lub przynajmniej większość) typy.

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

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

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