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

Разбираемся, как работает второй из базовых паттернов Nix — callPackage. Автоматизируем передачу параметров, сокращаем код репозитория.

В заметке "Идиоматическое внедрение зависимостей в ZIO 2" Пьер Рикадат описывает типичную структуру Scala-приложения на основе ZIO. Элементами этой структуры являются использование интерфейсов, классов с зависимостями и dependency injection.

Известен также подход, описанный в заметке "От внедрения зависимостей к отказу от зависимостей" Марка Симана. Автор прежде был апологетом внедрения зависимостей и написал об этом книжку. Но в функциональном подходе можно строить системы без зависимостей, что требует отказа сразу от интерфейсов, классов с зависимостями и от понятия dependency injection.

Хотелось бы посмотреть, как те же примеры, что приводит Пьер Рикадат, будут выглядеть без классов и интерфейсов. А также понять, можно ли использовать ZLayer'ы при разработке программ в функциональном стиле.

Перевод заметки Пьера Рикадата о механизме ZLayer в ZIO2 ("Idiomatic dependency injection for ZIO applications in Scala", Pierre Ricadat).

---

Я (автор оригинальной заметки) часто слышу в Интернете в Scala-обсуждениях, что ZLayer "слишком сложный" или "лишний". Эти совершенно противоречит моему опыту: я считаю, что ZLayer - невероятно крутая технология! В предыдущих версиях ZIO действительно были проблемы (те, кто помнит тип данных Has[_], знают, о чем я говорю!), но с тех пор всё поменялось. В этой статье я покажу идиоматическое использование ZLayer для DI (dependency injection, внедрение зависимостей) и надеюсь продемонстрировать, как это позволяет делать сложные вещи очень простым способом.

Примечание: Я много лет работал с приложениями ZIO (ещё даже до выхода версии 1.0!), и в настоящее время я работаю над серверной частью большой многопользовательской онлайн-игры, полностью написанной на Scala и использующей ZIO. Примеры в этой статье основаны на этой кодовой базе.

Разбираемся в тонкостях разработки пакетов. Изучаем паттерны, которые применяются при создании пакетов и репозиториев в Nix.

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

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

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

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

Задачи разработки компиляторов и интерпретаторов конфигурационных языков или даже полноценных Тьюринг-полных языков программирования время от времени встают перед разработчиками программного обеспечения. На практике, как правило, речь идёт о разработке предметно-ориентированных языков (англ. Domain Specific Language, DSL), проектируемых специально для решения узкого класса прикладных задач.

В статье рассматривается один из способов реализации DSL на примере разработки системы символьного дифференцирования, как в SymPy, с использованием парсер-комбинаторов peco и структурного сопоставления с образцом по PEP 636. Материал рассчитан на прикладных разработчиков, уже знакомых с Python, но, надеюсь, может быть полезен и продолжающим компиляторщикам.

Содержание пятой части:

Натуральные числа
Разложение в ряд
Производные от типов
Производные от экспоненциалов
Производные от рекурсивных типов

Содержание четвёртой части:

Обобщение свёрток/развёрток
Параморфизм и другие схемы рекурсии
Хистоморфизм
Футуморфизм

Сравнительно небольшая часть обзора, посвящённая свободным контейнерам. Содержание:

Свободный контейнер
Более свободный контейнер
Батуты
Ко-свободный контейнер
Промежуточный итог

Содержание второй части:

Неподвижные точки конструкторов типов
Начальная F-алгебра
Наибольшая неподвижная точка
Классы типов неподвижных точек

Слово «рекурсия» происходит от латинского «recursio» – «круговорот, возврат». Применительно к вычислениям этот термин относится к алгоритмам, повторяющих какие-либо действия. Этот обзор посвящён типам, которые обслуживают рекурсивные алгоритмы.

Это вводная часть и собственно про типы здесь будет мало что сказано. Содержание:

Вычислимые функции
Циклы и рекурсия
Cтек и хвостовая рекурсия
Ссылки вперёд
Y-комбинатор в λ-исчислении
Реализация комбинатора неподвижной точки

Я пишу коммерческий код с 2005 года и с 2014 года ищу способ систематически писать хороший код.

В рамках этих поисков я изучил всю популярную литературу о хорошем коде и его дизайне — от «Чистого кода» Анкл Боба до «DDD» Эрика Эванса. Однако все популярные подходы в значительной степени субъективны: они не дают объективного и последовательного судьи, который бы решал, какой код лучше.

Например, в чистом коде я до сих пор не знаю способа за конечное время дать ответ на вопрос «Сколько уровней абстракции в этой функции?». А если взять DDD — то я до сих пор не знаю способа, который бы позволял стабильно и за конечное время находить границы между ограниченными контекстами (прошу прощения за каламбур) или агрегатами.

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

Отчаявшись научиться писать стабильно хороший объектно‑ориентированный код, в 2016 году я пошёл в сторону функционального программирования и архитектуры. Там с детерминированностью было получше: если в коде нет побочных эффектов (ввода‑вывода, оператора присваивания и чтения глобальных переменных) — то код хороший, если есть — плохой. Однако как затащить в коммерческий проект и, главное, собственную голову свободные монады и их интерпретаторы — я так и не понял.

Поэтому в 2020 году поиски своего Святого Грааля я продолжил в «эзотерических» и древних книгах. Одной из таких книг стал «Структурный дизайн» Ларри Константина. И в этой книге я, наконец, нашёл простой и понятный принцип, который лёг в основу моего текущего подхода к проектированию и кодированию, и для которого можно быстро и однозначно дать ответ, соответствует ли тот или иной кусочек кода этому принципу или нет.

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

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

Краткая цель статьи — сделать потоки данных проще, более тестируемыми и управляемыми с DTO и Runtime Model структурой.

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

Концепт использует немного функционала Entities, описанных Robert C. Martin (Uncle Bob) в Clean Architecture, также Model‑Driven engineering вместе с концептом immutability.

Эта статья:

— разделена на секцию теории и применения, чтобы статью можно было понять разработчикам не знающим язык используемый в примерах (Dart).
— в основном фокусируется на client‑side (frontend, app, server‑side рендеринг) разработчиках, но думаю что может быть интересна и другим разработчикам..
— для примеров используется абстрактное финансовое приложение и язык Dart.

Бывает ситуация, когда нам необходимо протестировать middleware, либо асинхронное событие, которые возникает в хранилище redux.

Цель этой статьи в том, чтобы показать как тестировать action в redux store.

Есть готовое решение, redux-mock-store, но оно не позволяет оперировать реальным хранилищем, через него мы можем только проверить был вызван тот или иной action, а данные которые сохраняем мы в store, не можем проверить.

Однажды я устроился в проект на Erlang. Вообще мой профиль тогда был в основном Java и немного BigData. Но по результатам собеседования договорились что я попробую написать небольшое тестовое задание — и сам пойму нравится ли мне язык — и ребята оценят, гожусь ли я им. Ну и за выходные справился — язык непривычный но не очень сложный — и интересный, с необычными «фишками». Команде же, куда меня взяли, оказался удобен мой опыт в бигдате и амазоне.

Сейчас я расскажу на паре примеров про язык — он действительно по‑своему классный (если вам нравится функциональное программирование — это для вас) — и про то как, однако, он оказался неудачным выбором для проекта (данного‑конкретного).

Статья для широкого круга читателей, не знакомых с языком — знатоки же Эрланга в частности и ФП вообще возможно найдут неточности в моём повествовании — дело было лет 6 назад — так что можете смело поправлять и даже ругать при необходимости:)

Приветствую всех, кто устал от бесконечных проверок на null, громоздких блоков try-catch и мутирующих коллекций. Если вы когда-нибудь мечтали о том, чтобы привнести в Java немного функциональности, то я рад рассказать вам о библиотеке Vavr.

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