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

1.1. Контекст и вызов Современные большие языковые модели(LLM) совершили рывок в обработке естественного языка, приблизившись к человеческому уровню в задачах генерации и понимания текста. Однако за внешней убедительностью ответов скрывается одна большая и существенная проблема: LLM по своей природе всё также остаются «предсказателями» следующего токена, а не системами, построенными на формальной логике или чётких онтологических моделях. Это порождает парадокс: модели, способные вести глубокие дискуссии по сложным темам, могут формировать ложные выводы или выдавать противоречивые утверждения в одном ответе.

1.2. Суть проблемы: смешение абстракций и отсутствие внутренней дисциплины
Галлюцинация не являются основной проблемой, они лишь следствие. Основная причина в
систематическом нарушении согласованности между различными уровнями обработки информации. Это проявляется в нескольких ключевых типах логических сбоев, скрывающихся в архитектуре LLM:

· Фактическая несогласованность: Ответы модели противоречат проверяемым данным или её же собственным предыдущим утверждениям в рамках диалога.
· Логическая несогласованность: Нарушение базовых правил дедукции (например, признание истинности утверждений «А → Б» и «А», но отрицание «Б») или последовательности в цепочках рассуждений.
· Контекстуальная несогласованность: Неспособность сохранять все выводы и факты при генерации сложного ответа, что приводит к искажению или полной замене исходных условий.

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

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

Разработчик, знающий только одну парадигму программирования, напоминает плотника, у которого в ящике с инструментами лежит один-единственный молоток. Конечно, молотком можно идеально забить гвоздь. Или шуруп, если приложить достаточно рвения. Но попробуйте этим молотком распилить или отшлифовать доску — и сразу станет ясно, — при условии, что вам доводилось видеть в жизни пилу или рубанок, — что инструмент выбран неудачно. Так и с парадигмами: знание только императивного программирования или только объектно-ориентированного подхода превращает разработчика в механического исполнителя задач, неспособного увидеть элегантное решение там, где оно лежит на поверхности.

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

Как работает чистый код?

Ниже моё облыжное мнение о том, почему «Чистый код» — чистой воды инфоцыганщина, и почему если вы слышите в аргументации собеседника эти слова — нужно бежать, ведь разговаривать с зомби бессмысленно.

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

Давайте посмотрим на выключатели со схем 1-7. Понятно, что выключатель №1 должен быть подключён по двум контактам (1 и 2), иначе это ошибка. А вот выключатель на схеме 2 (напомню, что штриховая вертикальная линия — это механическая кнопка, замыкающая сразу несколько контактов) должен быть подключён хотя бы по одной из пар 1-2 и 2-4. То есть, можно представить себе ситуацию, когда у нас нет в наличии простых выключателей со схемой 1, но есть ящик выключателей №2. Тогда получается, что мы должны подключать не все контакты, а только часть.

Давайте напишем маленький язык DSL, которого будет минимально достаточно для того, чтобы написать инструкцию для проверки.

Предельная унификация a.k.a. IDEAV — хранение вообще всего как список Entity — Attribute — Value с дополнительным полем ID. Звучит пугающе, но реализация скрыта под капотом, а снаружи нам доступен максимально родной и дружественный интерфейс.

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

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

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

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

Может показаться, что в современной разработке только и успеваешь, что реагировать на изменения: новые интеграции, обновленные бизнес-правила, смена технологического стека. В итоге команды тратят недели на задачи, которые должны решаться днями, а каждое новое требование встречается с сопротивлением. Но что если существует подход, который превращает постоянные изменения из головной боли в конкурентное преимущество? Сегодня мы поговорим о проектировании на основе нестабильности — архитектурной парадигме, которая позволяет системам становиться лучше с каждым изменением. 

Funxy — гибридный язык программирования со статической типизацией, pattern matching и удобной работой с бинарными данными.

Для чего подходит

Скрипты и автоматизация. Один бинарник без зависимостей — скачал и работает. Встроенная работа с файлами, JSON, HTTP, SQL.

Небольшие приложения. CLI-утилиты, API-сервисы, обработка данных.

Работа с бинарными данными. Парсинг на уровне отдельных битов. Сетевые протоколы, форматы файлов, нестандартные структуры.

Обучение программированию. Простой синтаксис, но с важными концепциями: типы, pattern matching, иммутабельные структуры данных, рекурсия с TCO (можно писать рекурсивный код без страха переполнения стека).

Статья демонстрирует построение минималистичного MapReduce-фреймворка на Scala для локальных экспериментов. Рассматриваются стадии Map, Shuffle и Reduce с ленивыми вычислениями через Iterator, а также абстракции ввода/вывода IO и локальные исполнители с виртуальными потоками.

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

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

Есть старая инженерная мудрость:

Если у вас не хватает проводов — значит, вы недостаточно творчески подходите к вопросу.

У нас была ровно такая ситуация.

Работая на одном проекте системы «умного города» мы, уйдя в стандарт «одна плата с разными конфигами для всего» решили делать на ней свой 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-ревью реально помогает, а где лид остаётся незаменим. Спойлер: место лидов в команде пока в безопасности.