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

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

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

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

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

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

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

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

Неподвижные точки конструкторов типов
Начальная 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 этим, твой код станет немного гибче и проще.

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

В новой статье директор департамента разработки компании «Криптонит» Алексей Шуксто рассказал об интересных особенностях управления жизненным циклом объектов в Scala и Java разных версий. С необходимостью вникать в эту внутреннюю кухню сталкиваются все, кто использует в своих программах потоки, подключения к БД и другим сторонним сервисам, анализирует метрики, обрабатывает исключения… все, кто пишет что-то сложнее «Hello World!» и хочет добиться предсказуемого результата.

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

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

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

Исследуем пакетный менеджер Nix и операционную систему NixOS.
В этой статье разбираемся со сборщиком мусора.

Цикл из одиннадцати статей Скотта Влащина, посвящённый вычислительным выражениям (computation expressions) в F#.

Скотт Влащин завершает рассказ о вычислительных выражениях в F#.

Сегодня поговорим про методы класса-построителя, с которыми мы ещё не сталкивались.

Скотт Влащин продолжает рассказ о вычислительных выражениях в F#.

Сегодня мы узнаем, как создавать ленивые вычислительные выражения.