Парадигмы программирования (ООП vs ФП)

Парадигма — это набор концепций мышления о коде, а не синтаксис. React-компонент в виде function ≠ ФП. ООП класс ≠ обязательно ООП-код. Реальный мейнстрим — мультипарадигма: процедурное + ООП + ФП без монадических вычислений.

Не путать синтаксис с парадигмой

Начинающие считают, что если вы пишете React-компоненты в функциональном стиле, то это функциональное программирование, а если на классах, то это ООП. Это с реальностью ничего общего не имеет.

Функциональный компонент с useState и побочными эффектами в useEffect — это ООП объект, упакованный в синтаксис функции.

Что пишут реально

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

Монадический стиль используют 2-3 раза в год — для конкретных задач или обучения.

Зачем монадический стиль

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

Ключевые эффекты:

  1. Бесплатное масштабирование — один и тот же код запускается в одном процессе, на нескольких ядрах, на распределённой системе. Внешней обвязкой, без переписывания.
  2. Нет комбинаторного взрыва состояний — чистые функции тестируются по одной, контракты стыкуются автоматически.
  3. Алгебраические типы — компилятор/линтер гарантирует обработку всех вариантов.

Декларативность ≠ ФП

Декларативность — это не свойство FP-подхода, это свойство в принципе любого хорошего кода. В том же ООП тоже надо писать декларативный код. У декларативного кода всегда под капотом будет императивный.

Filter/map/reduce пришли из ФП, но это декларативный синтаксис над императивной реализацией.

ФП к декларативности не стремится — оно ею является

В ФП декларативность не цель, а данность. По-другому ты код написать не можешь. Это суть самого FP.

Где ФП реально хорошо

  • Обработка сигналов (звук, видео, датчики)
  • Криптография и защита данных
  • Потоковая обработка + трансформации + наложение
  • Парсеры
  • ETL и data pipelines

Бизнес-логика — это перекладывание данных по правилам. Структуры данных, проверка, перекладывание, бизнес-правила. ФП хорошо ложится на этот сценарий.

ФП ≠ выведено из лямбда-исчисления

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

История: Fortran → subroutine с возвратом и без → Pascal разделил function/procedure → Маккарти захотел if как expression → LISP → ФП.

«Нам не нужны никакие процедуры с наборами действий. Мы всё можем описать функциями. Функция всегда возвращает значение.» — Маккарти.

ФП-принципы = переписанный SOLID

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

ООПшники "апроприировали" GoF и SOLID, но базовые принципы хорошего кода одинаковы.

Алан Кей и ООП

Алан Кей вообще не то имел в виду. Первое, что он придумал — это что-то похожее на модель акторов. Изолированные акторы с состояниями переплевываются ивентами.

Современный ООП (классы с наследованием) — не то, что было задумано как ООП изначально.

Почему ФП отстало в архитектуре

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

ООП доминировал в индустрии → потребность в расширяемых системах → SOLID, GRASP, GoF.

5000 чистых функций — 2 разработчика

Программа из 5000 чистых функций — их можно протестировать по одной. Если контракты стыкуются и есть алгебраические типы — 98% надёжность. Где нужно 10 ООП-разработчиков, тут 2 человека поддерживают.

Связанные темы

Ресурсы