Podczas moich czterech lat na uniwersytecie korzystaliśmy z programowania funkcjonalnego w kilku funkcjonalnych językach programowania. Ale używałem również programowania zorientowanego obiektowo i faktycznie używam języków zorientowanych obiektowo, kiedy robię własny mały projekt, aby przygotować się do mojej pierwszej pracy. Ale często żałuję, że nie pisałem w funkcjonalnym języku programowania podczas tych projektów.

Jednak szukając pracy, bardzo rzadko można zobaczyć pracę, w której wymagana jest znajomość funkcjonalnego języka programowania.

Dlaczego funkcjonalne języki programowania nie są częściej używane w branży? W dzisiejszych czasach jest sporo wiadomości na temat funkcjonalnych języków programowania, więc zastanawiam się, czy programowanie funkcjonalne ma się obecnie w branży?

Powiedziałbym, że jednym z powodów, dla których programowanie funkcjonalne nie jest bardziej rozpowszechnione, jest brak bazy wiedzy. Z mojego doświadczenia wynika, że ​​korporacje są bardzo niechętne do ryzyka, jeśli chodzi o wdrażanie technologii, które nie są głównym strumieniem i wolą inwestować w wypróbowane i prawdziwe platformy (java, c ++, c #). Nowe paradygmaty są brane pod uwagę tylko wtedy, gdy istnieje potrzeba biznesowa (jak w Ericsson). Ale nawet w przypadku Ericssona słyszałem, że zarząd zażądał użycia c ++, a Joe Armstrong był zmuszony do kodowania wywołań erlang w c ++ !! To powinno pokazać, jak niechętne są korporacjom wdrażanie nowych technologii!

Byłem profesorem i, podobnie jak programiści, profesorowie zawsze szukają następnej wielkiej rzeczy. Kiedy myślą, że go znaleźli, robią z niego modę, a wszyscy się kumulują. Skoro głoszą uczniom, którzy uważają, że profesorowie muszą być naprawdę mądrzy, bo dlaczego mieliby być profesorami, nie napotykają oporu.

Programowanie funkcjonalne to takie modne. Na pewno jest wiele ciekawych pytań do zbadania i wiele ciekawych artykułów na konferencji do napisania. Nie jest to szczególnie nowy pomysł i można to zrobić w prawie każdym nowoczesnym języku, a pomysły nie muszą być nowe, aby były interesujące. To także dobra umiejętność.

Biorąc to pod uwagę, programowanie funkcjonalne to tylko jedna strzałka, którą możesz mieć w kołczanie, nie jedyna, tak jak OOP nie jest jedyną.

Moją ulubioną akademią informatyki jest brak praktycznej współpracy z przemysłem w celu ustalenia, co naprawdę ma sens w świecie rzeczywistym, tj. Kontroli jakości. Gdyby istniała ta kontrola jakości, można by położyć nacisk na klasyfikację problemów i zakres ich rozwiązań, z kompromisami, a nie tylko na najnowsze bandwagony.

Ponieważ obecnie największym problemem w tworzeniu oprogramowania jest umiejętność zarządzania złożonością. To nie jest celem większości funkcjonalnych języków programowania. Jako takie, języki, które sprawiają, że jest to priorytet (a mianowicie bardziej popularne języki OOP), mają tendencję do kradzieży niektórych fajniejszych funkcji, które pochodzą z bardziej funkcjonalnych języków akademickich, i dlatego pozostają na szczycie.

Programowanie funkcjonalne na pewno zaczyna się nadrabiać - powoli, ale na pewno.

Na przykład w tworzonym przeze mnie startupu używa się języka funkcjonalnego (Clojure) jako podstawowego języka programowania z następujących powodów:

• Produktywność - uczenie się FP jest trudne, ale kiedy już go zrozumiesz, bardzo trudno go pokonać pod względem siły i ekspresji. Prawdopodobnie piszę około 1/10 liczby linii do implementacji dowolnego elementu funkcjonalności w porównaniu do tego, czego potrzebowałbym w C # lub Javie

• Niezawodność - czyste funkcje są znacznie łatwiejsze do uzasadnienia i przetestowania niż obiekty stanowe. Dzięki temu możesz łatwiej pisać lepsze testy i sprawdzać poprawność kodu.

• Współbieżność - języki funkcjonalne kładą nacisk na niezmienność, która ma ogromne zalety dla współbieżnych aplikacji, niż konieczność efektywnego działania na wielu rdzeniach. I to się podoba, czy nie, bieganie na wielu rdzeniach to przyszłość. Zobacz http://www.infoq.com/presentations/Value-Identity-State-Rich-Hickey, aby uzyskać doskonałe wyjaśnienie, dlaczego jest to tak ważne

• Komponowalność / modułowość - języki funkcjonalne wydają się łatwiejsze do łączenia komponentów razem niż złożone systemy OO. Nadal nie odkryłem wszystkich przyczyn tego, ale część tego wynika z faktu, że nie masz całej „przypadkowej złożoności”, którą ciągną ze sobą modele OO. Wystąpienie Stuarta Hallowaya na temat radykalnej prostoty zgłębia te idee o wiele głębiej.

EDYCJA : W odpowiedzi na komentarz Despertara, przykładem „przypadkowej złożoności” systemów OOP, która ogranicza modułowość, są problemy z głębokim klonowaniem a płytkim klonowaniem: nie można komponować obiektów razem i przekazywać ich jako struktur złożonych bez bardzo dokładna analiza semantyki klonowania i mutacji. W małych przypadkach jest to możliwe do opanowania, ale w złożonych systemach szybko staje się znaczącym problemem. Ten problem nie będzie istniał, jeśli polegasz na czysto funkcjonalnych strukturach danych.

Brak aplikacji zabójcy

Hej, ten tutaj wygląda świeżo. (kopać kopać kopać)

Myślę, że większość języków programowania prosperowała dzięki „zabójczej aplikacji” - coś przekonującego, co było wyłączne dla tego języka (lub tak było postrzegane). Nie oznacza to, że cała ta absorpcja była tą aplikacją, ale doprowadziła język do większej akceptacji.

Oto mój niezbyt dokładny obraz tego, co niszę spowodowało przyjęcie niektórych języków, które mamy dzisiaj:

• C: Działa wszędzie (były to lata 70. i 80.)
• C ++: frameworki GUI (wczesne lata 90.)
• Java: aplety i serwlety (pod koniec lat 90.)
• Cel C: Aplikacje na iOS (wcześniej aplikacje na system OS X)
• Ruby: Szyny
• C #: ASP.NET, WinForms
• PHP: Wordpress itp.
• JavaScript: AJAX, szczególnie przez frameworki
• lua: Skrypty gry, zwłaszcza WoW

Poza tym wiele prawnie zastrzeżonych języków dostało się do drzwi dzięki potężnym organizacjom sprzedażowym (Oracle oraz, w mniejszym stopniu, językom Microsoft), skutecznie tworząc własną niszę.

Jedna bardzo ważna uwaga na temat tej listy: „nisza” języka, jak wskazuje aplikacja killer, staje się coraz bardziej szczegółowa w miarę upływu dziesięcioleci. Zwróć uwagę na ostatni na liście: w szczególności skrypty gry . Języki stają się coraz trudniejsze do przyciągnięcia uwagi ze względu na listę rzeczy, które są już wystarczająco dobrze wykonane przez inny język.

Tak więc to, co każdy funkcjonalny język musi naprawdę wystartować, jest niszą. W rzeczywistości nie ma jeszcze żadnych ogromnych języków funkcjonalnych, ale jest wiele w mniejszych niszach:

• Emacs Lisp: Stałe użytkowanie od lat 80. w Emacsie przez programistów. ( Rzadko używany nigdzie indziej.)
• Erlang: Wszędzie tam, gdzie chcesz wielu równoczesnych agentów.
• Program: Edukacja
• APL / J / K: Finanse (Nazwijmy je funkcjonalnymi, ze względu na argument)
• Common Lisp: „AI” - ludzie twierdzą, że jest używany, co jest błogosławieństwem i przekleństwem.

Teraz jedynym głównym językiem, który wydaje mi się pominięty w tej dyskusji, jest Python. Python zrobił coś bardzo interesującego; udało się, nie wyglądając na zwycięzcę w żadnej głównej niszy. Może to oznaczać, że całkowicie błędnie oceniam popularność języka w ten sposób. Może to również oznaczać, że wystarczająco dobry język może stać się popularny bez aplikacji typu killer, która napędza adopcję i akceptację, ale jest to bardzo trudne i może zająć bardzo dużo czasu. (Perl ma podobną historię, ale przyszedł kilka lat wcześniej i teraz jest mniej rozpowszechniony).

Z tego, co mogę powiedzieć, który funkcjonalny języki myślę są na wzrost:

• Clojure: Programowanie internetowe, szczególnie. przez Heroku
• Scala: Lift (a może Play, obecnie) - JVM bez Java

Jeśli zapytasz mnie, gdzie mam teraz szukać popularnych języków funkcjonalnych, powiedziałbym, że wypatruj języka funkcjonalnego z opracowywaniem chmury pod klucz (a la Heroku lub GAE) lub tworzeniem aplikacji mobilnych pod klucz.

Z tego samego powodu, którego Lisp nigdy tak naprawdę nie złapał (niech zaczną się flamewars!). Programowanie funkcjonalne jest bardzo obcym paradygmatem w porównaniu do programowania imperatywnego i obiektowego. Jeśli, jak większość studentów CS, zacząłeś od C i przeszedł na C ++ / Java, zwykle nie chcesz uczyć się myślenia w sposób całkowicie ortogonalny do tego, co normalnie myślisz.

Rozważmy firmy i programowanie.

Są firmy, które używają swojego oprogramowania jako strategicznego zasobu. To nie jest typowe. Dla większości firm IT jest czymś, co wspiera prawdziwy biznes firmy. To konieczny wydatek. Są konserwatywni, ponieważ wiedzą, że za X USD mogą uzyskać potrzebną im IT, a jeśli przejdą na coś innego, zaoszczędzą mniej niż X X, jeśli wszystko pójdzie dobrze, i stracą naprawdę dużą wartość, jeśli wszystko pójdzie źle.

Co więcej, w firmach najtańszą rzeczą jest zazwyczaj to, co zrobili wczoraj. Pożądana zmiana jest jednak droga. Gdyby firma zmieniła, powiedzmy, rozwiązanie C # / .NET, nawet na F #, mieliby problemy. Ich programiści (którzy prawdopodobnie nie są najostrzejszymi programistami) musieliby nauczyć się nowego języka, biegle posługiwać się obydwoma i często używać obu. Przez długi czas będą pisane procedury. Gdyby przenieśli się do czegoś takiego jak Haskell lub w pierwszej kolejności korzystali z C ++ / MFC, zmieniliby się o wiele bardziej, a to byłoby znacznie droższe.

Ponadto, przez długi czas pojawi się zapas programistów C # i ciągłe wsparcie Microsoft. Na obecne praktyki informatyczne można liczyć. Nie ma takiego samego poziomu wsparcia instytucjonalnego ani zapewnienia ciągłej dostępności programistów.

Dlatego dla większości firm zmiana programowania funkcjonalnego byłaby z góry kosztowna i zapłaci się tylko wtedy, gdy redukcja kosztów IT będzie wystarczająca w długim okresie, z wyjątkiem tego, że długi okres może być niepewny.

Już piszesz kod w funkcjonalnym stylu, po prostu go nie znasz.

Kiedy musisz wykonać testy jednostkowe kodu, masz tendencję do pisania testowalnych funkcji, które nie tworzą ani nie zależą od efektów ubocznych i zawsze zwracają ten sam wynik na tych samych argumentach (tak zwane funkcje czyste). Jest to podstawowa zaleta programów funkcjonalnych.

Myślę, że języki funkcjonalne są zbyt ograniczające. Więc zamiast zastąpienia języków imperatywnych funkcyjnymi, języki imperatywne otrzymają funkcje funkcjonalne. Obecnie prawie każdy język programowania ma zamknięcia i lambdy.

Uważam, że jest tylko jedna prawdziwa odpowiedź na twoje pytanie. Możesz znaleźć wiele powiązanych powodów, dla których tak jest, ale są to różne pytania.

Oto on:

• Architekci oprogramowania zapewniają rozwiązania, które według nich będą działać.
• Większość architektów nie pracuje w językach funkcjonalnych.
• Po wybraniu technologii i języków firmy znajdują osoby, które mogą z nimi pracować.

Czy to łapie? Wszystko zależy od tego, czy ludzie, którzy są pewni posługiwania się językami funkcjonalnymi, stają się architektami i decydują się na wykorzystanie go w projektach, nad którymi pracują.

Prawdziwym problemem jest stan.

Języki funkcjonalne nie mają stanu globalnego. Większość problemów przemysłowych wymaga stanu na dużą skalę (jak reprezentujesz księgę lub zestaw transakcji), nawet jeśli niektóre funkcje na małą skalę tak naprawdę tego nie wymagają (przetwarzanie księgi).

Ale uruchamiamy kod na maszynach architektury Von-Neuman, które są z natury pełne. Więc tak naprawdę nie pozbyliśmy się stanu, języki funkcjonalne po prostu ukrywają złożoność stanu przed deweloperem. Oznacza to, że język / kompilator musi radzić sobie ze stanem za kulisami i zarządzać nim.

Tak więc chociaż języki funkcjonalne nie mają stanu globalnego, informacje o ich stanie są przekazywane jako parametry i wynik.

Pojawia się zatem pytanie, czy język może skutecznie obsłużyć państwo stojące za zmysłem? Zwłaszcza, gdy rozmiar danych znacznie przekracza rozmiar architektury.

Patrząc na to od strony sprzętowej

System operacyjny bardzo pomógł w ciągu ostatnich kilku lat w wizualizacji przestrzeni adresowej, więc aplikacje oficjalnie nie muszą się tym martwić. Ale aplikacje, które nie martwią się, że wpadną w pułapkę wyrzucenia sprzętu, gdy presja pamięci staje się intensywna (wyrzucanie sprzętu spowalnia procesy do indeksowania).

Ponieważ programista nie ma bezpośredniej kontroli nad stanem w języku funkcjonalnym, musi polegać na kompilatorze, aby sobie z tym poradzić i nie widziałem języków funkcjonalnych, które dobrze sobie z tym radzą.

Po przeciwnej stronie monety programator z pełnym stanem ma bezpośrednią kontrolę nad stanem i może w ten sposób kompensować warunki niskiej pamięci. Chociaż nie widziałem wielu programistów, którzy są wystarczająco inteligentni, aby to zrobić.

Patrząc od strony branży:

Przemysł ma wielu nieefektywnych programistów z pełnym stanem.

Ale z czasem łatwo jest zmierzyć postępy w tych programach. Rzucasz zespołowi programistów problem, w którym mogą poprawić kod, poprawiając sposób, w jaki program obsługuje stan.

W przypadku programów funkcjonalnych ulepszenia są trudniejsze do zmierzenia, ponieważ musisz ulepszyć narzędzia, które poprawią programy (my tylko patrzymy, jak aplikacje efektywnie obsługują stan bazowy tutaj, a nie ogólną poprawę programu).

Dlatego myślę, że w przemyśle sprowadza się to do możliwości pomiaru ulepszeń w kodzie.

Z perspektywy zatrudnienia

Do wypożyczenia jest wielu programistów z pełną statystyką. Funkcjonalnych programistów trudno znaleźć. Tak więc uruchomiłby się twój podstawowy model podaży i popytu, gdyby branża przeszła na programowanie w stylu funkcjonalnym i nie jest to coś, co chcieliby się wydarzyć (programiści są wystarczająco kosztowni).

To pytanie ma nieco błędną przesłankę. Z następujących powodów:

1. Programowanie funkcjonalne jest w rzeczywistości dość powszechne w branży. Ale jest używany tylko tam, gdzie są dostępni doświadczeni programiści. Nie można oczekiwać, że początkujący to wiedzą. Korzystają z niego prawie wszystkie duże projekty programistyczne, ale utrzymują go tylko w obszarach obsługiwanych przez doświadczonych programistów. Początkujący zajmą się łatwymi modułami, które nie wymagają programowania funkcjonalnego.
2. Biorąc pod uwagę tę rzeczywistość, firmy, które zatrudniają ludzi (zwykle młodych pochodzących z uniwersytetów), tak naprawdę nie mogą prosić o funkcjonalne doświadczenie programistyczne. Każdy w projektach wymagających programowania funkcjonalnego jest już w tej samej firmie od 15 lat.
3. Uniwersytety zaczynają go uczyć, ponieważ już teraz wiedzą, że wiedza z zakresu programowania funkcjonalnego będzie bardzo przydatna za 30 lat. Ich przedział czasu wynosi 30 lat, a nie normalny pół roku jak w firmach.
4. Te punkty powodują, że ludzie rozczarowują się, gdy wchodzą na rynek pracy i widzą, że rzeczy, których nauczyli się na uniwersytecie, nie są wykorzystywane. Ale zostały zaprojektowane na 30 lat i ostatecznie będą przydatne - po prostu firmy używają prostych rzeczy - rzeczy, których ludzie mogą się spodziewać.
5. Byłbyś także arogancki, jeśli myślisz po kilku latach studiów, znasz programowanie funkcjonalne na tyle dobrze, że można je wykorzystać w rzeczywistych projektach oprogramowania. Zacznij od prostych rzeczy. Naprawdę nie musisz wykonywać najbardziej skomplikowanego oprogramowania jako pierwszego zadania na początku pracy. W końcu dotrzesz do skomplikowanych rzeczy, ale to wymaga czasu.

Ponieważ trudniej jest debugować FP.