Какие были бы хорошие фактические аргументы, чтобы убедить руководство высокого уровня рассмотреть функциональное программирование? [закрыто]

Существует множество «теоретических» аргументов в пользу того, почему функциональное программирование является хорошей идеей (слишком много, чтобы это оставалось открытым вопросом, и это правильно).

Тем не менее, большинство из них являются аргументами, основанными либо на теории («элегантность» и т. Д.), Либо нацеленными на разработчиков.

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

Существуют ли убедительные аргументы для решения этих бизнес-задач, если принять во внимание принятие функционального программирования в качестве концепции (не какого-либо конкретного языка), в отличие от типичного сочетания процедурного / ООП, например, Java / C ++ / (Perl | Python) ,

Предпочтительно, я ищу аргументы, которые являются количественными и / или основанными на исследовании или тематических исследованиях. Например, «согласно этой ссылке, уровень ошибок многопоточных систем в Lisp / F # составляет 10% от уровня Java» или «80% выпускников высших учебных заведений выражают предпочтения желаемой технологии, называемой функциональным программированием как одной из трех основных интересов».

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

_{PS Я прекрасно понимаю, что вы можете сделать что-то близкое к функциональному программированию на Perl, вероятно, на Python, и (возможно) даже на Java 8 или C ++ 14. Но это не значит, что организация, использующая Perl, C ++ или Java, поддержит функционал против ООП / процедурные подходы даже на этих языках}

_{Для целей этого языка «большой» определяется как достаточно большой, чтобы иметь специальную группу разработки / инструментов разработки, которая определяет, что всем разработчикам разрешено использовать / делать; и по крайней мере сотни разработчиков на низком уровне} .

Есть один очень простой аргумент, который может по крайней мере позабавить руководство.

Хорошо известно, что современные компьютеры не становятся «более быстрыми», как раньше, потому что масштабирование частоты пока что достигает предела. Они увеличивают свою потенциальную производительность, добавляя ядра.

Это подразумевает, что для получения максимальной выгоды от этой архитектуры программы должны быть распараллелены. Но параллельное программирование намного сложнее, чем последовательное программирование, из-за множества новых проблем, с которыми оно связано (обратитесь к статье Wiki для всестороннего обзора).

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

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

Что касается смешанных языков (которые поддерживают как функциональный, так и императивный стиль программирования): с одной стороны, они могут быть полезны для перехода (люди могут начать использовать их «знакомым» способом и постепенно изучать новые подходы). С другой стороны, это может быть скрытым благословением, потому что потенциальные преимущества, которые дает функциональное программирование, могут быть отменены чьим-то неуклюжим кодом. Можно смягчить это, установив четкие руководящие принципы кодирования (см., Например, « Эффективная Scala » в Твиттере), хотя соблюдение руководящих принципов требует определенного уровня зрелости команды. С этой точки зрения, чисто функциональные языки могут быть «проще» для разработки программного обеспечения из-за более строгих правил, которые они навязывают при разработке.

Вы подходите к этому не с той стороны. В большинстве компаний руководство не несет ответственности за «выбор парадигмы программирования», оно отвечает (или, по крайней мере, должно) отвечать за эффективность работы команды. Если вся ваша команда убеждена, что функциональное программирование улучшит скорость или качество вашей работы, убедить руководство не должно быть слишком сложно. Более того, если ваша команда только начинает использовать функциональные конструкции в ваших установленных языках программирования, и все довольны этим, вам даже не нужно спрашивать разрешения (черт, непрограммист может даже не понимать разницу между функциональные и функциональные конструкции, так почему вы хотите обсудить этот вопрос с ним?).

Но будьте осторожны, если остальная часть вашей команды имеет другое мнение о FP, и они начинают жаловаться на ваш функциональный код, который другие члены команды не понимают, вы можете столкнуться с проблемами в управлении - по уважительной причине, так как в таком случае В этом случае команда теряет эффективность.

Итак, суть в том, чтобы убедить других членов команды или руководителей вашей команды, но не руководство высокого уровня!

EDIT: из - за ваш комментарий - на самом деле, это является ответом на ваш вопрос ;-). Один фактический аргумент, о котором я говорю, заключается в том, что «вся команда считает, что FP полезен для выполнения работы . ИМХО, это аргумент с наибольшей вероятностью быть принятым руководством высшего звена, и он практически применим. Попытка использовать технические аргументы непосредственно для нетехнических людей редко работает, не потому что они «слишком тупы, чтобы понимать технические аргументы», а потому что они достаточно умны, чтобы знать, что технические решения должны приниматься техническими экспертами, и они также достаточно умны, чтобы не полагаться по мнению только одного эксперта.

Чтобы понять, почему функциональное программирование не завоевало мир, вы должны понять корпоративное мышление, стоящее за решениями о языке программирования. Чтобы выбрать на Java на мгновение:

1. Доступно множество программистов, которые могут писать группы обычного Java-кода. Это не относится к программистам на Лиспе, Хаскеле (или даже Скале).
2. Все остальные используют Java, так что это должно быть хорошо. Следствие: менеджерам не нужно оправдывать свой выбор Java по сравнению с каким-то непонятным языком, о котором никто в командной структуре никогда не слышал.

Если ваша организация уже укоренилась в Царстве Существительных , массовых изменений в функциональном программировании просто не произойдет. Выбор языка (и всех других вариантов, которые его окружают) уже глубоко укоренился в корпоративной культуре.

Предполагая, что ваша цель - стать разработчиком программного обеспечения, лучше всего

1. Включите функциональные концепции в ваши существующие программы там, где они полезны и уместны,
2. Используйте новые функциональные языковые функции по мере их добавления к языку и
3. Изучите объектно-ориентированные шаблоны проектирования, некоторые из которых существуют для преодоления языковых недостатков в ОО-языках, которых нет в функциональных языках.

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

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

1. Всегда был технический директор и другие технические специалисты высокого уровня, которые имели опыт функционального программирования и сумели убедить в этом нетехнических руководителей. (И, кстати, эти люди лучше подготовлены, чтобы ответить на ваш вопрос, чем я.)
2. Как только эти люди покинут компанию и будут заменены людьми, у которых нет этой склонности, дела пойдут на юг. Новые парни будут обвинять все, что идет не так (включая, в частности, их собственные ошибки) в странном языке программирования и парадигме, использованной для построения того, что было раньше. Они будут изолировать оставшихся людей с функциональными навыками программирования, вытесняя их из компании. Система, построенная на функциональном языке, будет ухудшаться без обслуживания. Подобные вещи, на мой взгляд, представляют собой самый большой риск для бизнеса, если они принимают функциональный язык, и его нельзя недооценивать.
3. Организация должна иметь культуру «строи, а не покупай», чтобы это работало. Потому что принятие функционального языка будет означать меньше вариантов «купить».
4. Почти всегда был какой-то компромисс с техническими и нетехническими противниками идеи. Наиболее распространенным из этих компромиссов является то, что любой язык, не относящийся к JVM, просто не учитывался; Были предложены Clojure и Scala, Хаскелл и О'Камл были только что уволены.

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

• производительность
  • Как нынешние, так и будущие сотрудники
  • Все роли (архитекторы, разработчики, тестировщики, ОП, ...)
• Поддерживаемые платформы
  • Операционные системы (аппаратные средства?)
• Издатель языка / платформы
  • Лицензии
• Зрелость языка / платформы
  • Поддержка издателя и / или сообщества
  • Библиотеки
• Перенос текущей кодовой базы
  • Или интеграция с

Обратите внимание, что они не являются специфическими для функциональных языков программирования. Это также не аргументы, если вы не предоставите данные с ними. Мы не можем предоставить вам данные, так как они полностью зависят от среды вашего бизнеса. Единственное, что мы можем сделать, это собрать данные из Интернета, чтобы показать, насколько много знаний и интереса есть к конкретному языку. Будьте внимательны при переводе многих вопросов в StackOverflow или множества тегов в Linkedin на популярный язык.

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

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

Если вы хотите оспорить такое решение, как «Мы ​​будем придерживаться языка, подобного C, до конца всех компьютеров», вам нужно сделать больше, чем просто предоставить некоторые аргументы.

Первый шаг, вероятно, состоит в том, чтобы раскрыть лиц и причины решения о том, что высшее руководство должно иметь высказывание в таких технических решениях. Конечно, я могу только догадываться здесь, но весьма вероятно, что у них есть достаточно послужной список решений, принятых техническими сотрудниками, которые пошли плохо. Посмотрим правде в глаза: большинство разработчиков не очень хорошо принимают (даже технические) решения на уровне компании.

Как только вы нашли этих людей, поговорите с ними, чтобы завоевать там доверие. Возможно, лучший подход - слушать их. Что их беспокоит, какой риск и шансы они видят. С какими проблемами они сталкиваются. Отсюда вы можете перейти к тому, чтобы привлечь технологов к такому решению. Менеджмент часто не хочет принимать эти решения, но не доверяет другим. Поэтому, если ваша команда начинает принимать участие в архитектурном решении и демонстрирует, что решения, которые вы предлагаете, являются разумным руководством, возможно, захотите довериться вам / вашей команде.

Для того, чтобы придумать правильные архитектурные решения, важно:

• Сбор информации от заинтересованных сторон (менеджмент, пользователи, администраторы, продажи, клиенты ...)
• Основывать решения на этом вкладе
• Сообщите четко: каковы (предлагаемые) решения; Какой риск они стремятся смягчить; Какие конфликтующие интересы и с некоторой задержкой: насколько хорошо они работали.

Если вы работаете в крупной компании со штатом от 10 тыс. Человек, будьте готовы выучить некоторые из следующих уроков.

• скорость кодирования не очень важна для итогов.
• такие вещи, как ремонтопригодность в масштабе десятилетий.
• проблемы, которые, по вашему мнению, можно решить с помощью функциональных языков, на самом деле не актуальны
• такие проблемы, как обучение 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, а другой не использует. Показывать, что количество ошибок намного ниже, или что это был первый проект, который компания выполнила вовремя, должно быть достаточно убедительно.