Функциональное программирование *

Пришло время уйти от OOP

Становится уже доброй традицией — все любопытное, что появилось на Хаскеле — повторять на Эликсире.

Первой ласточкой были «Примерно 20 строк для подсчета слов», появившиеся как алаверды на «Побеждая C двадцатью строками Haskell: пишем свой wc» от 0xd34df00d — сегодня же я наткнулся на «Перевозим волка, козу и капусту через реку с эффектами на Haskell» от iokasimov и тоже не устоял.

Итак, встречайте: ленивый полный асинхронный параллельный перебор против алгебраических эффектов.

Однажды крестьянину понадобилось перевезти через реку волка, козу и капусту. У крестьянина есть лодка, в которой может поместиться, кроме самого крестьянина, только один объект — или волк, или коза, или капуста. Если крестьянин оставит без присмотра волка с козой, то волк съест козу; если крестьянин оставит без присмотра козу с капустой, коза съест капусту.

Fetch — это библиотека Scala для организации доступа к данным из файловых систем, БД, веб-сервисов и любых других источников, данные из которых можно получить по уникальному идентификатору. Библиотека написана в функциональном стиле и основана на Cats и Cats Effect. Предназначена для композиции и оптимизации выполнения запросов к разным источникам данных. Она позволяет:

• запрашивать данные из нескольких источников параллельно;
• запрашивать данные из одного источника параллельно;
• объединять запросы к одному источнику в один запрос;
• производить дедупликацию запросов в каждой из перечисленных ситуаций;
• кэшировать результаты запросов.

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

Перевод статьи подготовлен в преддверии старта курса «Scala-разработчик»

Теа, Ральф и Джесси используют tapir для описания своих конечных точек HTTP. Им нравится его удобный для программиста API, способ описания конечных точек, возможность использовать одно и то же описание для генерации сервера, клиента или документации, а также его возможности абстракции.

Однако, когда дело доходит до определения серверной логики для конечных точек (то есть, что должно произойти, когда их конечные точки интерпретируются как сервер и подвергаются воздействию внешнего мира), приоритеты у них разнятся. К нашей великой удаче, все три подхода теперь покрыты tapir!

Мне нравится экспериментировать с разными парадигмами и играться с разными интересными (для меня) идеями (некоторые из них превращаются в посты: раз, два). Недавно я решил проверить, смогу ли я писать объектно-ориентированный код на функциональном языке.

Наверное я не ошибусь, если скажу, что чаще всего на собеседованиях спрашивают о SOLID принципах. Технологии, языки и фреймворки разные, но принципы написания кода в целом похожи: SOLID, KISS, DRY, YAGNI, GRASP и подобные стоит знать всем.

В современной индустрии уже много десятков лет доминирует парадигма ООП и у многих разработчиков складывается впечатление, что она лучшая или и того хуже — единственная. На эту тему есть прекрасное видео Why Isn't Functional Programming the Norm? про развитие языков/парадигм и корни их популярности.

SOLID изначально были описаны Робертом Мартином для ООП и многими воспринимаются как относящиеся только к ООП, даже википедия говорит нам об этом, давайте же рассмотрим так ли эти принципы привязаны к ООП?

Неделю назад в издательстве "Ридеро" вышла книга "Clojure на производстве". Как ее автор, расскажу о ней подробнее: что внутри и кому она полезна.

Общие сведения

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

Это книга — попытка облегчить погружение в практику. Одновременно хочу развеять ложные надежды: Clojure — прекрасный язык, но и в нем не бывает чудес.

От других материалов по Clojure книга отличается следующим. Прежде всего, это не перевод. Я не зря делаю на этом акцент во вступлении. Проблема переводов в том, что в издательствах не понимают технические термины и пытаются их адаптировать. Token становится маркером, trait — чертой, persistence — сохранностью. Формально перевод корректный, но пропадает живость описания, и к нему падает интерес. В своей книге я не срезал углы: если у слова нет однозначного перевода, я ставил английский вариант — тот, в котором мы видим его каждый день.

Есть довольно простая идея, высказанная Фейнманом — цель физики найти простейшую теорию, которая сможет объяснить как можно больше явлений природы. Эта та идея, которая стоит за электродинамикой Максвелла или КЭД. Каждая новая большая теория объясняла больше явления природы и при этом была проще предшественников.

Это довольно простая мысль с далеко идущими последствиями. Так почему бы нам (инженерам) не взять ее на вооружение? Почему одни из лучших идей про разработку еще не формализованы и унифицированы, как тот же KISS или DRY? Они что, по сути не формализуемы? Это не может быть так если мы возьмем во внимание тот факт что информатика это раздел математики. Должен быть какой-то способ вывести эти пресловутые лучшие практики. И может, если у нас получиться вывести те что мы знаем по опыту, мы сможем выводить совершенно новые. В других научных дисциплинах именно это и происходило — ярче всего это было в авиации. Сначало, опытным путем, инженерам получилось построить то что хоть как-то да отрывается от земли, и только после физика крыла реально была изучена. С этой новой физикой мы имели просто взрывной рост отрасли.

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

"Кто ни разу не ошибался в индексировании цикла, пусть первый бросит в деструкторе исключение."

— Древняя мудрость

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

В конце концов, это просто некрасиво.

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

Данная работа ставит своей целью пролить свет на отнюдь не новую, но пока что не слишком распространённую идею, которая вполне способна произвести очередной прорыв в области написания программ на языке C++.

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

FizzBuzz это известная задачка, шутливо или не очень задаваемая на собеседованиях, существует множество вариантов реализации даже для такой простой игры. Существует даже шедевры вроде FizzBuzzEnterpriseEdition.

Предлагаю вашему вниманию еще один вариант, не совсем пятничный, а скорее субботний: FizzBuzz на Scala, functional style.

Я несколько раз начинал читать статьи из серии «Введение в функциональное программирование», «Введение в Теорию Категорий» и даже «Введение в Лямбда Исчисление». Причем и на русском, и на английском. Каждый раз впечатление было очень сходным: во-первых, много новых непонятных слов; во-вторых, много новых определений, которые возникают из ниоткуда; в-третьих, совершенно непонятно, как это использовать.

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

Попытки использовать как-то в работе изученные концепции разбивались о полное непонимание, как применить полученное глубокое знание. Ведь, напомню, что парадигму ФП (где-то удобнее, где-то не очень, но) можно использовать практически в любом ЯП, совсем необязательно для этого изучать условный Хаскель.