ФП виновно в снижении стоимости программ. Вот мои доказательства, господа присяжные заседатели

Введение

Среди особенностей Эргономичного подхода у моих заказчиков, коллег и студентов наибольшее сопротивление вызывает использование Spring Data JDBC, а не [Spring Data] JPA (де-факто стандарта работы с БД на платформе Java).

Изначально я собирался писать пост "Почему не JPA", но немного подумав понял, что ответ умещается в одно предложение: потому что JPA по своей природе (persistence context и dirty checking) не поддерживает неизменяемую модель данных - неотъемлемую часть функционального стиля программирования, который, в свою очередь, является неотъемлемой частью Эргономичного подхода. И это объективный факт.

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

Уверен, многие не согласятся с истинностью утверждения "применение функционального стиля ведёт к снижению стоимости разработки". Поэтому я пока буду называть его Гипотезой и приведу факты, доказывающие её истинность.

Главный из этих фактов - эмпирическое подтверждение Гипотезы, описанное в книге Structured Design.

Структурный дизайн

В 60-ых годах прошлого века учёный Ларри Константин написал книгу Structured Design. В этой книге он впервые ввёл понятия сцепленности (coupling) и функциональной связанности (cohesion), которые до сих пор лежат в основе большинства подходов к проектированию и кодированию программ.

Помимо этого, в главе "THE MORPHOLOGY OF SIMPLE SYSTEMS" (для просмотра необходимо пройти бесплатную регистрацию и "занять" книгу), Константин приводит иллюстрацию того, что он называет моделью, ориентированной на трансформацию (выделение цветами моё):

Упрощённо, эта модель разбивает код на четыре вида - ввод, вывод, трансформации и координацию.

Затем Константин пишет:

И если предположить, что трансформации являются чистым функциями в терминах ФП, то в этой модели отчётливо видна функциональная архитектура:

Константин не пишет прямым текстом, что трансформации - это чистые функции, но если изучить книгу и её исторический контекст, то это становится очевидно.

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

Первый вид эффектов (ввод-вывод) в подпрограммах трансформации исключён самой моделью.

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

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

Наконец, в статье Structured Design Константин пишет:

Это определение well-behaved модуля (подпрограммы) буквально является определением чистой функции.

Таким образом, мы получаем:

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

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

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

Тем не менее, я считаю, что слова учёного с мировым именем заслуживают доверия. В том числе потому, что они подтверждаются другими экспертами-практиками и моим собственным опытом.

Косвенные подтверждения Гипотезы

Вероятная причина низкой стоимости ФП-программ

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

Потому что при работе с понятной программой, разработчику требуется меньше времени (=денег) на её изучение, для того чтобы внести требуемые правки. И при изменении понятной программы меньше вероятность внести ошибку, которая потребует дополнительного времени (=денег) на её исправление.

И я хотя понятность кода во многом является субъективно метрикой, программы, написанные в функциональном стиле, объективно более понятны.

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

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

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

По сути та же ситуация может возникнуть и в однопоточной программе в момент вызова функции с передачей в неё изменяемой структуры данных. Да, тут всё значительно проще - вы точно знаете когда и примерно знаете кто (в случае полиморфного вызова в закрытой системе) может подменить вам конфетку. Но для того чтобы быть уверенным, что вы съедите именно конфетку, вам надо перед каждым использованием функции (и после каждого её изменения) заглядывать внутрь и изучать, что она делает с вашей конфеткой.

Эту проблему императивного стиля можно проиллюстрировать на следующем примере:

fun main() {
    val els: ArrayList<Int> = arrayListOf(2, 2)
    val sum = sum(els)
    println("Сумма ${els[0]} + ${els[1]} = $sum")
}

fun sum(els: ArrayList<Int>): Int = TODO()

Что мы можем сказать про поведение этой программы? Если вынести за скобки то, что прямо сейчас она вылетит с исключением (так реализована функция TODO в Kotlin) - ничего.

Потому что sum может быть реализована, например, так:

fun sum(els: ArrayList<Int>): Int {
    var sum = 0
    while (els.isNotEmpty()) {
        sum += els.remove(0)
    }
    return sum
}

С такой реализацией вызов этой программы завершится выбросом IndexOutOfBoundsException. Это хоть и синтетический пример, но он основан на реальных событиях - из-за подобного кода я лично вносил баг, который нашли только в проде.

Для того чтобы снизить стоимость разработки, не надо знать теорию категорий

Пуристы во главе с Эриком Мейером со мной не согласятся, но прагматики во главе в анкл Бобом меня поддержат в том, что для получения пользы от ФП-стиля не обязательно уходить в идеально чистое функциональное программирование.

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

Я не знаю единого хорошего источника по пролетарскому прагматичному ФП, но могу порекомендовать трек его изучения.

Заключение

Итого мы имеем следующие факты:

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