Istnieje mnóstwo „teoretycznych” argumentów przemawiających za tym, dlaczego programowanie funkcjonalne jest dobrym pomysłem (zbyt wiele, aby pozostało otwartym pytaniem, i słusznie).
Jednak większość z nich to argumenty albo teoretyczne („elegancja” itp.), Albo skierowane do programistów.
Problem polega na tym, że większość z nich jest całkowicie bezużyteczna, gdy celem jest przedstawienie kierownictwu wyższego szczebla dużej firmy , z których niektórzy nawet nie są programistami, a wszyscy dbają głównie o argumenty biznesowe : koszty, zarządzanie kapitałem ludzkim , dostawa produktu, obsługa klienta i przychody; a także fakty ilościowe ponad teoriami teoretycznymi, których nie można w pełni poprzeć faktami.
Czy istnieją jakieś przekonujące argumenty do przedstawienia tych obaw biznesowych, jeśli chodzi o rozważenie przyjęcia programowania funkcjonalnego jako koncepcji (nie określonego języka), w porównaniu z typową mieszanką procedur / OOP, np. Java / C ++ / (Perl | Python) .
Najlepiej szukam argumentów, które są ilościowe i / lub oparte na badaniach lub studiach przypadków. Np. „Według tego odniesienia wskaźnik błędów systemów wielowątkowych w Lisp / F # jest o 10% wyższy niż w Javie” lub „80% absolwentów wyrażających preferencje pożądanej technologii nazwanej programowaniem funkcjonalnym jako jedna z 3 najlepszych zainteresowań”.
Wiem, że Graham przedstawił przypadki użycia programowania funkcjonalnego dla starup i byłby otwarty na niektóre z jego argumentów, zakładając, że mogą one dotyczyć większej firmy o ustalonej pozycji.
psI doskonale zdaję sobie sprawę z tego, że możesz zrobić coś blisko programowania funkcjonalnego w Perlu, prawdopodobnie w Pythonie i (prawdopodobnie) nawet w Javie 8 lub C ++ 14. Ale to nie znaczy, że organizacja używająca Perla, C ++ lub Javy poparłaby funkcjonalność vs OOP / podejścia proceduralne nawet w tych językach
Na potrzeby tego języka „duży” jest definiowany jako wystarczająco duży, aby mieć dedykowaną grupę inżynierii / narzędzi programistycznych, która określa, co wszyscy programiści mogą używać / robić; i co najmniej setki programistów na niskim poziomie .
Odpowiedzi:
Jest jeden bardzo prosty argument, który może przynajmniej rozbawić kierownictwo.
Powszechnie wiadomo, że współczesne komputery nie stają się „szybsze”, jak kiedyś, ponieważ skalowanie częstotliwości na razie przekroczyło limit. Zwiększają swoją potencjalną produktywność, dodając rdzenie.
Oznacza to, że aby najwięcej skorzystać z tej architektury, programy muszą być sparaliżowane. Jednak programowanie równoległe jest znacznie trudniejsze niż programowanie sekwencyjne, ze względu na wiele nowych wyzwań, które niesie ( obszerny przegląd znajduje się w artykule Wiki ).
Programowanie funkcjonalne pomaga pozbyć się niektórych z tych wyzwań, np. Warunki wyścigowe nie mają zastosowania, jeśli używasz niezmiennych zmiennych i metod bez skutków ubocznych. Krzywa uczenia się dla programowania funkcjonalnego jest często stroma, ale krzywa uczenia się dla programowania równoległego może być jeszcze bardziej stroma i wcale nie intuicyjna.
Jeśli więc wyzwaniem jest napisanie wydajniejszych programów w bardziej wydajny sposób, można porównać koszty szkolenia ludzi do pisania programów równoległych z kosztami szkolenia ludzi do nauki programowania funkcjonalnego, a także ryzyko, jakie może przynieść oba te podejścia.
Jeśli chodzi o języki mieszane (które obsługują zarówno funkcjonalny, jak i imperatywny styl programowania): z jednego punktu mogą być przydatne do przejścia (ludzie mogą zacząć używać ich w „znajomy” sposób i stopniowo uczyć się nowych podejść). Z innego punktu widzenia może to być ukryte błogosławieństwo, ponieważ potencjalne korzyści, jakie niesie ze sobą funkcjonalne programowanie, można skasować za pomocą niezgrabnego kodu. Można to złagodzić, ustanawiając jasne wytyczne kodowania (patrz np. „ Skuteczna Scala ” na Twitterze), choć przestrzeganie tych wytycznych wymaga pewnego poziomu dojrzałości zespołu. Z tego punktu widzenia czysto funkcjonalne języki mogą być „łatwiejsze” do tworzenia oprogramowania ze względu na surowsze reguły, które narzucają z założenia.
źródło
Podchodzisz do tego z niewłaściwej strony. W większości firm kierownictwo nie jest odpowiedzialne za „wybór paradygmatu programistycznego”, są one (a przynajmniej powinny) być odpowiedzialne za usprawnienie pracy zespołu. Jeśli cały zespół jest przekonany, że programowanie funkcjonalne poprawi szybkość lub jakość pracy, przekonanie zarządu również nie powinno być trudne. Co więcej, jeśli Twój zespół zacznie używać funkcjonalnych konstrukcji w ustalonych językach programowania i wszyscy są z tego zadowoleni, nie powinieneś nawet prosić o pozwolenie (cholera, osoba niebędąca programistą może nawet nie zrozumieć różnicy między funkcjonalne i funkcjonalne konstrukcje, więc dlaczego chcesz z nim omówić ten problem?).
Ale uwaga, jeśli reszta twojego zespołu ma inne zdanie na temat FP i zaczną narzekać na twój kod funkcjonalny, którego inni członkowie zespołu nie rozumieją, możesz mieć kłopoty z zarządzaniem - nie bez powodu, ponieważ w takim przypadku zespół traci efektywność.
Więc sednem jest: przekonać innych członków zespołu lub liderów zespołu, ale nie zarządzanie na wysokim szczeblu!
EDYCJA: z powodu twojego komentarza - w rzeczywistości jest to odpowiedź na twoje pytanie ;-). Jedynym faktycznym argumentem, o którym mówię, jest to, że „cały zespół uważa, że FP jest pomocny w wykonywaniu zadania . IMHO to argument, który ma najwyższą szansę na zaakceptowanie przez kierownictwo wyższego szczebla i jest bardzo praktyczny. Próbuje użyć argumentów technicznych osobom nietechnicznym bezpośrednio nie pracuje, nie dlatego, że są „zbyt głupie, aby zrozumieć techniczne uzasadnienie”, ale ponieważ są wystarczająco inteligentne, aby wiedzieć, że decyzje techniczne powinny być podejmowane przez ekspertów technicznych, a także są wystarczająco inteligentne, aby nie polegać na podstawie opinii tylko jednego eksperta.
źródło
Aby zrozumieć, dlaczego programowanie funkcjonalne nie zawładnęło światem, musisz zrozumieć korporacyjne myślenie za decyzjami dotyczącymi języków programowania. Aby wybrać na chwilę Java:
Jeśli Twoja organizacja jest już zakorzeniona w Królestwie Rzeczowników , wprowadzenie hurtowej zmiany w Programowaniu Funkcjonalnym po prostu nie nastąpi. Wybór języka (i wszystkie inne opcje, które go otaczają) jest już głęboko osadzony w kulturze korporacyjnej.
Zakładając, że Twoim celem jest rozwój jako programista, najlepszym rozwiązaniem jest
Argumenty Paula Grahama dotyczą tylko startupów i pojawiło się wiele ostrzeżeń o firmach, które zaczęły używać języków wyłącznie funkcjonalnych, ale potem zostały wykupione przez inną firmę, której pierwszym zleceniem była natychmiastowa konwersja bazy kodu funkcjonalnego na język OO, aby ich obecni programiści mogli go zrozumieć.
źródło
Z mojego (nieco cynicznego) doświadczenia pracowałem w sklepie, w którym korzystaliśmy z programowania funkcjonalnego, i przeprowadzałem wywiady z kilkoma innymi:
źródło
Rzeczy do rozważenia dla wyższej kadry zarządzającej, kiedy / jeśli wyższa kadra zarządzająca bierze udział w wyborze języków programowania (co jest dziwne, powinny pozostawić to zaufanym, kompetentnym ludziom (zarówno technologicznym, jak i biznesowym):
Pamiętaj, że nie są one specyficzne dla funkcjonalnych języków programowania. Nie są to również argumenty, chyba że podasz dane. Nie możemy podać danych, ponieważ całkowicie zależą one od środowiska Twojej firmy. Jedyne, co moglibyśmy zrobić, to zebrać dane z sieci, aby pokazać, ile wiedzy i zainteresowania jest w danym języku. Zachowaj ostrożność tłumacząc wiele pytań na StackOverflow lub wiele tagów na Linkedin na popularny język.
źródło
Nie sądzę, aby argumenty lub fakty pomogły. I na pewno nie bez podania problemów, które chcesz rozwiązać.
Wbrew powszechnemu przekonaniu i typowej samoocenie wiele decyzji podejmowanych jest na podstawie odczuć jelitowych. Często decyzje te są bardzo dobre, ponieważ zawierają na poziomie podświadomości duże doświadczenie jednostki podejmującej decyzję.
Jeśli chcesz zakwestionować taką decyzję, jak „Będziemy trzymać się języka C do końca wszystkich komputerów”, musisz zrobić coś więcej niż tylko podać kilka argumentów.
Pierwszym krokiem jest prawdopodobnie odkrycie osób i przyczyn decyzji, które kierownictwo wyższego szczebla powinno mieć do powiedzenia w takich decyzjach technicznych. Oczywiście mogę się tylko zgadywać, ale bardzo prawdopodobne, że mają dość udokumentowane decyzje podejmowane przez techniczne osoby, które poszły źle. Spójrzmy prawdzie w oczy: większość programistów nie jest zbyt dobra w podejmowaniu (nawet technicznych) decyzji na poziomie firmy.
Po znalezieniu tych ludzi porozmawiaj z nimi, aby zdobyć zaufanie. Być może najlepszym podejściem jest: słuchaj ich. Czym się martwią, jakie widzą ryzyko i szanse. Jakie są problemy, z którymi są kwestionowane. Stąd możesz przenieść się, aby zaangażować ludzi technologii w podejmowanie tego rodzaju decyzji. Kierownictwo często tak naprawdę nie chce podejmować takich decyzji, ale nie ufa tym innym. Więc jeśli zespół zacznie angażować się w decyzje architektoniczne i wykaże, że proponowane decyzje są rozsądne, zarządzanie może być skłonne zaufać Tobie / Twojemu zespołowi.
Ważne przy podejmowaniu właściwych decyzji architektonicznych jest:
Jeśli pracujesz dla dużej firmy, powiedzmy ponad 10 000 pracowników, przygotuj się na następujące lekcje.
Gdy osiągniesz poziom zaufania, że twoje argumenty zostaną wysłuchane i wzięte pod uwagę, ustanowisz również sposób gromadzenia i rozważania wymagań, którym ufasz Ty, Twój zespół i kierownictwo.
Jeśli w wyniku tego procesu powstanie zalecenie dotyczące zastosowania podejścia funkcjonalnego w niektórych obszarach, to już gotowe.
Jeśli w wyniku tego procesu powstanie zalecenie, aby zignorować podejścia funkcjonalne wykraczające poza to, co oferuje obecny główny język programowania, to również gotowe.
Zła wiadomość: w zależności od wielkości i stylu firmy może to zająć kilka lat lub dekad.
Dobra wiadomość: po drodze wiele się nauczysz.
Ponieważ pierwszym krokiem jest rozpoczęcie rozmowy, a zwłaszcza wysłuchanie wyższej kadry kierowniczej, polecam zacząć od przeczytania Just Listen .
źródło
Jednym dobrym podejściem byłoby wykazanie, że wykazało dobre wyniki w branży i zostało przyjęte.
Możesz uzyskać niektóre dane z:
http://www.quora.com/What-companies-use-a-functional-language-as-an-official-language
http://pchristensen.com/blog/lisp-companies/
Najlepiej, spróbuj porozmawiać z menedżerami w niektórych spółkach giełdowych, szczególnie w swojej branży, i uzyskaj od nich liczby i referencje.
Google ma wiele innych podobnych linków do Haskell, OCaml itp.
źródło
Dochodzisz do tego ze złego kierunku.
Próbujesz przekonać kierownictwo do przejścia na funkcjonalny paradygmat dla własnego rozbawienia i próbujesz zgarnąć argumenty na poparcie tego, które nie mają nic wspólnego z prawdziwym powodem, dla którego tego chcesz. W przeciwnym razie nie musisz zadawać pytania, ponieważ będziesz w stanie wymienić swoje argumenty z góry głowy.
Raczej powinieneś pomyśleć o bieżącej potrzebie biznesowej i jak najlepiej ją zaspokoić. Jeśli tak się dzieje, że najlepiej jest go podawać za pomocą funkcjonalnego paradygmatu, to - tak! - możesz zagrać. Ale jeśli przeprowadzisz rzetelną analizę, biorąc pod uwagę operacyjne potrzeby biznesowe, niezbędne szkolenie współpracowników, pochodzenie przyszłych programistów, konserwację itp., Często tak nie będzie.
źródło
Kierownictwo wyższego szczebla bez umiejętności technicznych nie powinno dbać o aspekty techniczne, takie jak stosowanie paradygmatów funkcjonalnych. To nie jest ich dziedzina wiedzy i wącha mikrozarządzanie. Dlaczego nie przekazują tych decyzji osobom, które faktycznie wymagały umiejętności?
To powiedziawszy, oto kilka wskazówek, aby przekonać ludzi z wykształceniem technicznym (pierwszy przypadek) i tych bez jednego (drugi przypadek).
Pierwszy przypadek
Jeśli rozmawiasz z ludźmi znającymi się na programowaniu , porównywanie kodu napisanego bez funkcjonalnych paradygmatów programowania i tego samego kodu napisanego w funkcjonalnym stylu może być wystarczająco przekonujące:
Przykładowy kod C #, który używa stylu imperatywnego:
Ten sam kod przepisany z myślą o programowaniu funkcjonalnym:
Następnie zapytaj ich:
Ile błędów może popełnić programista w pierwszej próbce? A co z drugim?
Jak trudno jest dostrzec błędy?
Jak trudno jest modyfikować kod?
Wszystkie trzy czynniki wpływają na produktywność, a więc i koszt produktu.
Drugi przypadek
Jeśli masz do czynienia z ludźmi, którzy nie znają programowania, nie ma wiele technicznych rzeczy, które możesz im powiedzieć. Jednym ze sposobów przekonania jest pokazanie faktycznego wpływu paradygmatów funkcjonalnych na twoją pracę i pracę twoich współpracowników.
Na przykład porównaj dwa projekty wykonane przez ten sam zespół, jeden wykorzystujący FP, a drugi nie wykorzystujący go. Pokazywanie, że liczba błędów jest znacznie mniejsza lub że był to pierwszy projekt, który firma dostarczyła na czas, powinno być wystarczająco przekonujące.
źródło
yield
return
jest trochę oszustwem, ponieważ jest to przykład, w jaki sposób przygotowujesz kod do użycia w scenariuszu Linq, a twojeif
wypowiedzi mogą być pisane bardziej zwięźle z operatorami trójskładnikowymi. Cały twój pierwszy przykład może zostać przekształcony w funkcje rozkazujące, aby złożoność była ukryta.map
/grep
jako non-FP. IOW, przedstawiasz argumenty, że Java jest złym językiem, a nie, że FP jest dobrym podejściem.