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

Важно знать, где FP сияет, а где нет, прежде чем полностью принять его. Следовательно, этот пост в блоге должен помочь вам решить, подходит ли FP для решения вашей проблемы.

Преимущества

Простой

Ограничения, налагаемые чистыми функциями и неизменностью, способствуют простоте. Как я упоминал ранее, я отчетливо имею в виду простое и непростое. Рич Хикки разъясняет это в своем выступлении Просто стало легко. https://www.youtube.com/watch?v=LKtk3HCgTa8. Когда мы говорим о написании кода, простой код понятен, точен, лаконичен и поэтому прост для понимания. Поэтому простой код написать непросто. Easy лежит рядом, а точнее первая реализация, которая приходит на ум.

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

Тестируемый

Вы когда-нибудь часами пытались заставить макет работать? у меня есть и хреново. Это расстраивает, потому что кажется, что вы тратите время, которое могли бы потратить на реализацию функций. Я был на проекте, где коллеги пропускали написание тестов, потому что насмешки доставляли слишком много хлопот. Угадайте, чистые функции не нуждаются в тестировании моков. Это означает, что все ядро ​​вашего приложения можно протестировать без моков в FP. Что еще лучше, вы можете математически доказать правильность чистых функций. Модульные тесты без моков проще и быстрее (меньше кода) писать и дают высокую уверенность в правильности вашей реализации.

Многоразовый

Три свойства FP делают его функции многоразовыми.

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

Следующие два — более продвинутые концепции, которые я еще не объяснял. Я сделаю это в будущем посте в блоге

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

Масштабируемость

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

Недостатки

Использование памяти и производительность

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

Меньше фреймворков и инструментов

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

Меньше пользователей/экспертов

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

Другие соображения

Известный французский философ Клод Леви-Стросс сказал бы об определенных инструментах:

«Хорошо ли думать?».

Функциональное программирование — это подход к анализу проблемы определенным образом. Эрик Норманд описывает это как действия, расчеты и данные в своей книге Grokking Simplicity. Действия – это взаимодействие с внешним миром. Действия — это операции ввода-вывода или любые нечистые операции. Вычисления — это чистые функции, работающие с (неизменяемыми) данными.

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

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

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