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

Абразивные материалы — обязательный инструмент в хозяйстве домовладельцев: с их помощью шлифуют дерево, зачищают металл и приводят в порядок поверхности перед покраской. В строительстве от качества абразивов зависит буквально все: ровно ли будут обработаны стены и полы, можно ли вообще будет назвать дом красивым и удобным, который не стыдно показать гостям. А на производстве точность обработки абразивами определяет финальное качество деталей. Для предприятий-изготовителей качество абразивной продукции — это вопрос их престижа и постоянных клиентов, которые должны быть уверены, что абразивы под их брендом точно не подведут. Рассказываем про белгородский стартап «Солид» — интеллектуальную платформу визуальной аналитики для контроля качества абразивных изделий. Он создан студентами Белгородского государственного технологического университета им. В. Г. Шухова (БГТУ) и прошел прокачку на межвузовском акселераторе «Хоумнет», реализуемом в рамках ФП «Технологии».

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

Примеры написаны на JavaScript (ES2015). Почему JavaScript?

Где уместно, в этом документе используются термины, определенные в Fantasy Land spec.

Несколько месяцев назад я зачем-то полез изучать теорию категорий. Причины были примерно те же, по которым нормальные люди иногда решают разобраться в квантовой механике по роликам на YouTube: звучит умно, выглядит загадочно, а главное – можно потом с важным лицом употреблять слово «эндофунктор» в компании людей, которые не могут проверить, несёшь ты ахинею или нет. В моём случае ситуацию усугубляла любовь к функциональному программированию, поэтому рано или поздно столкновение с теоркатом было неизбежно.

Первые впечатления были соответствующими. Категории, морфизмы, функторы, естественные преобразования, монады, знаменитое «монада – это моноид в категории эндофункторов». Я читал определения, вроде бы даже понимал отдельные слова, закрывал книжку и через пару часов снова не мог ответить на простой вопрос: а зачем мне всё это как программисту? Я пишу обычные приложения, крашу кнопки, перекладываю JSON из одного места в другое. Где в этой картине должны появиться все эти стрелочки?

Что произойдет, если AI‑программист будет получать контекст не из собственного чата, а из функциональной и архитектурной модели проекта?

ERP‑Tools совместно с Cursor пилят сайт и документируют систему.

Привет! Меня зовут Артём. Я руководитель группы Scala-разработчиков в компании «Криптонит», бэкенд-разработчиков, если быть точнее. Мы пишем на Typelevel стеке с использованием Cats Effect. Я знал о том, что можно писать фронтенд на Scala, но не делал этого, пока не занялся небольшим pet-проектом сервис "План развития". По пути я обнаружил множество “подводных камней” и сделал для себя ряд выводов. Об этом интересном опыте и будет моя статья.

Как написать бэк на Typelevel стеке большинство знают — этому посвящены сотни ресурсов: книги, статьи, курсы... В частности, этому посвящена книга “Practical FP in Scala” Габриэля Вольпе (Gabriel Volpe), где описывается создание интернет-магазина. Но как визуализировать этот магазин? 

Как скрестить фронт и Scala тоже известно: У Play framework более 12 тысяч звёзд на гитхабе. На этом фреймворке успешно написаны сотни продуктов. Однако Play — это классический ООП-фреймворк, плюс он основан на Pekko/Akka, а мне хотелось писать в функциональном стиле на Typelevel стеке, где под капотом cats effect и htttp4s.

Первое решение — а почему бы не навайбкодить фронт?! Но у вайбкодинга есть определённая граница, после пересечения которой ты уже перестаёшь понимать проект, количество багов очень быстро растёт. Всё это приводит к демотивации и потере энтузиазма:

Носителям прекрасного языка программирования C++ тема частичного применения может показаться скучной. Что примечательного в пяти строчках кода? Но дьявол кроется в деталях: я часто встречал реализации, которые работали не так, как ожидали их авторы. Иногда дело доходило до undefined behavior. Поэтому здесь хочется разобраться прежде всего с владением, временем жизни и категориями значений.

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

Здесь мы рассмотрим, как можно генерировать целевые структуры для объектов JSON напрямую из JSON схем при помощи других трюков из стандарта 26.

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

Раскопал на Medium интересное эссе про Elixir от разработчика Krzyś. Написано так захватывающе и самобытно, что я не смог пройти мимо. Хотел чуть-чуть подсократить, но каждый раздел важен, а терять стиль автора не хочется. Вот тут первая часть, а это — вторая.

Раскопал на Medium интересное эссе от разработчика Krzyś про Elixir. Написано так захватывающе и самобытно, что не смог пройти мимо. Хотел чуть-чуть подсократить, но каждый раздел важен, а терять стиль автора не хочется. Поэтому разбиваю его на две части — сегодня делюсь первой.

Навайбкодить 10k строк кода за час — дело нехитрое. Но как проверить, что этот код рабочий? Можно потратить много часов на ревью классическим способом, а можно прочитать эту статью и применить у себя новый метод. В материале архитектор Mindbox Саша Кальницкий рассказывает, как перестроил работу с AI‑агентами, чтобы больше им доверять и не тратить время на код‑ревью.

Здесь мы разберём

∙ элементы математической логики, связывающие её с языками программирования;

∙ ключевой аспект логического программирования — автоматизация вывода искомого результата (конструктивного доказательства);

∙ базовые принципы языка Пролог;

∙ связь теории типов с математической логикой;

∙ связь механизмов «неявности» в разных языках с логическим программированием.

Если честно, я давно планировал написать свой язык. Просто надоело на каждом проекте писать одинаковый бойлерплейт, ловить неожиданные ошибки в рантайме, натыкаться на компоненты аля LoanPreloanInterractNDFL6.2ReportViewComponent - и гадать - что имел ввиду художник...

В итоге получился язык "Марка" — штука статически-типозированная, но в которой типы живут во время выполнения, ошибки обрабатываются сами, а из REPL можно сразу дергать запросы и смотреть, что приходит на клиенте и сервере. Как давно мечтал.

Но раскидав исходники по знакомым, получил неутешительный фидбэк: читать трудно! Встал дурацкий вопрос: как это должно выглядеть в коде, чтобы было удобно? Я набросал 4 варианта синтаксиса — от LISP-стиля до почти Python - нотации. У каждого есть плюсы и минусы, и я уже неделю не могу выбрать.

Какой из вариантов читать было бы удобнее лично вам? Проголосуйте!

P.S. Если заинтересовал проект - уже сейчас доступна playground площадка для экспериментов http://marka-lang.ru/playground.php

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

Обзор, посвящённый применению элементов теории категорий в программировании, завершён. Настало время подвести его итоги.

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

Как построить гибкий реактивный граф обработки данных, где узлы изолированы друг от друга, а связи между ними строятся автоматически на основе их возможностей? Рассказываю о разработке Transferum — легковесной TypeScript-библиотеки для реактивных потоков. Внутри: разбор системы вычислимых типов для проверки контрактов в compile-time, управление маршрутизацией данных в графе и примеры построения динамических пайплайнов для IoT-датчиков и панелей управления.

Императивные эффекты (direct-style effects), также известные как «алгебраические эффекты» и «обработчики эффектов», — это следующий шаг в развитии языков программирования. Сначала мы обсудим проблему и связанные с нею ограничения. Затем рассмотрим простую реализацию на Scala 3 и опишем языковую особенность, которая её обеспечивает — контекстные функции. Далее мы увидим некоторые недостатки этой реализации и посмотрим, как их можно решить с помощью двух языковых особенностей: одной хорошо известной (ограниченные продолжения) и одной, находящейся в разработке (нововведения в системе типов).

В мире разработки программного обеспечения редко можно увидеть, как зрелый, динамический язык добавляет мощную, статическую систему типов без ущерба для своей философии и существующего кода. 3 июня 2026 года команда Elixir сделала именно это, выпустив версию 1.20. Главное нововведение — постепенная типизация (gradual typing), которая обещает найти в вашем коде «верифицированные баги» (verified bugs — ошибки, гарантированно ведущие к падению в рантайме) без необходимости писать аннотации типов.

Но почему это должно волновать вас, если вы пишете на Python, Java или Go? Команда Elixir поставила перед собой цель, которую многие считают «святым граалем». На практике сочетание всех трёх свойств почти не встречается.

И я считаю, что это отличный повод присмотреться к Elixir, даже если вы никогда не писали на нём ни строчки. Зрелый и интересный язык, работающий на виртуальной машине Erlang (BEAM) и исповедующий функциональную парадигму. Он известен своей отказоустойчивостью и конкурентностью, но, увы, остается малоизвестным языком, и я надеюсь что эта статья заставит вас заинтересоваться Elixir.

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