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

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

С точки зрения ФП такой сервис будет являться просто функцией Request => Response. Из этого сразу вытекает, что взаимодействовать с таким сервисом можно даже без наличия реального сервера, и, более того, к нему применимы те же рассуждения, что и к обычным функциям. Путём модификации сигнатуры функции сервиса в него можно добавить, к примеру, обработку внутренних исключений, а с помощью комбинации функций можно добавить в сервис метрики, логирование, аутентификацию и т.д. Именно тот факт, что высокоуровневую абстракцию сервиса можно выразить с помощью функции - базовой конструкции языка - приводит к написанию тестируемого, композабельного и понятного кода, который можно назвать хорошим.

Более подробно (с примерами кода) в видео с митапа Scale by the bay:
https://www.youtube.com/watch?v=0oVpLdgZqpE

Scala bin

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

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

С точки зрения ФП такой сервис будет являться просто функцией Request => Response. Из этого сразу вытекает, что взаимодействовать с таким сервисом можно даже без наличия реального сервера, и, более того, к нему применимы те же рассуждения, что и к обычным функциям. Путём модификации сигнатуры функции сервиса в него можно добавить, к примеру, обработку внутренних исключений, а с помощью комбинации функций можно добавить в сервис метрики, логирование, аутентификацию и т.д. Именно тот факт, что высокоуровневую абстракцию сервиса можно выразить с помощью функции - базовой конструкции языка - приводит к написанию тестируемого, композабельного и понятного кода, который можно назвать хорошим.

Более подробно (с примерами кода) в видео с митапа Scale by the bay:
https://www.youtube.com/watch?v=0oVpLdgZqpE

YouTube

Scale By The Bay: Paul Snively, FP Scala Meat & Potatoes...

ai.bythebay.io Nov 2025, Oakland, full-stack AI conference Scale By the Bay 2019 is held on November 13-15 in sunny Oakland, California, on the shores of Lake Merritt: https://scale.bythebay.io. Join us!
-----

Title: FP Scala Meat & Potatoes: HTTP, JSON…

hottg.com/scalabin/36

153 viewsedited  Mar 3, 2019 at 06:23