Dlaczego programowanie funkcjonalne jeszcze nie zostało przejęte?

Masterminds of Programming: rozmowy z twórcami głównych języków programowania

[Haskell]

Jak myślisz, dlaczego żaden funkcjonalny język programowania nie wszedł do głównego nurtu?

Kiepski marketing! Nie mam na myśli propagandy. Mam na myśli staranny wybór docelowej niszy rynkowej do dominacji, a następnie zdecydowany wysiłek, aby programowanie funkcjonalne było zdecydowanie najbardziej skuteczne sposób na zajęcie się tą niszą. W szczęśliwych latach 80. myśleliśmy, że programowanie funkcjonalne jest dobre dla wszystkiego - ale nazywanie nowej technologii "dobrą do wszystkiego" jest tym samym, co nazywanie jej "szczególnie dobrą w niczym". Jaka ma być Marka? Jest to problem, który John Launchbury opisał bardzo wyraźnie w swoim zaproszonym wystąpieniu w ICFP. Połączenia Galois prawie upadły, gdy ich marka była "oprogramowaniem w językach funkcyjnych", ale od koncentrując się na " wysokiej jakości oprogramowaniu."

Wiele osób nie ma pojęcia, jak postępują innowacje technologiczne i oczekuje, że lepsza technologia stanie się po prostu Dominująca sama w sobie( efekt "lepszej pułapki na myszy" [4]), ale świat nie jest taki.

Odpowiedź giełdowa jest taka, że żadne z nich nie zastąpi ani nie zastąpi drugiego - są to różne narzędzia, które mają różne zestawy zalet i wad, a które podejście ma przewagę będą się różnić w zależności od projektu i innych "miękkich" problemów, takich jak dostępna Pula talentów.

Myślę, że masz rację, że wzrost współbieżności z powodu wielordzeniowości zwiększy procent (globalnego zestawu projektów programistycznych), gdy Programowanie funkcyjne zostanie wybrane w stosunku do innych stylów.

Myślę jest to rzadkie dzisiaj, ponieważ większość dzisiejszych zawodowych puli talentów jest najbardziej komfortowe z imperatywnych i obiektowych technologii. Na przykład nie raz wybrałem Javę jako język dla komercyjnego projektu, ponieważ była wystarczająco dobra, mało kontrowersyjna i Wiem, że nigdy nie zabraknie mi ludzi, którzy potrafią w niej programować (wystarczająco dobrze).

Pomimo zalet programowania funkcyjnego, programowanie imperatywne i obiektowe nigdy nie odejdzie całkowicie.

Programowanie imperatywne i obiektowe to krok po kroku opis problemu i jego rozwiązania. Jako takie, może być łatwiejsze do zrozumienia. Programowanie funkcyjne może być nieco niejasne.

Ostatecznie, użyteczny program zawsze będzie miał skutki uboczne (jak dostarczanie rzeczywistej produkcji do użytkownika do konsumpcji), więc najczystsze funkcjonalne języki nadal będą potrzebowały sposobu, aby od czasu do czasu wkroczyć w imperatywny świat.

Obecny stan techniki polega na tym, że języki imperatywne (takie jak C#) zapożyczają funkcje ze świata funkcjonalnego (takie jak wyrażenia lambda) i odwrotnie.

Czyż nie?

Smalltalk był kiedyś świetnym systemem zorientowanym obiektowo. Dlaczego programowanie zorientowane obiektowo nie zostało przejęte? Cóż, to prawda. To nie wygląda jak Smalltalk. Główne języki stają się coraz bardziej Smalltalk - jak w C++, Java, C#, itp. Moda i styl zmieniają się wolniej niż cokolwiek innego, więc kiedy OO weszło do głównego nurtu, otrzymaliśmy to przez przyklejenie części OO do starych języków, więc wyglądało to wystarczająco jak C, aby przełknąć.

Funkcjonalność jest taka sama. Haskell był świetny język funkcjonalny. Ale mamy jeszcze większą masę mainstreamowych programistów używających składni podobnej do C niż 20 lat temu. Więc musi wyglądać jak C. Done: spójrz na dowolne wyrażenie LINQ i powiedz mi, że nie działa.

Uważam, że języki imperatywne są bardziej rozpowszechnione po prostu dlatego, że do tego przywykło więcej ludzi. Ani Programowanie funkcyjne, ani imperatywny model programowania nie są bardziej niejasne ani akademickie niż inne. W rzeczywistości są one uzupełnieniami.

Jeden z plakatów powiedział, że kod imperatywny jest łatwiejszy do zrozumienia niż kod programowania funkcyjnego. Jest to prawdą tylko wtedy, gdy czytelnik widział już kod imperatywny, zwłaszcza jeśli wcześniejsze przykłady należą do tej samej " rodziny "(dla przykład, C / C++, Perl, PHP i Java). Nie twierdzę, że to prawda dla jakiegokolwiek imperatywnego języka; weźmy porównanie Javy i Forth, aby dać Ekstremalny przykład.

Dla laika wszystkie języki programowania są nieczytelnymi bełkotami, może poza językami gadatliwymi, takimi jak Hipertalk i SQL. (Warto zauważyć, że SQL jest językiem deklaratywnym i / lub funkcjonalnym i cieszy się ogromną popularnością.)

Gdybyśmy byli początkowo szkoleni w języku Lisp-y lub Haskell-y z zacznijmy od tego, że funkcjonalne języki programowania są całkowicie normalne.

Masz już wystarczająco dużo odpowiedzi, że wspomnę tylko o kilku rzeczach, o których jeszcze nie widzę.

Po pierwsze i (moim zdaniem) przede wszystkim, języki proceduralne w znacznym stopniu skorzystały z ich stopnia podobieństwa. Na przykład, prawie każdy, kto zna prawie każdy z głównych języków proceduralnych (lub oo) do prawie dowolnego stopnia, może przeczytać większość innych dość dobrze. Aktywnie unikam pracy w Javie, C#, Cobol, Fortran, czy Basic (za kilka przykłady), ale może odczytać każdy z nich dość dobrze-prawie tak samo dobrze, jak ludzie, którzy używają ich na co dzień.

Po stronie funkcjonalnej, to jest dużo mniej prawdziwe. Na przykład, mogę napisać schemat całkiem rozsądnie, jak również, ale to jest mało przydatne w czytaniu Ocaml lub Haskell (tylko na kilka przykładów). Nawet w obrębie jednej rodziny (np. Scheme vs.Common Lisp) znajomość jednego z nich nie wydaje się przekładać prawie tak dobrze na drugi.

Twierdzenie, że kod funkcjonalny jest bardziej czytelny, wydaje się być prawdziwy tylko w wąskim zakresie warunków. Dla ludzi, którzy są bardzo zaznajomieni z językiem, czytelność jest rzeczywiście doskonała , ale dla wszystkich innych, to często obok nieistniejących. Co gorsza, podczas gdy różnice w językach proceduralnych w dużej mierze składają się ze składni i dlatego stosunkowo łatwo się uczą, różnice w językach funkcyjnych są często o wiele bardziej fundamentalne ,więc wymagają znacznych badań, aby naprawdę zrozumieć (np. małej pomocy w zrozumieniu Monad).

Innym ważnym punktem jest to, że idea, że programy funkcjonalne są krótsze niż proceduralne, często opiera się bardziej na składni niż semantyce. Programy napisane w Haskell (na przykład) są często dość krótkie, ale ich funkcjonalność jest raczej niewielką częścią tego. Wiele, jeśli jest po prostu, że Haskell ma stosunkowo zwięzłą składnię.

Niewiele czysto funkcjonalnych języków może dobrze konkurować z APL o krótki kod źródłowy (choć w uczciwość, APL wspiera tworzenie funkcji wyższego poziomu, jak również, więc nie jest to dość duża różnica, jak w niektórych innych przypadkach). W przeciwieństwie do Ada i C++ (Tylko dla kilku przykładów) mogą być dość konkurencyjne pod względem liczby operacji niezbędnych do wykonania danego zadania, ale składnia jest (przynajmniej zazwyczaj) zasadniczo bardziej zwięzła.

Brak Potrzeby

Przypominam sobie odpowiedź mojego byłego szefa Ricka Cline ' a, kiedy pokazałem mu kopię wykładu Johna Backusa z nagrody Turinga zatytułowanego czy programowanie można uwolnić od stylu von Neumanna?

Jego odpowiedź: "może niektórzy z nas nie chcąbyć wyzwoleni od stylu von Neumanna!"

Dlaczego Programowanie funkcyjne nie zostało jeszcze Przejęte?

Funkcjonalność jest lepsza dla niektórych rzeczy i gorsza dla innych, więc nigdy nie"przejmie". Jest już wszechobecny w realnym świecie.

Programy bezstanowe; brak efektów ubocznych

Bezpaństwowe programy są łatwiejsze do przetestowania. Jest to obecnie powszechnie doceniane i często wykorzystywane w przemyśle.

Współbieżność; gra niezwykle przyjemnie dzięki rosnącej technologii wielordzeniowej Programy są zwykle krótsze, a w niektórych przypadkach łatwiejsze do odczytania Wydajność wzrasta (przykład: Erlang)

Współbieżność może być wykonywana efektywnie za pomocą komunikujących się procesów sekwencyjnych (CSP). Kod wewnątrz CSP może mutować swój lokalny stan, ale wiadomości wysyłane między nimi powinny być zawsze niezmienne.

Czysto funkcjonalne programowanie gra bardzo źle z wielordzeniowym, ponieważ jest tak nieprzyjazne dla pamięci podręcznej. Rdzenie kończą się walka o pamięć współdzieloną i programy równoległe nie skalują się.

Dlaczego firmy używają lub programy napisane w językach funkcyjnych nadal są tak "rzadkie"?

Dlaczego, patrząc na zalety programowania funkcyjnego, wciąż używamy imperatywnych języków programowania?

Czysto Programowanie funkcyjne ma wiele poważnych wad, więc używamy nieczystych języków funkcyjnych, takich jak Lisp, Scheme, SML, OCaml, Scala i C#.

Kiedy myślę o tym, co programowanie funkcjonalne może wnieść do moich projektów w pracy, zawsze kieruję się tą samą ścieżką myślenia:

1. Aby uzyskać pełne zalety programowania funkcjonalnego, potrzebujesz lenistwa. Tak, istnieją ścisłe języki funkcyjne, ale prawdziwe korzyści płynące z programowania funkcyjnego nie świecą równie dobrze w ścisłym kodzie. Na przykład w Haskell łatwo jest utworzyć sekwencję leniwych operacji na liście, połączyć je i zastosować do listy. Np. op1 $ op2 $ op3 $ op4 $ someList. Wiem, że nie zbuduje całej listy i wewnętrznie po prostu zdobędę ładną pętlę, która przechodzi przez elementy po kolei. Pozwala to na pisanie naprawdę modularnego kodu. Interfejs między dwoma modułami może obejmować przekazywanie potencjalnie ogromnych struktur danych, a mimo to nie musisz mieć struktury rezydentnej.

2. Ale kiedy masz lenistwo, staje się trudne do rozumowania o użyciu pamięci. Zmiana flag kompilatora Haskell często zmienia ilość pamięci używanej przez algorytm od O(N) Do o (1), z wyjątkiem czasami, że nie. to nie jest do przyjęcia, gdy masz aplikacje, które muszą maksymalnie wykorzystać całą dostępną pamięć, i nie jest to świetne nawet dla aplikacji, które nie potrzebują całej pamięci.

Dwie rzeczy:

1. Potrzeba czasu, bez względu na to, jak dobra jest technologia.[5]} idee PR mają około 70 lat. Ale jego powszechne zastosowanie w Inżynierii Oprogramowania (w okopach, w przemyśle) wynosi prawdopodobnie mniej niż 10 lat. Poproszenie deweloperów o przyjęcie nowych, rasowo myślących zestawów jest możliwe, ale zajmuje tylko czas (wiele, wiele lat). Na przykład, OOP naprawdę dostał głównego nurtu użytkowania na początku 1980 roku. jednak nie zyskał dorminance aż do końca 1990 roku.
   
2. Ludzie muszą być zmuszeni do stawienia czoła sile technologii, zanim uderzy ona w nią mocno. Obecnie ludzie używają narzędzi, które nie nie wykorzystują równoległości i wszystko działa dobrze. Kiedy aplikacje, które nie używają równoległości, stają się nieznośnie powolne; wtedy wiele osób będzie zmuszonych do korzystania z równoległości-narzędzia i FP mogą zyskać na popularności. Może to również dotyczyć innych mocnych stron programu ramowego.