От Lisp до Haskell
Привет, Хабр :3, что-то давно я не писал свое графоманство, что читается хуже нейрослопа, да и знаки препинания по паузам в уме моём, а еще я "–" умею ставить ввиду академической проф-деформации.
Итак, заваривайте чай, напрягаем мозг, сегодня поговорим в целом о программировании и его проблемах ввиду популяризации LLM, а также экспериментах и куда смотреть, а куда не надо. Плана статьи не будет, до конца дочитают сильнейшие (изи байт). Ехала!
Абразивные материалы — обязательный инструмент в хозяйстве домовладельцев: с их помощью шлифуют дерево, зачищают металл и приводят в порядок поверхности перед покраской. В строительстве от качества абразивов зависит буквально все: ровно ли будут обработаны стены и полы, можно ли вообще будет назвать дом красивым и удобным, который не стыдно показать гостям. А на производстве точность обработки абразивами определяет финальное качество деталей. Для предприятий-изготовителей качество абразивной продукции — это вопрос их престижа и постоянных клиентов, которые должны быть уверены, что абразивы под их брендом точно не подведут. Рассказываем про белгородский стартап «Солид» — интеллектуальную платформу визуальной аналитики для контроля качества абразивных изделий. Он создан студентами Белгородского государственного технологического университета им. В. Г. Шухова (БГТУ) и прошел прокачку на межвузовском акселераторе «Хоумнет», реализуемом в рамках ФП «Технологии».
Функциональное программирование (ФП) предоставляет много преимуществ, и, как следствие, его популярность растет. Однако, каждая парадигма программирования имеет собственный уникальный жаргон и ФП не исключение. Цель этого словаря терминов — облегчить изучение ФП.
Примеры написаны на JavaScript (ES2015). Почему JavaScript?
Где уместно, в этом документе используются термины, определенные в Fantasy Land spec.
Несколько месяцев назад я зачем-то полез изучать теорию категорий. Причины были примерно те же, по которым нормальные люди иногда решают разобраться в квантовой механике по роликам на YouTube: звучит умно, выглядит загадочно, а главное – можно потом с важным лицом употреблять слово «эндофунктор» в компании людей, которые не могут проверить, несёшь ты ахинею или нет. В моём случае ситуацию усугубляла любовь к функциональному программированию, поэтому рано или поздно столкновение с теоркатом было неизбежно.
Первые впечатления были соответствующими. Категории, морфизмы, функторы, естественные преобразования, монады, знаменитое «монада – это моноид в категории эндофункторов». Я читал определения, вроде бы даже понимал отдельные слова, закрывал книжку и через пару часов снова не мог ответить на простой вопрос: а зачем мне всё это как программисту? Я пишу обычные приложения, крашу кнопки, перекладываю JSON из одного места в другое. Где в этой картине должны появиться все эти стрелочки?
Что произойдет, если AI‑программист будет получать контекст не из собственного чата, а из функциональной и архитектурной модели проекта?
ERP‑Tools совместно с Cursor пилят сайт и документируют систему.
Около 3-х лет назад, я написал статью о том, как я открыл для себя язык программирования gleam. Тогда я отметил, что gleam не так уж сильно отличается от питона.
Сейчас я решил продолжить дискурс и перенести его в практическую плоскость. Я сделал форк CPython и попросил DeepSeek немного поиграться с синтаксисом. Хорошо, что в питоне обновили парсер - он теперь достаточно гибкий.
В общем, если смотреть с формальной стороны - получился новый язык. Он немного расширяет питон (то есть, является суперсетом), но совсем чуть-чуть. Оставаясь при этом верным главному синтаксическому принципу - значимым пробелам. Целевые рантаймы для этого языка - CPython и BEAM. Они очень разные, поэтому отлично дополняют друг друга.
На картинке вы видите знак вопроса. Он связан с тем, что у нового языка пока нет окончательного названия. Есть только некоторые идеи - они связаны, простите, со свиньями. Также, в конце будет опрос - нужны ли минипиги в программировании. Ответьте, пожалуйста, это очень важно.
Привет! Меня зовут Артём. Я руководитель группы 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 для техники логического программирования.
Навайбкодить 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 и опишем языковую особенность, которая её обеспечивает — контекстные функции. Далее мы увидим некоторые недостатки этой реализации и посмотрим, как их можно решить с помощью двух языковых особенностей: одной хорошо известной (ограниченные продолжения) и одной, находящейся в разработке (нововведения в системе типов).
