Ранее мы выяснили, что монадные возможности присущи эндофункторам, основанных на определённых ковариантных обобщённых типах. Обобщённые же типы соответствуют алгебраическим выражениям, собранным из сумм, произведений и экспоненциалов типов.
В этой части обзора мы увидим, почему конструкторы типов связаны с алгебраическими операциями, и как сама эта связь порождает монады и комонады.
Есть старая инженерная мудрость:
Если у вас не хватает проводов — значит, вы недостаточно творчески подходите к вопросу.
У нас была ровно такая ситуация.
Работая на одном проекте системы «умного города» мы, уйдя в стандарт «одна плата с разными конфигами для всего» решили делать на ней свой BMS. Зачем да почему? Нужно было универсальное решение, которое должно работать и с литиевыми, и со свинцовыми батареями, и с ещё парой экзотических химий, встречающихся в природе примерно так же часто, как радужные единороги. Нужно было надёжно определять тип батареи, считывать её состояние, пригодность к использованию, дату производства и всё‑всё‑всё подобное, блокировать несовместимые варианты и вообще предотвращать самое главное — человеческую ошибку. Но как это часто бывает в компаниях где в R&D священный хаос — никто и не задумывался чтобы сесть и обсудить «А как мы вообще это делать будем». В производство ушла тысяча плат.
В любой другой ситуации мы бы пошли по наименьшему пути сопротивления: i2c на коннекторе рядом и EEPROM на аккуме. Но не тут было.
Привет, Хабр! Меня зовут Артём. Я руковожу группой Scala‑разработчиков в компании «Криптонит» и веду Scalabook — русскоязычную базу знаний по Scala и функциональному программированию. В ней можно найти другие мои статьи‑инструкции, а также примеры кода. В этой статье предлагаю обсудить циклы и связанные с ними спорные моменты.
Если вы когда-нибудь задумывались о написании своего языка программирования, в особенности функционального, то должны быть в курсе, что лямбда исчисление — это основа всех функциональных языков. Я решил сделать цикл статей, где мы будем реализовывать интересные алгоритмы, используемые в компиляторах, а также различные исчисления. Лямбда‑исчисление — это фундамент, с которого я и предлагаю начать погружение в эту нору.
Премьера! Драматическое признание в любви (к Ф...).
100 рублей и 100_000 юаней!
Реализации аналогов друзей в C#, различные подходы, сравнительный анализ. Элвис жив!
Вах, заходи дорогой(-ая), другом будешь!
Это началось со статьи «Алгебраические типы данных на самом деле не такие страшные». Мы знаем о типах‑суммах и типах‑произведениях. Но задумывались ли вы когда‑нибудь о том, откуда они получили такие имена, и как вообще были открыты они и их свойства? Я провел последнюю неделю в кроличьей норе истории, и я просто обязан поделиться тем, что я нашёл.
И вот, в четвёртой части обзора мы наконец-то встретимся с главным героем! Мы рассмотрим анатомию и морфологию монад и попробуем выяснить, почему их бывает сложно композировать. Попутно познакомимся с аппликативными функторами и комонадами.
Всем привет! Меня зовут Михаил, я веду Telegram-канал «Python Шпильки», где делюсь изящными приемами программирования. Сегодня я хочу рассказать об универсальном декораторе, который может принимать аргументы, а также вызываться без их приема. Для тех кто хорошо знает тему декораторов - ничего нового они тут не увидят! Этот пост для тех, кто, возможно, хочет более подробно понять тему декоратора. Итак, поехали.
Для начала приведу пример конструкции универсального декоратора:
Привет, Хабр! Меня зовут Артём Корсаков. Я руководитель группы серверной разработки в компании "Криптонит". Пишу на Scala и веду проект scalabook.ru. В этой статье мы разберём основы функционального программирования (ФП) на примерах и с поправкой на суровую действительность.
Многие слышали о преимуществах ФП, но пока не понимают, как применить эти концепции на практике. Теория монад и функторов и вовсе отпугивает, кажется чем-то заумным и непонятно где применимым. Поэтому мы отбросим сложную теорию и сосредоточимся на основных моментах, которые вы сразу сможете начать использовать в своём коде.
Введение
Мы часто говорим об алгоритмах как о «сердце» любой сложной системы. В контексте нашей платформы Гриндаты алгоритмы — это не просто код. Представьте, что данные — это деньги или документы клиентов, а алгоритмы — это инструкции и правила, которые позволяют быстро находить, сортировать, обрабатывать и сохранять эти «деньги/документы».
Процесс создания алгоритма для бизнес‑логики всегда начинается с декомпозиции действий. Далее мы переводим эти действия на алгоритмический язык, подбирая оптимальные пути решения. Но чтобы делать это быстро и эффективно, необходима прочная концептуальная база.
Формулы удачного написания алгоритма не существует, поскольку задачи всегда разного толка и сложности. Однако понимание основных парадигм программирования — это первый и главный ключ к написанию оптимально работающих алгоритмов. Наши алгоритмы являются мультипарадигменными, поэтому рассмотрим два основных подхода, лежащих в их основе: ООП и ФП.
Концептуальная основа: ООП (Объектно‑ориентированное программирование)
Концепция ООП лежит в основе структуры и окружения нашей платформы. Понимание ООП необходимо аналитику для:
Привет, Хабр!
Последние пару лет часто возникает вопрос: «А может ли ИИ заменить тимлида на code review?». Вопрос созрел не на пустом месте – инструменты на базе LLM теперь умеют и подсвечивать баги, и предлагать правки к pull request. Хайп подогревают отчёты: 84% разработчиков уже используют или планируют использовать ИИ в работе. Однако доверие к таким ассистентам хромает: почти 46% инженеров активно не доверяют ответам ИИ (против 33%, кто доверяет). Получается парадокс: пользуемся – но проверяем. Давайте разберёмся, где AI-ревью реально помогает, а где лид остаётся незаменим. Спойлер: место лидов в команде пока в безопасности.
Многие мои собеседники "стопроцентно" уверяли меня, что сама суть функционального программирования заключается в повсеместном использовании map, filter и reduce; что эти функции превосходят циклы for во всём, настолько, что их нужно запихнуть в каждый возможный язык безо всякого анализа затрат и выгод, потому что выгоды настолько несравненно потрясающие, что затраты просто не могут иметь значения. А само сомнение в этих затратах уже доказывает, что я ничего не понял. Поэтому пора задать главный вопрос: действительно ли именно они (map, filter и reduce) и есть ядро функционального программирования?
К чёрту теорию; давайте посмотрим на практику. Давайте взглянем на реальный проект на Haskell. Я знаю два крупных проекта на Haskell, которые вышли за пределы хаскель-экосистемы и стали полезными программами, которые люди скачивают: xmonad и pandoc. Но xmonad - странная программа: она делает массу привязок к библиотекам C и взаимодействует со всевозможными системными сервисами…Что, конечно, неплохо, как говорится, но из-за этого она не очень типична. А вот pandoc - это чистейший Haskell: парсинг, работа с абстрактным синтаксическим деревом, его трансформация и генерация; т.е., по сути, огромный компилятор для документов. Более «хаскельским» код быть не может. Давайте посмотрим на него.
Что действительно делает программу великой? Скорость работы, поражающая воображение? Лаконичность и изящество кода, восхищающие коллег? Или, быть может, Архитектура, обещающая вечную гибкость? Тысячи лет все эти империи рушились перед лицом коварной Ошибки. Пришло время провозгласить манифест иной истины: высшая ценность программы — её Достоверность, и цель разработки — доказать, что программа безупречно воплощает замысел своего создателя. В данной статье мы рассмотрим инструменты и методы, которые превращают намерение программиста в неопровержимую теорему. Через формальную верификацию тривиального, но коварного ФиззБазза средствами Idris 2 мы покажем, как строить программы, чья правильность не вера, но математический факт. Зависимые типы — наш меч. Добро пожаловать в мир, где код не просто работает — он доказан.
Мы пытались закрыть пробелы в доказательстве в Lean 4. Но вместо решений получили 120 000 токенов объяснений и одно слово: sorry. Из этого вырос философский трактат о природе формальных доказательств.
Всем привет! Меня зовут Артём Корсаков, я руковожу группой разработчиков на Scala в компании «Криптонит». Хочу рассказать про мой проект, которым я занимаюсь уже 4 года — Scalabook.
За последние 20 лет язык Scala завоевал прочные позиции в backend-разработке, машинном обучении, обработке данных, создании распределённых систем и во многих других областях. Есть тысячи ресурсов по Scala: книги, статьи, курсы, подкасты, проекты с открытым исходным кодом, хакатоны и специализированные мероприятия, вроде Advent of Code. Однако часто возникают вопросы: с чего начать изучение Scala, или как систематизировать уже имеющийся опыт?
Вот так у меня и появилась идея создать русскоязычную базу знаний по Scala — Scalabook. Это уникальный проект, в котором представлены материалы о функциональном программировании, алгоритмах и структурах данных, классах типов, переводы статей, а также ресурсы различного уровня сложности для изучения Scala. Это собрание материалов по разным темам в русскоязычном пространстве.
Также уделено внимание практическим аспектам функционального программирования: создан тренажёр с набором задач возрастающей сложности, которые позволяют освоить ключевые концепции функционального программирования на Scala.
На сайте можно оставлять комментарии, получать обратную связь по решениям задач или предлагать дополнения для расширения базы знаний. Scalabook регулярно обновляется: добавляются новые упражнения, пояснения и материалы. Пользователи также могут внести свой вклад в этот процесс. Таким образом, изучение Scala становится более систематизированным, а не просто набором разрозненных ресурсов, в которых легко запутаться. Scalabook способствует обмену знаниями в сообществе Scala.
Одна из самых эзотерических тем в программировании и computer science это продолжения (continuations), ограниченные продолжения (delimited continuations) и continuation-passing style. Я попытаюсь раскрыть эту тему понятным для обычного программиста языком. Предполагается, что обычный программист знаком с понятиями функции/подпрограммы, фрейма вызова (stack frame), а также имеет базовое знания языка Scheme, хотя бы на уровне первых глав SICP.
«В последнее время все меньше иностранных компаний остаются доступны в России. В связи со сложными внешнеполитическими процессами, внутренний рынок требует все больше отечественных независимых „импортозамещающих“ разработок во всех сферах производства, включая и горную промышленность.»
Примерно с такой формулировкой к нам обратилось одно крупное предприятие из области добывающей промышленности.
---------------------------------------------------
На большинстве крупных предприятий так или иначе всегда присутствует конвейер. Вещь очень полезная, тем более если необходима постоянная транспортировка материала из цеха в цех, на переработку или куда‑нибудь еще. В нашем случае, точнее в случае заказчика, конвейер установлен в цехе среднего дробления и задача его — загружать руду в мельницу, для получения более мелкой фракции на выходе.
Это вторая вводная часть обзора, посвящённого применению теории категорий в программировании. В первой части представлены некоторые основные определения теории, в том числе, hom-типы, их значения-морфизмы, а также их композиция, позволяющая строить пути вычислений в рамках одной категории. В данной же публикации мы рассмотрим, как пути вычислений можно прокладывать через разные категории.
Моя повседневная работа с основном связана с языком Elm. Благодаря сочетанию функционального языка и архитектуры Elm, многие архитектурные решения в нём получаются практически незаметными (подробнее об этом я рассказываю в этом посте у меня в блоге). Вы получаете четкое разделение задач, а язык по умолчанию подталкивает вас к хорошему проектированию.
Но моя работа не ограничивается Elm. Я часто создаю функции, которые охватывают как фронтенд, так и бэкенд — пишу новые конечные точки, а иногда даже проектирую новые таблицы баз данных. Когда я выхожу за пределы мира Elm, я вспоминаю, что архитектура — это то, к чему я должен снова относиться сознательно.
Этот пост не о том, какой код идет в какой слой, и не о конкретных паттернах проектирования. Прежде всего, я хочу поговорить об обманчиво простом выборе: следует ли просто реализовать то, что вам нужно, или же лучше начать с создания абстракции?
