Jakie byłyby dobre argumenty faktyczne, aby przekonać kierownictwo wysokiego szczebla do rozważenia programowania funkcjonalnego? [Zamknięte]

15

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 .

DVK
źródło
1
Chyba tego szukasz? paulgraham.com/avg.html Właściwie uważam, że artykuł jest nieco przestarzały, między wieloma funkcjonalnymi koncepcjami weszło do głównych języków.
Doc Brown
34
Dlaczego kierownictwo wysokiego szczebla powinno obchodzić, jakie języki programowania i metody są używane? Dlaczego mieliby być zaangażowani w taką decyzję? Z pewnością jest to kwestia kierowników technicznych?
High Performance Mark
8
@HighPerformanceMark: Zastąp „menedżerów technicznych” terminem „zarządzanie wysokiego szczebla” i ponownie oceń pytanie.
Robert Harvey
2
W jakiej jesteś firmie? Jeśli zajmujesz się programowaniem kontraktowym i doradztwem, programowanie funkcjonalne może być modnym słowem, które zdaniem kierownictwa zrobi wrażenie na twoich klientach.
JeffO
3
Jakie argumenty biznesowe przedstawił Ci zarząd w przypadku języków, których obecnie używasz?
JeffO

Odpowiedzi:

7

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.

Ashalynd
źródło
Jeśli potrafisz znaleźć rzeczywiste badania / dowody na poparcie tych twierdzeń - szczególnie „Języki funkcjonalne pomagają pozbyć się niektórych z tych wyzwań” - jak dotąd jest to najlepsza dostępna odpowiedź.
DVK
3
Tyle że wiele języków OOP obsługuje również programowanie funkcjonalne, więc możesz wykorzystać aspekty funkcjonalne podczas wylewania dziecka z kąpielą.
Andy,
1
Tak, pytanie dotyczyło „programowania funkcjonalnego”, a nie „języków funkcjonalnych”. Zmieni brzmienie.
Ashalynd
40

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.

Doktor Brown
źródło
7
Dziwi mnie, że 19 osób głosowało za odpowiedzią, która wcale nie odpowiada na pytanie . To praktyczne pytanie w praktycznej sytuacji. Członkowie zespołu NIE mają głosu i nie muszą być przekonani. Nie będą też działać - i ja też nie będę - nad niezatwierdzoną technologią / językiem, ponieważ pytanie stało się jasne.
DVK
1
@DVK, jeśli nikt inny nie zobaczy Twojego kodu, nie musisz nikogo przekonywać, że Twój język jest dobry. Po prostu zacznij go używać.
user253751
2
@DVK - musisz zapewnić lepszy wgląd w sposób, w jaki kierownictwo kontroluje języki używane w Twojej firmie. W większości przypadków zarząd ma niewielki wkład w tym obszarze, ponieważ pozostawia to zespołom i ich liderom.
JeffO
3
@DVK: Ludzie głosują za odpowiedzią, którą znaleźli, są najbardziej pomocni w danym pytaniu. Jeśli większość ludzi ocenia pozytywne odpowiedzi stwierdzające, że podchodzisz do niewłaściwego problemu, może to sugerować, że duża liczba programistów była w podobnych sytuacjach i uznała te „brak odpowiedzi” za pomocne. Większość zgadza się, że w Twojej firmie jest coś zasadniczo niezdrowego i nie ma to nic wspólnego z wyborem języka. Większość zgadza się, że należy to rozwiązać, każda próba pójścia bezpośrednio po wyborze języka po prostu doprowadzi cię do następnej przeszkody, a nie do szeregu rozwiązań.
Cort Ammon
1
@CortAmmon Chociaż z przyjemnością zgodzę się, że pytanie wskazuje na coś złego w sposobie zarządzania firmą pytającego, jest bardzo mało prawdopodobne, aby był w stanie naprawić takie problemy. Widziałem z pierwszej ręki problemy, które może wywołać opinia CTO (w rzeczywistości dopiero wczoraj musiałem spędzić znaczną ilość czasu na obejściu problemu spowodowanego regułą, że nasza firma nie będzie wdrażać oprogramowania poza „plikami programów” „katalogi na komputerach z systemem Windows, ale Ruby nie zainstaluje się w katalogu ze spacją w nazwie.
Jules
16

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:

  1. Dostępne są armie programistów, które potrafią pisać ryzę zwykłego kodu Java. Nie dotyczy to programistów Lisp, Haskell (a nawet Scali).
  2. Wszyscy inni używają Javy, więc musi być dobra. Corrolary: menedżerowie nie muszą uzasadniać wyboru języka Java w porównaniu do niejasnego języka, o którym nikt w strukturze poleceń nie słyszał.

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

  1. Włącz koncepcje funkcjonalne do swoich istniejących programów, jeśli są przydatne i odpowiednie,
  2. Użyj nowych funkcji języka funkcjonalnego, gdy zostaną dodane do języka, oraz
  3. Poznaj zorientowane obiektowo wzorce projektowe, z których niektóre istnieją w celu przezwyciężenia braków językowych w językach OO, które nie występują w językach funkcjonalnych.

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

Robert Harvey
źródło
1
Nie, moim celem NIE (na potrzeby tego pytania) jest „rozwój jako programista”. Moim celem jest zebranie najlepszego zestawu argumentów do przedstawienia osobom, które podejmują decyzje, które skłoniłyby ich do przyjęcia FP jako zatwierdzonego podejścia. Nic więcej i nic więcej. Podkreśl zalety FP, szczególnie w porównaniu do standardowego OOP / stosu proceduralnego.
DVK
Ponadto, chyba że popełniłem poważny błąd w sformułowaniu, pytanie zdecydowanie nie miało oznaczać „zmiany hurtowej” jako zamierzonego wyniku poszukiwanych argumentów.
DVK
+1 dla Królestwa Rzeczowników. Nazywam to „wojną między rzeczownikami a czasownikami”.
Rob
4
@DVK: Sposób na przekonanie do zarządzania czymkolwiek jest taki sam od samego początku: pokaż im, w jaki sposób zaoszczędzi im pieniądze.
Robert Harvey
9

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:

  1. Zawsze był CTO i inni ludzie wysokiego szczebla, którzy mieli doświadczenie w programowaniu funkcjonalnym i udało się go przekonać o nietechnicznym kierownictwie. (Nawiasem mówiąc, ci ludzie są lepiej wykwalifikowani, aby odpowiedzieć na twoje pytanie niż ja.)
  2. Gdy ci ludzie odejdą z firmy i zostaną zastąpieni ludźmi, którzy nie mają takiej skłonności, wszystko pójdzie na południe. Nowi faceci będą winić wszystko, co pójdzie nie tak (w tym zwłaszcza ich własne błędy) za dziwny język programowania i paradygmat użyty do zbudowania tego, co było wcześniej. Zmarginalizują pozostałych ludzi za pomocą funkcjonalnych umiejętności programowania, wypychając ich z firmy. System zbudowany na języku funkcjonalnym ulegnie pogorszeniu w stanie nieobsługiwanym. Moim zdaniem takie ryzyko jest największym ryzykiem dla firmy, jeśli przyjmą funkcjonalny język, i nie można tego lekceważyć.
  3. Aby to działało, organizacja musi mieć kulturę „buduj zamiast kupować”. Ponieważ przyjęcie funkcjonalnego języka będzie oznaczało mniej opcji „kup”.
  4. Prawie zawsze istniał pewien kompromis z technicznymi i nietechnicznymi przeciwnikami pomysłu. Najczęstszym z tych kompromisów jest to, że jakikolwiek język inny niż JVM był po prostu brany pod uwagę; Zaproponowano Clojure i Scalę, Haskell i O'Caml byli tuż obok nietoperza.
sacundim
źródło
4

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

  • Wydajność
    • Zarówno obecni, jak i przyszli pracownicy
    • Wszystkie role (architekci, programiści, testerzy, PO, ...)
  • Obsługiwane platformy
    • Systemy operacyjne (sprzęt?)
  • Wydawca języka / platformy
    • Licencje
  • Dojrzałość języka / platformy
    • Wsparcie / przez wydawcę i / lub społeczność
    • Biblioteki
  • Migracja bieżącej bazy kodu
    • Lub integracja z

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.

Eee nie
źródło
1
Firmy martwią się również o zatrudnianie ludzi, więc jeśli trudniej jest zastąpić funkcjonalnego programistę, powiedziałbym, że to dobry powód, aby zaangażować się w takie decyzje.
Andy,
1
@Andy - Tak, dlatego nie odrzucam pytania i uważam, że menedżerowie powinni być zainteresowani zadanymi przeze mnie tematami. Martwię się mniej więcej o to, że rozwiązanie (funkcjonalne języki programowania) zostanie wybrane PRZED zdefiniowaniem problemu (???).
Erno,
Czy naprawdę tak trudno jest zastąpić funkcjonalnego programistę? Pod względem liczby poinformowanych programistów, którzy publikują tutaj i na innych stronach w Internecie, podejrzewam, że jest o wiele więcej funkcjonalnych programistów, niż sądzą menedżerowie.
Giorgio
@Giorgio - Nigdy nie mówiłem, że trudno je wymienić, ale mam wrażenie, że dostępność może się różnić w zależności od lokalizacji. Niektórzy absolwenci uczelni nigdy nawet nie nauczyli się podstaw, podczas gdy niektóre uniwersytety specjalizują się w nich. W przypadku firmy bardzo ważne jest, aby spojrzeć w perspektywie długoterminowej i oczekiwanej potrzebie nowych pracowników.
Erno,
@Erno: Zgadzam się z twoim poglądem. Komentowałem komentarz Andy'ego. W każdym razie zawsze zakładałem, że jest bardzo niewielu funkcjonalnych programistów i że FP jest postrzegany jako coś ezoterycznego. Ostatnio mam wrażenie, że jest więcej programistów FP niż miejsc pracy FP.
Giorgio,
3

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:

  • Zbierz informacje od interesariuszy (zarządzanie, użytkownicy, administratorzy, sprzedaż, klienci ...)
  • Podejmuj decyzje na podstawie tych danych wejściowych
  • Komunikuj się jasno: jakie są (proponowane) decyzje; Jakie ryzyko zamierzają ograniczyć; Czym są sprzeczne interesy i z pewnym opóźnieniem: jak dobrze działały.

Jeśli pracujesz dla dużej firmy, powiedzmy ponad 10 000 pracowników, przygotuj się na następujące lekcje.

  • szybkość kodowania nie jest tak naprawdę istotna dla dolnej linii.
  • rzeczy takie jak łatwość utrzymania w skali dziesięcioleci.
  • problemy, które Twoim zdaniem można rozwiązać za pomocą języków funkcjonalnych, nie są tak naprawdę istotne dla dolnej linii
  • problemy takie jak przeszkolenie 1000 programistów, naturalna odporność na zmiany i utrzymanie bazy kodu napisanej przez programistów z mniej niż 5-letnim doświadczeniem w stosowanej technologii.

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 .

Jens Schauder
źródło
3

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:

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.

LispGood
źródło
3
Niektóre firmy idą zobaczyć to jako sprawę przeciwko, ponieważ praktyków OO przewyższa liczbę zwolenników FP przez szeroki margines .
Robert Harvey
1
@RobertHarvey - to trochę kłótnia z czerwonego śledzia, przynajmniej w moim konkretnym przypadku. Są już wystarczająco inteligentni, aby wiedzieć TO. NIE wiedzą (a dowiedziałem się z tej odpowiedzi), że Eaton Vance korzysta ze Schematu, a co ważniejsze, Faceboook , BoA / ML, Deutsche Bank i Google [użyj Haskell]. To znaczy, jest to coś, co MOŻNA rozważyć zanurzenie palca, ponieważ inni godni postanowili. Zadziwiające, że jedyną rzeczywiście przydatną odpowiedzią, która próbowała odpowiedzieć na pytanie, które zadałem (a nie tą, na którą ludzie mieli ochotę odpowiedzieć), jest ta z najmniejszą
liczbą
1
@dvk: Pytanie, które zadałeś (jeśli dobrze to rozumiem) brzmi: „Jak przekonać moich szefów, że FP to dobra rzecz?” Czasami tak nie jest. Żyjemy w zmiennym świecie, a programowanie funkcjonalne jest, szczerze mówiąc, trochę dziwne. Jeśli mi nie wierzysz, spójrz na monady. Odpowiedzi dotyczące tych osobliwości (i ich wpływu na proces projektowania i rozwoju oprogramowania) są przydatne, niezależnie od tego, czy sądzisz, że tak, czy nie.
Robert Harvey
@RobertHarvey (1) Cofam to. Teraz DWIE użyteczne odpowiedzi są najsłabiej ocenione :) (nowa, która właśnie została opublikowana, może zostać ulepszona faktami, ale to dobry początek).
DVK
@RobertHarvey - tak. Pytanie NIE brzmiało „Czy FP jest dobrą rzeczą” lub „Czy można przekonać ludzi, że FP jest dobrą rzeczą”. Pytanie było bardzo precyzyjne: „Których argumentów można użyć, aby KIEDY próbować przekonać, że to dobra rzecz”. Nie było to również „Jak mogę ukradkiem wprowadzić FP do mojej pracy / kodowania w pozytywny sposób”, na co odpowiedziałeś - gdyby to była opcja, której nie pytałbym w pierwszej kolejności, kodowałbym: )
DVK
2

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.

Anonimowy Tchórz
źródło
2
Jest to trochę pedantyczne i niezbyt pomocne w udzieleniu odpowiedzi na pytanie, które należy oderwać od samej pomocy OP w jego „podejściu”.
VF1
1

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:

var categorizedProducts = new Dictionary<string, List<Product>>();

// Get only enabled products, filtering the disabled ones, and group them by categories.
foreach (var product in this.Data.Products)
{
    if (product.IsEnabled)
    {
        if (!categorizedProducts.ContainsKey(product.Category))
        {
            // The category is missing. Create one.
            categorizedProducts.Add(product.Category, new List<Product>());
        }

        categorizedProducts[product.Category].Add(product);
    }
}

// Walk through the categories.
foreach (var productsInCategory in categorizedProducts)
{
    var minimumPrice = double.MaxValue;
    var maximumPrice = double.MinValue;

    // Walk through the products in a category to search for the maximum and minimum prices.
    foreach (var product in productsInCategory.Value)
    {
        if (product.Price < minimumPrice)
        {
            minimumPrice = product.Price;
        }

        if (product.Price > maximumPrice)
        {
            maximumPrice = product.Price;
        }
    }

    yield return new PricesPerCategory(category: productsInCategory.Key, minimum: minimumPrice, maximum: maximumPrice);
}

Ten sam kod przepisany z myślą o programowaniu funkcjonalnym:

return this.Data.Products
    .Where(product => product.IsEnabled)
    .GroupBy(product => product.Category)
    .Select(productsInCategory => new PricesPerCategory(
              category: productsInCategory.Key, 
              minimum:  productsInCategory.Value.Min(product => product.Price), 
              maximum:  productsInCategory.Value.Max(product => product.Price))
    );

Następnie zapytaj ich:

  1. Ile błędów może popełnić programista w pierwszej próbce? A co z drugim?

  2. Jak trudno jest dostrzec błędy?

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

Arseni Mourzenko
źródło
3
Widzę, co tam zrobiłeś, ale twój przykład nie jest całkowicie przekonujący. Zasadniczo rozwinąłeś swój funkcjonalny przykład w imperatywny, co nie byłoby czymś, co by się wydarzyło w praktycznych kwestiach korporacyjnych. Twój yield returnjest trochę oszustwem, ponieważ jest to przykład, w jaki sposób przygotowujesz kod do użycia w scenariuszu Linq, a twoje ifwypowiedzi 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.
Robert Harvey
@RobertHarvey Mógłbyś przekształcić pierwszy przykład w kilka funkcji imperatywnych, ale byłyby to niestandardowe funkcje imperatywne specyficzne dla tego zapytania; nadal musisz to wszystko zobaczyć, aby przekonać się, że zapytanie jest prawidłowe. Refaktoryzacja jeszcze bardziej podniosłaby rozmiar kodu imperatywnego. Nawet jeśli potrafisz napisać go równie kompaktowo, nadal musisz uważnie przeczytać kod, ponieważ cała praca odbywa się za pośrednictwem efektów ubocznych; nie chciałbyś przegapić efektu ubocznego w drugiej części trójskładnikowego operatora na końcu linii.
Doval
1
@RobertHarvey Nie jestem nawet pewien, czy dwa fragmenty kodu są równoważne, ponieważ jeden z nich „filtruje”, budując drugą listę zamiast pomijać iterację. Czy prawdziwy ekwiwalent nie używałby tylko jednej pętli, a tym samym byłby jeszcze bardziej zagnieżdżony?
Doval
5
Nie ma wątpliwości, że uzasadniasz włączenie koncepcji funkcjonalnych do języka imperatywnego / OO, ale niekoniecznie jest to dobry przypadek użycia całkowicie funkcjonalnych języków w środowisku korporacyjnym, które już jest imperative / OO.
Robert Harvey
Kolejny (być może mniej poprawny) problem z twoim przykładem: Mógłbym napisać pierwszy przykład w pełni czytelnym, głównie nie-FP Perla, w - zgaduję - 30% objętości. Może mniej. Zależy, czy akceptujesz map/ grepjako non-FP. IOW, przedstawiasz argumenty, że Java jest złym językiem, a nie, że FP jest dobrym podejściem.
DVK