Dlaczego języki funkcjonalne? [Zamknięte]

332

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?

MattBelanger
źródło
John Hughes napisał o tym artykuł: Dlaczego programowanie funkcjonalne ma znaczenie .
Hjulle,

Odpowiedzi:

214

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.

Mendelt
źródło
14
MOŻESZ programować funkcjonalnie w Pythonie, ale to naprawdę okropne. stackoverflow.com/questions/1017621/…
Gordon Gustafson
28
To nie trudno napisać kod IO w czystej językach funkcjonalnych. Wszystkie zapewniają prosty mechanizm pisania kodu IO, który działa tak samo jak w imperatywnych językach. Wszystko, co robią, to wymuszanie, że nie można wywoływać kodu IO wewnątrz innego kodu, którego interfejs jest zadeklarowany jako nie wykonujący IO. Analogią byłby programista języka dynamicznego, który narzekałby, że statycznie typowany język, taki jak Java, utrudnia zwrócenie dowolnego typu z metody, ponieważ musi zwrócić wszystko, co deklaracja typu mówi, że zwróci.
Ben
9
Haskell to przykład czysto funkcjonalnego języka, który nie ma wady, o której mówiłeś. To sprawia, że ​​radzenie sobie z efektami ubocznymi jest znacznie łatwiejsze, ponieważ efekty uboczne są enkapsulowane, i umożliwia programistom osiągnięcie znacznie silniejszego poziomu abstrakcji niż języków imperatywnych ... Naprawdę, każdy powinien dać Haskellowi szansę, naprawdę go zrozumieć i zdać sobie sprawę dlaczego jest tak potężny.
FtheBuilder
202

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.

joel.neely
źródło
55
Spójrz tylko 20 lat wstecz. Nie wydaje mi się, żeby programowanie bardzo ewoluowało. Mają lepsze narzędzia, może nowy język lub 2, ale zasadniczo niewiele się zmieni. Zajmie to ponad 20 lat. Wszyscy kiedyś myśleliśmy, że zobaczymy latające samochody w 2000 roku. :)
bibac
32
O'Caml jest Irlandczykiem.
defmeta
7
@alex dziwne: „Sprzyjanie niezmienności” i „unikanie skutków ubocznych” były dobrą zasadą od dłuższego czasu zarówno w szkołach programowania obiektowego, jak i imperatywnego. (Więc czego nie lubić? ;-)
joel.neely
101
@bibac: 20 lat temu pisaliśmy kod C i omawialiśmy zalety Clippera lub Turbo Pascala. Object Orientation była wyłączną sferą naukowców. Twierdzenie, że niewiele się zmieniło, jest wręcz absurdalne.
Daniel C. Sobral
24
@Daniel: Podaj listę osób, które opowiadały się za „zaletami” Clippera. Muszą zostać upolowani i postawieni przed wymiarem sprawiedliwości.
David
125

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.

Steven Robbins
źródło
4
Już to widzimy. I stanie się więcej w przyszłości. Zgadzam się więc w 100% w tej kwestii.
Jason Baker
Trudną rzeczą jest to, że ze względu na wspólne efekty uboczne FP nic / brak sprawiają, że jest tak odpowiedni do równoległości. I to są aspekty, które nie pasują do rozwiązań OO - tworzenie skutecznych hybryd jest niezwykle trudne. Być może klej FP między węzłami OO?
James Brady
Aby uzyskać skuteczną hybrydę, zobacz gałąź 2.0 języka programowania D. Jest w fazie alpha / w toku, ale się tam rozwija.
dsimcha
2
Uważam tę odpowiedź za interesującą, nie znam żadnego języka funkcjonalnego, dlaczego uważa się ją za bardziej odpowiednią do równoległości?
iandandand
26
Ponieważ nie ma wspólnych danych, funkcje nie mają skutków ubocznych. Wszystko, na czym Ci zależy, to wartość zwrotu. (Jest to dość trudny pomysł dla programisty OO / proceduralnego, aby odwrócić głowę.) Dlatego można wywoływać wiele funkcji jednocześnie, o ile dane wyjściowe z jednej nie są wykorzystywane jako dane wejściowe do drugiej.
Tom Smith
79

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.

użytkownik21714
źródło
Dobra uwaga, ale chciałbym zobaczyć wyjaśnienie „w jaki sposób uczyni cię lepszym programistą”
mt3,
20
Różne paradygmaty programowania podchodzą do problemów z różnych punktów widzenia i często wymagają „innego sposobu myślenia” lub sposobu myślenia. A trenowanie siebie na wiele różnych sposobów myślenia (co oznacza uczenie się, którego użyć w jakiej sytuacji ...) nigdy nie jest złe.
peSHIr
56

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.

Norman Ramsey
źródło
Nie wiem o uniwersytetach w Wielkiej Brytanii. Prawdopodobnie przekonasz się, że wiele uniwersytetów uczy tutaj bardzo niewielu języków programowania (Java, C, może Perl, jeśli masz szczęście). Problemem jest tutaj różnica w jakości, ponieważ najlepsze (nieliczne) uniwersytety mają najlepsze programy CS.
Mike B
Nie zgadzam się z podanymi przez ciebie przykładami, które są wadliwe, być może niszowe lub odpowiednie dla niektórych obszarów, ale wystarczają do ogólnego zastosowania, aby można je było zająć uniwersalnie bez ogromnej krzywej uczenia się. to prawdopodobnie największy powód ich sukcesu.
gbjbaanb
Zrobiłem Forth i Lisp na uni w Wielkiej Brytanii (a także Pascal, C, Modula2 i Cobol), ale to było 20 lat temu ..
kpollock
29
Nauczono mnie Java / C ++ na uni (w Australii), ale kilku moich współpracowników poszło na różne uniwersytety, gdzie zrobili kilka jednostek w Haskell. Wykorzystano go zarówno do wprowadzenia do programowania, jak i do jednego z ich ostatnich lat. Zaśmiałem się, gdy usłyszałem, co powiedział mój współpracownik wykładowcy Javy po tym, jak po raz pierwszy zapoznał się z castingiem (w tym momencie znał tylko Haskella) - „Co ?! Masz na myśli, że coś masz, a ty nie” T KNOW jakiego typu jest ?!”
Jacob Stanley
1
Spójrz, co stało się z C # z tymi wszystkimi Europejczykami w zespole :)
Benjol
32

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

Psvensson
źródło
2
Tak naprawdę zacząłem kopać programowanie funkcjonalne. Nie ma nic lepszego niż lista Prototype.js. Każda (funkcja (pozycja) {}) lub cała metoda działania jQuery.
Cory R. King
20
JavaScript umożliwia programowanie w funkcjonalny sposób. Jest to jednak język paradygmatu, który pozwala programować na różne sposoby (co wolę, ale to nie dotyczy) ... OO, funkcjonalne, proceduralne itp.
RHSeeger
+1, patrz codex.sigpipe.cz/zeta
po prostu ktoś
Metody obiektowe jQuery to tylko operacje na monadzie listy. Przyjmowanie obiektu reprezentującego kontener (lub sekwencję) jako danych wejściowych i zwracanie kontenera obiektów jako danych wyjściowych jest doskonałym przykładem praktycznego ponownego opracowania fmap.
Jared Updike,
25

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.

Michael Paulukonis
źródło
25

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
bretoński
źródło
10
Jak JavaScript jest uważany za programowanie funkcjonalne?
Pacerier
8
Ma pierwszorzędne funkcje, funkcje wyższego rzędu, zamknięcia, anonimowe funkcje, częściowe zastosowanie, curry i kompozycję.
daniel1426
2
Ha ha. Kiedyś napisałem formułę Excel dotyczącą spłaty obciążenia, która była szersza niż ekran z zagnieżdżonymi funkcjami. W pewnym momencie wiedziałem, że programuję funkcjonalnie, ale nie znałem jeszcze tego terminu.
ProfK
7
Dodaj C do tej listy
Mandeep Janjua
2
@MandeepJanjua: Huh? Dlaczego? A dlaczego nie jakiś język?
Sz.
18

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. ;)

jalf
źródło
MIT wykorzystywane do nauczania programu w swoim wstępie CS Oczywiście, ale używa teraz Pythona.
mipadi
1
„15 lat temu nie rozumieli OOP” - Problem w tym, że 15 lat temu też nie rozumieli FP. I nadal tego nie robią.
Jason Baker
15

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”

shawndumas
źródło
12

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.

Kyle Cronin
źródło
12

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.

obecalp
źródło
6
Nie sądzę, że OO jest z natury łatwiejsze niż FP. To zależy od twojego pochodzenia (jestem matematykiem, zgadnij, co jest dla mnie łatwiejsze? :) Cholera, OO ludzie i twoje szalone zasady.
temp2290
14
Monady nie są trudne do zrozumienia. Nie kupuj tego byka.
Rayne
-1 OOP jest trudniejsze niż FP
tylko ktoś
-1 Nie pisalibyśmy optymalizujących kompilatorów używających OCaml lub Haskell, gdyby FP było odpowiednie tylko dla ładnych problemów matematycznych.
gracchus
8

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 #?

Mike K.
źródło
Dobra uwaga +1. @Mendelt: „bardziej dostępny”? Czy masz na myśli, że ból głowy jest szybszy, gdy oglądasz kod?
Patrick Honorez,
2
Zobacz bibliotekę F #: quanttec.com/fparsec/tutorial.html . Chciałbym zobaczyć przykładowy kod w języku C # z parserami, które wyglądały w połowie tak elegancko i czytelnie jak kod F #, nawet jeśli zostały skompilowane według tych samych instrukcji. I spróbuj przenieść FParsec z F # na C # i zobacz, jak kod się rozszerza.
Jared Updike,
8

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?

RD1
źródło
2
* Przeciętny programista korporacyjny, np. Większość ludzi, z którymi pracuję, nie zrozumie tego, a większość środowisk pracy nie pozwoli ci się na to programować - to nadal dotyczy OOP w wielu miejscach, w których pracowałem :) (oczywiście mówią robią OOP, ale nie są)
tolanj
7

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.

zendar
źródło
6
Twierdzę, że Scala była dość głębokim fundamentem dla JRE.
cdmckay
2
Jeśli chodzi o biblioteki, to naprawdę zależy od tego, co robisz. F # jest skierowany do sektora finansowego i ma również zastosowanie do obliczeń naukowych, ale OCaml ma o wiele lepsze biblioteki dla takich aplikacji niż .NET. Na przykład, kiedy przyszedłem do F # z OCaml, nie znalazłem przyzwoitej FFT i skończyłem pisać (i sprzedawać) własne w C #, a potem F #.
Jon Harrop,
1
LINQ jest dobrym pomostem do używania funkcjonalnych koncepcji z C # i VB.Net ... I uważam, że czytanie jest o wiele mniej bolesne w porównaniu do F #
Matthew Whited
5

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.

Jason Baker
źródło
Daj +1, ale nie zapomnij o sile marketingu, a także o tym, że góra Twojej starej firmy nie zmieni języka dzięki jakimś nowym, modnym trendom.
temp2290
I zapomniałeś wspomnieć: Google popularyzuje Pythona.
Hao Wooi Lim
4

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.

tylermac
źródło
4

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.

Tim
źródło
1
C # jest teraz funkcjonalnym językiem programowania (podobnie jak Lisp), ponieważ ma najwyższej klasy zamknięcia leksykalne. Rzeczywiście są one już używane w WPF i TPL. Więc programowanie funkcjonalne jest oczywiście już tutaj.
Jon Harrop,
4

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

Janis Veinbergs
źródło
3

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ą.

Głaskanie pod brodę
źródło
3

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.

Juliet
źródło
3

Kwestia Dlaczego programowanie funkcjonalne ma znaczenie

grom
źródło
Link nie otwiera się. Błąd 403.
Alexey Frunze,
To może być dobry zamiennik? cs.kent.ac.uk/people/staff/dat/miranda/whyfp90.pdf
canadiancreed
Martwy link. Dlatego tego rodzaju odpowiedzi są niekorzystne zarówno dla cytowania, jak i łączenia.
Sylwester
Naprawiłem link. @Sylwester to prawda, ale jest to 23-stronicowy dokument. Dystrybucja papieru w celu uzyskania odpowiedzi na tej stronie nie oddałaby tego sprawiedliwie.
grom
2

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ć?

duffymo
źródło
2

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.

Sebastian
źródło
Przepraszamy, ale FP było prawie 3 razy dłuższe niż OOP. To po prostu nie jest kwestia potrzeby więcej czasu. Sprawienie, by PR stało się głównym nurtem, wymaga jeszcze czegoś więcej.
Jason Baker
Jak mogłeś przegapić tę część mojego postu, w której wyjaśniam, że „coś więcej” może równie dobrze być wielordzeniowe? A coś „przebywania w pobliżu” nie jest tak naprawdę istotne. Ludzie rozumieli OOP, ponieważ oferował wówczas wymierne korzyści, FP dopiero niedawno stała się praktyczna.
Sebastian
2

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.

Pete OHanlon
źródło
2

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ść.

Bretoński
źródło
2

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.

Arachid
źródło
2

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.

Ingo
źródło
1

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.

Rodrick Chapman
źródło