Які б були фактичні аргументи, щоб переконати керівництво високого рівня розглянути функціональне програмування? [зачинено]

Існує безліч "теоретичних" аргументів, чому функціональне програмування є хорошою ідеєю (занадто багато, щоб це не було як відкрите питання, і правильно).

Однак більшість з них є аргументами або зробленими з теорії ("елегантність" тощо), або націленими на розробників.

Проблема полягає в тому, що більшість із них є абсолютно марними, коли мета полягає в тому, щоб представити ідею вищому керівництву великої компанії , частина з яких навіть не розробники, а всі вони в основному дбають про бізнес-аргументи : вартість, управління людським капіталом. , доставка продукції, обслуговування клієнтів та дохід; а також кількісні факти над теоретичними моментами, які не можуть бути повністю підкріплені фактами.

Чи є якісь вагомі аргументи для вирішення цих проблем бізнесу щодо прийняття функціонального програмування як концепції (не будь-якої конкретної мови), порівняно з типовим поєднанням процедурних / OOP, наприклад Java / C ++ / (Perl | Python) .

Переважно, я шукаю аргументи, які є кількісними та / або ґрунтуються на дослідженнях або прикладах. Наприклад, "згідно з цим посиланням, частота помилок багатопотокових систем в Lisp / F # становить 10% від рівня Java" або "80% випускників, які висловлюють переваги потрібної технології, названої функціональним програмуванням, як на топ-3 інтересах".

Я знаю, що Грем представив випадки функціонального програмування для перешкод, і був би відкритий до деяких своїх аргументів, припускаючи, що вони можуть бути дійсними для більшої створеної компанії.

_{psI я прекрасно знаю, що ви можете зробити щось наближене до функціонального програмування в Perl, ймовірно, Python, і (можливо) навіть Java 8 або C ++ 14. Але це не означає, що організація, яка використовує Perl, C ++ або Java, буде підтримувати функціонал vs OOP / процедурні підходи навіть цими мовами}

_{Для цілей цієї мови "великий" визначається як достатньо великий, щоб мати спеціально розроблену інженерно-інструментальну групу, яка диктує, що всі розробники можуть використовувати / робити; і принаймні сотні розробників на низькому рівні} .

Є один дуже простий аргумент, який може хоча б розвеселити управління.

Добре відомо, що сучасні комп’ютери не стають «швидшими», як раніше, тому що масштабування частоти поки що досягає межі. Вони збільшують свою потенційну продуктивність, додаючи ядра.

Це означає, що, щоб отримати найбільшу користь від цієї архітектури, програми потрібно паралелізувати. Але паралельне програмування набагато складніше, ніж послідовне програмування, через багато нових викликів, які воно приносить (див. Статтю Wiki для повного огляду).

Функціональне програмування допомагає позбутися деяких із цих проблем, наприклад, умови перегонів не застосовуються, якщо ви використовуєте лише незмінні змінні та методи без побічних ефектів. Крива навчання функціонального програмування часто крута, але крива навчання для паралельного програмування може бути ще крутішою і зовсім не інтуїтивно зрозумілою.

Отже, якщо завдання полягає в тому, щоб написати більш ефективні програми більш ефективним способом, можна порівняти витрати на навчання людей, щоб писати паралельні програми, з витратами на навчання людей для вивчення функціонального програмування, і ризики, які можуть приносити обидва підходи.

Щодо змішаних мов (які підтримують як функціональний, так і імперативний стиль програмування): з одного пункту вони можуть бути зручними для переходу (люди можуть почати використовувати їх "звичним" способом і поступово вивчати нові підходи). З іншого пункту, це може бути корисним маскуванням, оскільки потенційні переваги, які приносить функціональне програмування, можуть бути скасовані чиїсь незграбним кодом. Це можна пом'якшити, встановивши чіткі вказівки щодо кодування (див., Наприклад, " Ефективна шкала " від Twitter), хоча дотримання вказівок вимагає певного рівня зрілості команди. З цієї точки зору, чисті функціональні мови можуть бути "простішими" для розробки програмного забезпечення через більш жорсткі правила, які вони встановлюють дизайном.

Ви підходите до цього з неправильної сторони. У більшості компаній керівництво не несе відповідальності за "вибір парадигми програмування", вони (або принаймні повинні бути) відповідальні за ефективність роботи команди. Якщо вся ваша команда впевнена, що функціональне програмування підвищить швидкість або якість вашої роботи, переконати керівництво теж не повинно. Більше того, якщо ваша команда тільки починає використовувати функціональні конструкції у встановлених мовах програмування, і всі задоволені цим, вам навіть не потрібно просити дозволу (чорт, непрограміст може навіть не зрозуміти різниці між не- функціональні та функціональні конструкції, так чому ви хочете обговорити це питання з ним?).

Але будьте обережні, якщо решта вашої команди має іншу думку щодо FP, і вони почнуть скаржитися на ваш функціональний код, який інші члени команди не розуміють, у вас можуть виникнути проблеми з управлінням - з поважної причини, оскільки в такому випадку У випадку випадку команда втрачає ефективність.

Отже, суть полягає в тому, щоб переконати інших членів команди або ваших керівників, але не керівництво високого рівня!

EDIT: з - за ваш коментар - на насправді, це є відповіддю на ваше запитання ;-). Єдиний фактичний аргумент, про який я говорю, - "вся команда вважає, що FP є корисною для виконання цієї роботи . ІМХО, це аргумент з найвищим шансом на те, щоб прийняти керівництво високого рівня, і це дуже практично застосовно. Намагаючись використовувати технічні аргументи для нетехнічних людей, які рідко працюють, не тому, що вони "занадто німі, щоб зрозуміти технічні міркування", а тому, що вони досить розумні, щоб знати, що технічні рішення повинні приймати технічні експерти, а також вони досить розумні, щоб не покладатися на думку лише одного експерта.

Щоб зрозуміти, чому функціональне програмування не перейняло світ, ви повинні зрозуміти корпоративне мислення, яке стоїть за рішеннями мови програмування. Щоб вибрати момент на Java:

1. Доступні армії програмістів, які можуть записувати рейки звичайного коду Java. Це не стосується програмістів Lisp або Haskell (або навіть Scala).
2. Всі інші користуються Java, тому це повинно бути добре. Корроларі: менеджерам не доводиться обґрунтовувати свій вибір Java порівняно з якоюсь незрозумілою мовою, про яку ніхто в командній структурі не чув.

Якщо ваша організація вже закріпилася в Королівстві іменників , внесення змін на функціональне програмування до оптового просто не відбудеться. Вибір мови (і всі інші варіанти, що її оточують) вже глибоко вбудований у корпоративну культуру.

Якщо припустити, що ваша мета - розвиватися як розробник програмного забезпечення, найкраще зробити це

1. Включіть у свої існуючі програми функціональні концепції там, де вони корисні та доречні,
2. Використовуйте нові функціональні функції мови, оскільки вони додаються до мови та
3. Вивчіть об'єктно-орієнтовані структури дизайну, деякі з яких існують для подолання мовних недоліків в мовах ОО, які відсутні у функціональних мовах.

Аргументи Пола Грехема дійсно стосуються лише стартапів, і існує ряд попереджувальних казок компаній, які почали використовувати суто функціональні мови, але потім їх викупила інша компанія, першим замовленням якої було негайно перетворити функціональну кодову базу до мови ОО, щоб їхні існуючі розробники програмного забезпечення могли зрозуміти це.

З мого (дещо цинічного) досвіду, працюючи в магазині, де ми використовували функціональне програмування, і брав інтерв'ю у кількох інших:

1. Завжди був КТО та інші технічні люди високого рівня, які мали досвід функціонального програмування та встигли переконати нетехнічних керівників. (І, до речі, ці люди краще кваліфікуються, щоб відповісти на ваше запитання, ніж я.)
2. Як тільки ці люди покинуть компанію і заміняться людьми, які не мають цього схильності, все піде на південь. Нові хлопці звинувачуватимуть у всьому, що піде не так (у тому числі, зокрема, у власних невдачах) у дивній мові програмування та парадигмі, що використовується для побудови того, що було раніше. Вони маргіналізуватимуть решти людей із навичками функціонального програмування, витісняючи їх із компанії. Система, побудована на функціональній мові, погіршиться без збереження. Такі речі, на мій погляд, найбільший ризик, який бере на себе бізнес, якщо він застосує функціональну мову, і його не можна недооцінювати.
3. Для цього організація повинна мати культуру "будувати замість того, щоб купувати". Тому що прийняття функціональної мови означатиме менше варіантів "купити".
4. Практично завжди був якийсь компроміс з технічними та нетехнічними зловмисниками ідеї. Найпоширеніший з цих компромісів полягає в тому, що будь-яка мова, що не є JVM, була просто поза увагою; Клуджуре та Скала були запропоновані, Хаскелл та О'Камл були просто з місця.

Що слід враховувати для вищого управління, коли / якщо вищий менеджмент бере участь у виборі мов програмування (що дивно, вони повинні залишати його довіреним, знаючим людям (як технології, так і бізнесу):

• Продуктивність
  • Як нинішні, так і майбутні співробітники
  • Усі ролі (архітектори, розробники, тестери, ОП, ...)
• Підтримувані платформи
  • Операційні системи, (апаратні засоби?)
• Видавець мови / платформи
  • Ліцензії
• Зрілість мови / платформи
  • Підтримка видавця та / або спільноти
  • Бібліотеки
• Міграція поточної бази коду
  • Або інтеграція з

Зауважте, що вони не характерні для функціональних мов програмування. Це також відсутні аргументи, якщо ви не надаєте дані. Ми не можемо надати вам дані, оскільки вони повністю залежать від середовища вашого бізнесу. Єдине, що ми могли б зробити - це зібрати дані з Інтернету, щоб показати, скільки є знань та інтересів для певної мови. Будьте уважні, перекладаючи багато питань на StackOverflow або багато тегів на Linkedin на популярну мову.

Я не думаю, що аргументи чи факти допоможуть. І точно не без вказання проблем, які ви хочете вирішити.

Проти загальної думки та типової самооцінки багато рішень приймаються на основі відчуття кишечника. І часто ці рішення є дуже хорошими рішеннями, оскільки вони включають на підсвідомому рівні великий досвід особистості, яка приймає рішення.

Якщо ви хочете оскаржити таке рішення, як-от "Ми будемо дотримуватися мови на C мові до кінця всіх комп'ютерів", ви повинні зробити більше, ніж просто навести деякі аргументи.

Перший крок - це, мабуть, розкриття осіб та причин, що стоять за рішенням, що вищестояще керівництво повинно говорити в таких технічних рішеннях. Звичайно, я можу тут лише здогадуватися, але, швидше за все, у них є досить успішний досвід рішень, прийнятих технічним персоналом, які погані. Давайте визначимось: більшість розробників не дуже добре приймають (навіть технічні) рішення на рівні компанії.

Опинившись, ці люди розмовляють з ними, щоб отримати там довіру. Можливо, найкращий підхід: слухайте їх. Що їх хвилює, який ризик та шанси вони бачать. Які проблеми вони стикаються. Звідси ви можете рухатися, щоб залучити людей до технологій прийняття такого рішення. Керівництво часто не дуже хоче приймати ці рішення, але не довіряє цим іншим. Тож якщо ваша команда почне брати участь у архітектурних рішеннях і продемонструє, що запропоновані вами рішення є надійним управлінням, можливо, будете готові довіряти вам / вашій команді.

Важливим для створення обгрунтованих архітектурних рішень є:

• Зберіть дані від власників акцій (менеджмент, користувачі, адміністратори, продажі, клієнти ...)
• Базові рішення на цьому вході
• Чітко повідомляйте: що таке (запропоновані) рішення; Який ризик вони спрямовані на зменшення; Які конфліктні інтереси є і з деяким запізненням: наскільки добре вони працювали.

Якщо ви працюєте у великій компанії зі штатними співробітниками 10K +, будьте готові вивчити деякі наступні уроки.

• Швидкість кодування насправді не має значення для нижнього рядка.
• такі речі, як ремонтопридатність в масштабах десятиліть.
• проблеми, які, на вашу думку, можна вирішити за допомогою функціональних мов, насправді не актуальні для нижнього рядка
• такі проблеми, як підготовка 1000 розробників, природна стійкість до змін та підтримання кодової бази, написані розробниками, які мають менше 5-річного досвіду використання використовуваних технологій.

Як тільки ви досягли рівня довіри, що ваші аргументи будуть почуті та розглянуті, ви також створили спосіб збору та розгляду вимог, яким ви, ваша команда та керівництво довіряєте.

Якщо цей процес дає рекомендацію використовувати функціональний підхід у певних сферах, які ви закінчили.

Якщо цей процес дає рекомендацію ігнорувати функціональні підходи, що виходять за рамки того, що пропонує поточна основна мова програмування, ви також зробите.

Погані новини: Залежно від розміру та стилю компанії, це може зайняти пару років чи десятиліть.

Хороша новина: Ви багато чого навчитеся в дорозі.

Оскільки перший крок - почати розмову і особливо слухати вищий менеджмент, я б рекомендував почати з читання Just Listen .

Хорошим підходом було б показати, що це показало хороші результати в галузі та прийнято.

Ви можете отримати деякі дані з:

• http://www.quora.com/What-companies-use-a-functional-language-as-an-official-language

• http://pchristensen.com/blog/lisp-companies/

В ідеалі спробуйте поговорити з менеджерами деяких компаній, що перераховуються, особливо якщо у вашій галузі, і отримуйте від них номери та відгуки.

У Google є багато інших подібних посилань для Haskell, OCaml тощо.

Ви йдете на це з неправильного напрямку.

Ви намагаєтесь переконати управління перейти на функціональну парадигму для власного розваги, і ви намагаєтесь розігратися в аргументах, щоб підтримати це, що не має нічого спільного з реальною причиною, чому ви цього хочете. В іншому випадку вам не потрібно буде ставити це запитання, оскільки ви зможете перерахувати свої аргументи вгорі голови.

Швидше, про що ви повинні думати - це те, що потрібно поточному бізнесу та як його найкраще обслуговувати. Якщо так сталося, що найкраще його використовувати за допомогою функціональної парадигми, то - так! - ти граєш. Але якщо ви будете робити чесний аналіз, враховуючи операційні потреби бізнесу, необхідну підготовку колег, досвід майбутніх програмістів, технічне обслуговування тощо, часто цього не буде.

Старший керівник, який не має технічних навичок, не повинен дбати про технічні аспекти, такі як використання функціональних парадигм. Це не їх сфера досвіду, і пахне мікроменеджментом. Чому вони не делегують ці рішення особам, які насправді мають необхідні навички?

Якщо говорити, ось деякі підказки, щоб переконати людей з технічним досвідом (перший випадок) та людей без одного (другий випадок).

Перший випадок

Якщо ви розмовляєте з людьми, які знають програмування , порівняння коду, написаного без функціональних парадигм програмування, і того ж коду, написаного у функціональному стилі, може бути досить переконливим:

Зразок коду C #, в якому використовується імперативний стиль:

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);
}

Цей же код переписаний з функціональним програмуванням на увазі:

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

Тоді запитайте їх:

1. Скільки помилок може допустити програміст у першому зразку? А як щодо другого?

2. Наскільки важко виявити помилки?

3. Наскільки складно змінити код?

Усі три фактори впливають на продуктивність, а значить, і вартість продукту.

Другий випадок

Якщо ви маєте справу з людьми, які не знають програмування, ви не можете їм сказати багато технічних речей. Один із способів бути переконливим - показати фактичний вплив функціональних парадигм на вашу роботу та роботу ваших колег.

Наприклад, порівняйте два проекти, зроблені однією командою, один використовує FP, а інший не використовує. Показати, що кількість помилок значно менша або що це був перший проект, який компанія фактично доставила вчасно, має бути досить переконливим.