How to stop functional programming (2016)

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

Пример с функцией userCoworkers показывает, как чистый код постепенно усложняется: сначала добавляется мутабельная коллекция, затем логирование. Юмор в том, что даже с побочными эффектами метод остаётся чистым снаружи, а задание «просто вернуть число» ставит под вопрос, как вообще избежать функциональных подходов. Финальный совет — спросить у менеджера, как сложить числа без чистых функций — подчёркивает абсурдность таких запретов.

Комментарии (62)

Важность написания читаемого кода с учетом целевой аудитории (уровня навыков читателей) и необходимости согласования стиля в команде.
Критика восприятия функционального программирования (ФП) как исключительно сложного, с указанием, что проблема часто в неидиоматичном коде, излишне длинных цепочках методов или специфических особенностях языков (например, Haskell), а не в ФП как парадигме.
Необходимость обучения, код-ревью и парного программирования для внедрения сложных концепций и выравнивания уровня команды, особенно при использовании нишевых языков (например, Scala).
Споры о балансе между простотой (для младших разработчиков) и продвинутыми практиками, где чрезмерное упрощение может привести к посредственному коду, а сложность — к проблемам читаемости.
Роль менеджмента в разрешении конфликтов через технические решения, которые могут ограничивать инструменты или стили (например, запрет ФП), иногда без глубокого понимания причин проблемы.