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

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

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.

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.

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

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.

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.

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 .

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.

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.

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.