Dlaczego programowanie funkcjonalne nie jest bardziej popularne w branży? Czy to się teraz przydarza? [Zamknięte]

61

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?

Jonas
źródło
3
W pewnym stopniu nie zgadzam się z przesłanką twojego pytania. Funkcje językowe inspirowane „językami funkcjonalnymi” są dodawane do języków takich jak Java i JavaScript. W rzeczywistości JavaScript zawsze był (pod pewnymi względami) językiem funkcjonalnym, choć wiele osób nie zdawało sobie z tego sprawy do niedawna.
MatrixFrog,
1
@MatrixFrog: Można by zapytać „Po co funkcjonować tylko w połowie, dodając kilka funkcjonalnych koncepcji do języków niefunkcjonalnych zamiast przyjmować pełnoprawny język FP? Po tym wszystkim paradygmat istnieje już od wielu lat i jest bardzo dojrzały”.
Giorgio
świat nie przełącza się na lepsze alternatywy (a czysty FP jest lepszą alternatywą) z różnych powodów, w tym kompatybilności wstecznej, bezwładności itp. Zastanów się nad układem klawiatury DVORAK: jest bardziej wydajny w pisaniu dotykowym, ale wszyscy utknęliśmy w QWERTY po prostu dlatego, że jest tak dużo oprogramowania za pomocą skrótów przyjaznych qwerty.
KolA

Odpowiedzi:

38

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!

ennuikiller
źródło
9
W jaki sposób programowanie funkcjonalne jest w jakikolwiek sposób „nowe”?
Evan Plaice,
7
Myślę, że miał na myśli „nieużywany” zamiast „nowy”.
Vinko Vrsalovic,
9
Więc nie jest używany ... ponieważ nie jest używany? Hm
Alex Baranosky
21
@Alex - Dokładnie. Do bani, prawda?
KeithS
5
@ Stargazer712: Jakie są te powody? Znam wielu programistów, którzy nie znają programowania funkcjonalnego, więc ignorancja ma dla mnie sens. Czy w przeszłości programowanie funkcjonalne miało poważną awarię, która odstraszyła branżę, o której nie jestem świadomy?
Sean McMillan
67

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.

Mike Dunlavey
źródło
1
To jest naprawdę dobry komentarz. +1 do strzał w kołczanie i zakresów rozwiązań z kompromisami.
user21007,
2
+1 za kontrolę jakości. Ten mgr byłby o wiele bardziej przydatny z dedykowanymi przedmiotami obejmującymi testowanie, przegląd kodu, złożoność kodu i podobne. Możliwość automatycznej weryfikacji , czy program robi to, co powinien po ostatniej łatce, jest warta dowolnej liczby „powinno działać teraz”, falistego bełkotu.
l0b0
5
@ l0b0: Dzięki, chociaż tak naprawdę myślałem o kontroli jakości tego, czego się uczy i jak. W tej chwili profesorowie CS tylko uczą tego, co według nich jest najbardziej interesujące. Porównaj to z inżynierią, w której istnieje związek z przemysłem lub medycyną, gdzie rzeczywiste znaczenie jest bardzo duże. IME, profesorowie CS uważają, że prawdziwy świat będzie nauczał tego, co ważne w prawdziwym świecie, ale studenci nie przychodzą chętnie się uczyć - raczej chętnie prozelityzmują to, co najbardziej podekscytowali profesorowie.
Mike Dunlavey,
@ Mike: prawie jakikolwiek współczesny język? Czy w tym C ++ i Java?
kevin cline
+1. Nie mógłbym tego lepiej powiedzieć.
riwalk 30.09.11
25

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.

Fishtoaster
źródło
48
Nie zgadzam się. Funkcjonalne języki programowania starają się zminimalizować użycie stanu i przez to stają się mniej skomplikowane. Programy zaprogramowane w języku funkcjonalnym są również łatwiejsze do testowania i refaktoryzacji.
Jonas
7
@Jonas: wielu programistom bardzo trudno jest napisać program bez prawie żadnego stanu (w tym ja). Z tego punktu widzenia jest to w rzeczywistości bardziej skomplikowane. (Należy pamiętać, że nie dyskutuję o przydatności programowania funkcjonalnego w jakikolwiek sposób!)
ShdNx
3
@ShdNx: Tak, wiem. Nawet myślałem, że programowanie funkcjonalne było trudne, kiedy po raz pierwszy nauczyłem się go na uniwersytecie. Ale po pewnym czasie zacząłem preferować programowanie imperatywne i bardziej szczegółowe OOP. Na moim uniwersytecie nauczano programowania funkcjonalnego przed programowaniem imperatywnym, a studenci, którzy nie wykonywali żadnego programowania zanim uniwersytet pomyślał, że programowanie imperatywne było bardzo trudne na początku i że programowanie funkcjonalne było bliższe matematyce.
Jonas
16
Istnieje różnica między trudnością a złożonością. OOP jest zdecydowanie trudniejszy niż programowanie strukturalne, ponieważ dodaje więcej pojęć. W przypadku wystarczająco dużych ilości kodu zmniejszają złożoność, zapewniając strukturę kodu. FP to to samo: jeśli piszesz tylko dwa wiersze, wydaje się, że to przesada, ale jeśli twój kod jest wystarczająco duży, wówczas struktura kodu jako bezstanowe podjednostki poprawia skalowalność i zmniejsza złożoność kodu.
Muhammad Alkarouri
6
Jednym z głównych elementów programowania funkcjonalnego jest kompozycyjność. Jeśli to nie jest narzędzie do zarządzania złożonością, nie wiem, co to jest.
dan_waterworth
23

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.

mikera
źródło
+1, byłbym bardzo zainteresowany usłyszeniem twojego procesu decyzyjnego dotyczącego tego, dlaczego wybrałeś Clojure. (Nie jestem za lub przeciw Clojure, jestem po prostu zainteresowany).
dan_waterworth
4
„uczenie się FP jest trudne”: Uczenie się każdego paradygmatu jest trudne. Pamiętam, ile godzin spędziłem z kodem rozkazującym (Pascal), zanim miałem wystarczająco dużo doświadczenia, aby być wystarczająco produktywnym. Myślę, że FP jest mniej znany, ponieważ wielu programistów najpierw nauczyło się języka imperatywnego, a kiedy nauczyli się programować, nie mieli czasu spojrzeć na coś innego. Jestem pełnoetatowym programistą C ++ i obecnie uczę się Scali wieczorem po pracy. Gdybym miał rodzinę do opieki, mógłbym po prostu o tym zapomnieć.
Giorgio
1
Myślę, że pierwsze 3 to świetne przypadki, jednak nie zgadzam się z czwartym. OOP jest niezwykle modułowy i kompozycyjny; dla mnie jest to jedna z jego największych zalet. Świetnie nadaje się także do ukrywania złożoności poprzez enkapsulację i abstrakcję.
Despertar,
1
@Giorgio. Dokładnie. „Nauka FP jest trudna, nauka OOP jest łatwa” jest równie absurdalna jak „Nauka hiszpańskiego jest trudna, ale chiński jest łatwy”. To zależy, który był twoim pierwszym językiem. I nie wybrałem chińskiego jako arbitralnego odpowiednika OOP - ponieważ idiomy OO są jak hieroglify: łatwe do nauczenia się jeden po drugim, ale trudne do zapamiętania je wszystkie i niemożliwe do skomponowania. FP jest bardziej podobny do języka z alfabetem: oddzielne litery są bezużyteczne w oderwaniu, ale pozwalają na komponowanie wszystkiego z rozsądnie małym zbiorem reguł
KolA
1
(ciąg dalszy) więc dlaczego nie jest popularny - jeszcze - z tych samych powodów. Hieroglify istniały na długo przed wynalezieniem i dojrzewaniem pierwszego alfabetu. Może to potrwać kolejne pokolenie, które ma alfabetyczne pisanie i czytanie Mam na myśli FP jako ich pierwszy paradygmat
KolA
12

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

Jesse Millikan
źródło
Uważałbym również Perla za główny język. Powiedziałbym, że jest to starszy język, który jest najczęściej używany w systemach uniksopodobnych. Chociaż Python wydaje się być bardziej nowoczesną alternatywą. Jest to nadal popularny język, który zyskał wiele uwagi i ma dużą społeczność.
Despertar,
1
@Despertar - nie bardzo starałem się być egalitarny w kwestii języków, o których wspomniałem :) I zgodziłem się, że historia przypomina Pythona, z wyjątkiem kilku lat w przeszłości.
Jesse Millikan
1
Perl nie mieć kilka nisz. Najwcześniejsza z nich znalazła odzwierciedlenie w starszych wersjach dokumentacji, która odnosiła się do nazwy jako akronimu „praktycznego języka ekstrakcji i raportowania”. Drugi przyszedł trochę później i był skryptów CGI - przez wiele lat, Perl był językiem w internecie. Oczywiście straciło to obecnie dużą popularność, ale spójrz na stare strony internetowe, które nadal działają na tym samym oprogramowaniu, z którego zostały pierwotnie zbudowane, i zobaczysz dużo perla (myślę o slashdot.org, teraz , ale jest ich jeszcze kilka).
Jules
8

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.

Chinmay Kanchi
źródło
2
Obcy paradygmat? Jest bliżej matematyki niż programowania imperatywnego. Tutaj, w Szwecji, myślę, że większość studentów CS na uniwersytecie jest najpierw programowaniem funkcjonalnym. Np. Zaczynaliśmy od Standard ML, przed C, Erlang i Java.
Jonas
4
Słusznie. Wiem, że wielu studentów inżynierii w Wielkiej Brytanii i Indiach uczy się najpierw języka C, a następnie C ++ i / lub Java. Często nie uczy się ich wcale języka funkcjonalnego.
Chinmay Kanchi,
13
@Jonas Dla wielu ludzi matematyka jest paradygmatem obcych i wszystko, co odsuwa programowanie od matematyki, ułatwia zrozumienie.
scriptocalypse
5
Słyszałem o ludziach, którzy nigdy nie słyszeli o drzewach, nie mówiąc już o programowaniu funkcji, po ukończeniu studiów.
dan_waterworth,
1
@ Tux-D, właściwie nie, mówię o studentach w Wielkiej Brytanii.
dan_waterworth
6

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.

David Thornley
źródło
2

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.

Calmarius
źródło
1

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

John Fisher
źródło
0

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

Martin York
źródło
2
Języki funkcjonalne, zwłaszcza „nieczyste” języki funkcjonalne, doskonale radzą sobie ze stanem globalnym. Uważam, że często programy rozkładają się na naprzemienne warstwy: np. Stan globalny ... ale przejścia stanu funkcjonalnego ... ze sporadycznymi stanami lokalnymi (zamaskowanymi) w celu implementacji krytycznych pod względem wydajności części tych przejść itp. Problem z imperatywnymi językami, IMO polega na tym, że często prowadzą programistów do niewłaściwego używania stanu, gdy wzorce funkcjonalne działałyby lepiej. Ale języki wydają się ewoluować w kierunku dobrego wspierania obu stylów.
Ryan Culpepper
1
Bardzo łatwo radzić sobie ze stanem w językach funkcjonalnych, ale wymaga to przesunięcia nacisku. Podczas gdy w językach imperatywnych piszesz procedury modyfikujące stan, w językach funkcjonalnych piszesz funkcje zwracające procedury modyfikujące stan.
dan_waterworth
„Języki funkcjonalne nie mają stanu globalnego” - Nie potrzebujesz stanu globalnego. Prawie całe zarządzanie stanem można wykonać za pomocą monad.
Arunav Sanyal
-3

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.
tp1
źródło
2
1) „korzysta z niego prawie wszystkie duże projekty programistyczne”. Z mojego doświadczenia wynika, że ​​jest to dalekie od rzeczywistości. Bardzo niewiele firm korzysta z programowania funkcjonalnego, co wiem. Większość używa tylko Java i C # (mimo że C # ma bardziej funkcjonalne konstrukcje w ciągu ostatnich kilku lat), C ++ i C.
Jonas
2
2) Moje doświadczenie jest odwrotne. Wydaje się, że tylko ludzie z uniwersytetów znają programowanie funkcjonalne. Tutaj w Szwecji większość uniwersytetów uczy programowania funkcjonalnego od pierwszego roku. A uniwersytety takie jak MIT do niedawna stosowały programowanie funkcjonalne w swoim pierwszym kursie programowania (Schemat).
Jonas
@jonas: nie, język programowania nie ma z tym nic wspólnego. Oczywiście C i C ++ oraz Java itp. Są używane przez dużą liczbę projektów. Programowanie funkcjonalne działa również w kodzie c ++. Wydaje się, że obecna praktyka polega na tym, że część projektu wykorzystuje OO, a część wykorzystuje programowanie funkcjonalne. Obie części używają tego samego języka (zwykle c / c ++)
tp1
Tak, możesz zrobić OO również w C. Ale nie jest to zalecane. C i C ++ nie mają wielu konstrukcji do programowania funkcjonalnego, np. Nie są domyślnie niezmienne, brak dobrego wsparcia dla dopasowywania wzorców, brak niezmiennych struktur danych i tak dalej ...
Jonas
Właśnie dlatego wymaga doświadczonych programistów. Ponieważ zmiana języka programowania z głównego nurtu jest prawie niemożliwa, następną najlepszą rzeczą jest wykonanie programowania funkcjonalnego w c ++. Również c ++ ma takie rzeczy jak const, które bardzo pomagają.
tp1
-10

Ponieważ trudniej jest debugować FP.

interstar
źródło
11
Nie zgadzam się. Bez efektów ubocznych proces debugowania jest łatwiejszy. Może uważasz, że jest trudniej, ponieważ paradygmat funkcjonalny jest inny i wymaga doświadczenia, aby poczuć się komfortowo z nowym sposobem wykonywania zadań, w tym debugowaniem.
Maniero,
2
Funkcjonalne języki programowania są w rzeczywistości łatwiejsze do przetestowania, ponieważ czyste funkcje są bezstanowe.
Jonas
4
Jonas, nie powiedziałem „test”, powiedziałem „debugowanie” tj. znajdź błąd, który popełniłeś. Testowanie jest częścią tego, ale rozumowanie na temat programu itp. Bigown - stoję przy tym. Jest to funkcja siły FP. Im więcej pracy wykonuje dany wiersz kodu, tym trudniej jest zobaczyć, który wiersz kodu powoduje problem. Mapowanie między wierszem kodu a efektem jest bardziej rozproszone, np. pojedyncza funkcja wyższego rzędu może dotykać dziesiątek zachowań programu i odwrotnie. Objawy mogą się znacznie różnić między różnymi punktami dla tego samego błędu.
interstar
Z mojego doświadczenia wcale nie jest trudno debugować. Korzystam z F # i nie mogę znaleźć żadnego powodu, dla którego byłoby ci trudniej debugować niż na przykład C #. Może debugowanie jest trudniejsze w Haskell z powodu lenistwa (nie mam pojęcia), ale chętne programowanie FP jest prostsze z powodu bezpaństwowości, jak powiedział Jonas. Innymi słowy, kod FP jest bardziej przewidywalny, ponieważ wiesz, że na wynik nie mają wpływu niewidoczne zmienne.
Muhammad Alkarouri
2
Dopóki twoje funkcje są czyste, debugowanie jest łatwe. Jeśli nie możesz debugować poprzez dodanie testów jednostkowych, oznacza to, że nie wykonujesz odpowiedniej pracy pisania testów.
dan_waterworth