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

15

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

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

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

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

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

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

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

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

DVK
источник
1
Вы ищете это, я полагаю? paulgraham.com/avg.html На самом деле, я думаю, что статья немного устарела, между многими функциональными концепциями вошли в основные языки.
Док Браун
34
Почему высокоуровневому управлению наплевать, какие языки программирования и методы используются? Зачем им участвовать в таком решении? Конечно, это вопрос для технических менеджеров?
Высокая производительность Mark
8
@HighPerformanceMark: замените «технических менеджеров» на «менеджмент высокого уровня» и снова оцените вопрос.
Роберт Харви
2
Чем вы занимаетесь? Если вы занимаетесь контрактным программированием и консалтингом, функциональное программирование может быть модным словом, которое, по мнению руководства, поразит ваших клиентов.
JeffO
3
Какие бизнес-аргументы вам привели менеджеры в отношении языков, которые вы используете в настоящее время?
JeffO

Ответы:

7

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

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

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

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

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

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

Ashalynd
источник
Если вы можете найти фактические исследования / доказательства для этих утверждений, чтобы поддержать их - особенно «Функциональные языки помогают избавиться от некоторых из этих проблем» - пока что это будет наилучшим доступным ответом.
ДВК
Этот самый вопрос уже обсуждался несколько раз, например, quora.com/Why-does-functional-programming-favor-concurrency или stackoverflow.com/questions/474497/…
Ashalynd
3
За исключением того, что многие языки ООП также поддерживают функциональное программирование, поэтому вы можете использовать функциональные аспекты, выплескивая ребенка с водой из ванны.
Энди
1
Правильно, вопрос был о «функциональном программировании», а не о «функциональных языках». Изменит формулировку.
Ашалынд
40

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

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

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

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

Док Браун
источник
7
Я поражен, что 19 человек проголосовали за ответ, который не отвечает на вопрос вообще . Это практический вопрос, в практической ситуации. Члены команды НЕ имеют права голоса, и их не нужно убеждать. Они также не будут работать - и я не буду в этом отношении - над неутвержденной технологией / языком, поскольку вопрос стал кристально ясным.
ДВК
1
@DVK Если никто не увидит ваш код, вам не нужно никого убеждать, что ваш язык хорош. Просто начни его использовать.
user253751
2
@DVK - вам нужно больше узнать о том, как руководство контролирует языки, используемые в вашей компании. В большинстве случаев руководство не имеет большого вклада в этой области, потому что они оставляют это на усмотрение команд и их лидеров.
JeffO
3
@DVK: Люди, отвечающие на вопросы, которые они считают наиболее полезными для ответа на поставленный вопрос. Если большинство людей голосуют против ответов, в которых говорится, что вы приближаетесь к неправильной проблеме, это может означать, что многие программисты сталкивались с подобными ситуациями и находили эти «не ответы» полезными. Большинство согласны с тем, что в вашем бизнесе есть что-то принципиально нездоровое, и оно не имеет никакого отношения к выбору языка. Большинство согласны с тем, что эту проблему необходимо решить, любая попытка сразу перейти к выбору языка просто приведет вас к следующему препятствию, а не к серии решений.
Cort Ammon - Восстановить Монику
1
@CortAmmon Я, к счастью, согласен с тем, что этот вопрос указывает на что-то не так с управлением компанией аскера, но вряд ли он сможет решить такие проблемы. Я видел из первых рук проблемы, которые может вызвать самоуверенный технический директор (фактически, только вчера мне пришлось потратить значительное количество времени на решение проблемы, вызванной правилом, согласно которому наша компания не будет развертывать программное обеспечение вне «программных файлов». "каталоги на компьютерах с Windows, но Ruby не будет устанавливаться в каталог с пробелом в его имени.
Жюль
16

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

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

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

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

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

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

Роберт Харви
источник
1
Нет, моя цель - НЕ (для целей этого вопроса) «расти как разработчик программного обеспечения». Моя цель - собрать лучший набор аргументов для представления людям, которые принимают решения, которые побудили бы их к разрешению FP в качестве одобренного подхода. Не больше, не меньше. Выделите преимущества FP, особенно по сравнению со стандартным ООП / процедурным стеком.
ДВК
Кроме того, если я не допустил серьезной ошибки в формулировке, вопрос определенно не имел в виду упоминание «массовых изменений» как предполагаемого результата разыскиваемых аргументов.
ДВК
+1 для Королевства Существительных. Я называю это «Войной между существительными и глаголами».
Роб
4
@DVK: способ убедить руководство в чем-либо был тем же самым с начала времени: покажи им, как это сэкономит им деньги.
Роберт Харви
9

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

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

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

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

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

Эрно
источник
1
Компании также озабочены тем, чтобы нанимать людей, поэтому, если заменить функционального разработчика сложнее, я бы сказал, что это хорошая причина для них участвовать в таких решениях.
Энди
1
@ Энди - Да, именно поэтому я не опровергаю вопрос, и я думаю, что менеджеры должны интересоваться темами, которые я изложил. Меня больше беспокоит то, что решение (Языки функционального программирования) выбирается ДО того, как проблема (???) будет определена.
Эрно
Неужели так сложно заменить функционального разработчика? По количеству информированных разработчиков, которые размещают здесь и на других сайтах в Интернете, я подозреваю, что есть намного больше функциональных разработчиков, чем думают менеджеры.
Джорджио
@ Джорджио - я никогда не говорил, что их трудно заменить, но, по моему опыту, доступность может отличаться от места к месту. Некоторые выпускники колледжей даже не изучали основы, в то время как некоторые университеты специализируются на них. Для бизнеса очень важно смотреть на долгосрочную перспективу и ожидаемую потребность в новых сотрудниках.
Эрно
@Erno: я согласен с вашим мнением. Я комментировал комментарий Энди. В любом случае, я всегда предполагал, что очень мало функциональных программистов и что FP рассматривается как нечто эзотерическое. В последнее время у меня сложилось впечатление, что разработчиков FP гораздо больше, чем рабочих мест FP.
Джорджио
3

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

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

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

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

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

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

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

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

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

Как только вы достигнете уровня доверия, что ваши аргументы будут услышаны и учтены, вы также определите способ сбора и рассмотрения требований, которым вы, ваша команда и руководство доверяете.

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

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

Плохая новость: в зависимости от размера и стиля компании это может занять несколько лет или десятилетий.

Хорошая новость: вы многому научитесь на своем пути.

Поскольку первый шаг - начать говорить и особенно слушать старшее руководство, я бы рекомендовал начать с чтения Just Listen .

Йенс Шаудер
источник
3

Один хороший подход - показать, что он показал хорошие результаты в отрасли и принят.

Вы можете получить некоторые данные из:

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

У Google есть много других похожих ссылок на Haskell, OCaml и т. Д.

LispGood
источник
3
Некоторые компании собираются рассматривать это как дело против, так как ОО practicioners превышает число FP приверженцев с большим отрывом .
Роберт Харви
1
@RobertHarvey - это что-то вроде аргумента красной сельди, по крайней мере, в моем конкретном случае. Они уже достаточно умны, чтобы знать, ЧТО. Что они НЕ знают (и что я узнал из этого ответа), так это то, что Eaton Vance использует Scheme и, что более важно, Faceboook , BoA / ML, Deutsche Bank и Google [используют Haskell]. Это означает, что они МОГУТ подумать о том, чтобы окунуться в них, поскольку другие достойные решили. Удивительно, что единственный действительно полезный ответ, который пытался ответить на вопрос, который я задал (а не тот, на который люди хотели ответить), - это тот, кто набрал наименьшее количество голосов
ДВК
1
@dvk: Вы задали вопрос (если я правильно понимаю): «Как мне убедить моих боссов, что FP - это хорошо?» Ну, иногда это не так. Мы живем в изменчивом мире, и функциональное программирование, честно говоря, немного странно. Если вы мне не верите, взгляните на монады. Ответы, касающиеся этих странностей (и того, как они влияют на процесс проектирования и разработки программного обеспечения), полезны, независимо от того, думаете вы это или нет.
Роберт Харви
@RobertHarvey (1) Я забираю это. Теперь ДВА из полезных ответов имеют наименьшее количество голосов :) (только что опубликованный новый может быть улучшен с помощью фактов, но это хорошее начало).
ДВК
@RobertHarvey - да. Вопрос был НЕ «Является ли FP хорошей вещью» или «Можно ли убедить людей, что FP хорошая вещь». Вопрос был очень точным: «Какие аргументы можно использовать, чтобы поддержать КОГДА пытаться убедить, что это хорошо». Это было НЕ «Как я могу незаметно внедрить FP в мою работу / кодирование в позитивном ключе», на что вы и ответили - если бы это был вариант, который я бы не спрашивал в первую очередь, я бы написал: )
ДВК
2

Вы идете на это с неправильного направления.

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

Скорее всего, вам следует подумать о том, что нужно текущему бизнесу и как его лучше обслуживать. Если так получится, что лучше всего использовать функциональную парадигму, то - да! - ты можешь играть. Но если вы проводите объективный анализ, принимая во внимание операционные потребности бизнеса, необходимую подготовку коллег, опыт будущих программистов, обслуживание и т. Д. И т. П., Часто это не будет.

Анонимный трус
источник
2
Это немного педантично, и не слишком помогает в ответе на вопрос, который следует абстрагироваться от просто помощи ОП в его «подходе».
VF1
1

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

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

Первый случай

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

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

Арсений Мурзенко
источник
3
Я вижу, что вы там сделали, но ваш пример не совсем убедителен. Вы в основном развернули свой функциональный пример до императивного, а это не то, что могло бы случиться в любой практической корпоративной проблеме. Вы yield returnнемного обманываете, это пример того, как вы будете готовить код для использования в сценарии Linq в любом случае, и ваши ifоператоры могут быть написаны более кратко с помощью троичных операторов. Весь ваш первый пример может быть преобразован в императивные функции, так что сложность скрыта.
Роберт Харви
@RobertHarvey Вы могли бы преобразовать первый пример в набор императивных функций, но это были бы пользовательские императивные функции, специфичные для этого запроса; вам все равно придется увидеть все это, чтобы убедиться, что запрос правильный. Этот рефакторинг еще больше увеличил бы размер императивного кода. Даже если бы вы могли написать его так же компактно, вы все равно должны внимательно прочитать код, потому что вся работа выполняется через побочные эффекты; Вы не хотели бы пропустить побочный эффект, который делается во второй части троичного оператора в конце строки.
Довал
1
@RobertHarvey Я даже не уверен, что два фрагмента кода эквивалентны, поскольку императивный «фильтрует», создавая второй список вместо того, чтобы просто пропустить итерацию. Разве реальный эквивалент не использовал бы только один цикл и таким образом был бы еще более глубоко вложенным?
Довал
5
Нет сомнений в том, что вы делаете хороший пример для включения функциональных концепций в язык, который в противном случае является императивным / OO, но это не обязательно хороший случай для использования полностью функциональных языков в корпоративной среде, которая уже является императивной / OO.
Роберт Харви
Еще одна (возможно, менее правильная) проблема с вашим примером: я мог бы написать первый пример на полностью читаемом, в основном не-FP Perl, в - я предполагаю - 30% объема. Может, меньше. Зависит от того, принимаете ли вы map/ grepкак не FP. Итак, вы приводите аргументы, что Java - плохой язык, а не FP - хороший подход.
ДВК