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

Добро пожаловать в чистилище препроцессора — место, где здравый смысл уступает место макросам. Сегодня мы заставим C++ притвориться Haskell-ем и внедрим do-нотацию, за которую любой адепт «чистого языка» предаст нас анафеме.

Программисты на C++ делятся на два типа: те, кто боится препроцессора, и те, кто познал сие древнее чудо с сишных времён.

Сегодня мы перейдем черту. Функциональное программирование манит своими абстракциями, но когда дело доходит до цепочек вычислений в монадах, C++ встречает нас бесконечными лямбдами и вложенностью, от которой рябит в глазах. В Haskell эта проблема решена элегантным do-синтаксисом. А что, если я скажу, что мы можем получить то же самое в C++, используя лишь тёмную магию макросов, простые шаблоны и полное пренебрежение здравым смыслом?

Приготовьтесь: мы будем дорабатывать парсер и превращать ваш код в нечто, что заставит коллег вызвать экзорциста. Это история о том, как затащить чистую красоту монад в суровый мир C++.

Доброго Здоровья!
Предполагается, что статья будет интересна тем, кто любит четкие контракты в своих проектах, строгость и чистоту в инкапсуляции, новые подходы в ООП. А также тем, кто уважает функциональное программирование.
Эти темы и затрагиваются в предлагаемом «Elvis-модификаторе доступа», реализованным через Roslyn Analyzer. Все исходники и nuget пакеты прилагаются.

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

Python славится своей гибкостью. Мы можем передавать функции как аргументы, возвращать их из других функций и даже "записывать" внутрь них состояние. Но как это работает под капотом? И при чем тут странное слово nonlocal?

В этой статье мы проследим эволюцию: начнем с глобальных переменных, разберемся с замыканиями (closures), поймем магию nonlocal, а затем соберем всё это вместе, чтобы понять, как работают декораторы — один из самых элегантных механизмов Python.

Hobbes - это функциональный язык программирования со статической типизацией, написан на С++ и включает JIT-компилятор на базе LLVM. Похож на Haskell, но совсем не такой же революционный и гораздо менее известен. Я немного расскажу, что это за язык и как он устроен внутри.

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

Всем привет! Меня зовут Сергей и последнее время я занимаюсь backend-разработкой на Scala. Вообще, мой опыт асинхронного программирования на Scala и C# составляет более десяти лет, и за это время сложилось вполне достаточное понимание этой темы. Во всяком случае, тогда мне так казалось…

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

В мире Python есть особый вид функций — невидимки. У них нет имени, документ-строки и даже нормального тела. Они живут одну строку и умирают, сделав свое дело. Это лямбда-функции.

Многие новички считают их бесполезной игрушкой или, наоборот, пытаются запихнуть всю логику в одну лямбду, превращая код в нечитаемое месиво. В этой статье мы разберемся, где проходит эта грань. Мы не просто выучим синтаксис lambda x: x, мы поймем, как они устроены внутри, как их использовать с инструментами вроде map, filter, sorted, и главное — когда от их использования стоит категорически отказаться.

Работа с переменными в Python кажется очевидной до тех пор, пока код не начинает вести себя неожиданно. Ошибки с UnboundLocalError, странное поведение замыканий или некорректная работа global и nonlocal - всё это следствие непонимания области видимости.

В Python действует чёткое правило разрешения имён - LEGB. Разберёмся, как оно работает и какие ловушки скрываются под капотом.

В статье рассматривается реальная ограниченность современных больших языковых моделей (LLM) при разработке сложных электромеханических систем, включающих аналоговые и цифровые датчики, шаговые и серво‑приводы, а также различные исполнительные устройства. Показано, что хотя нейросети способны быстро генерировать черновые схемы, фрагменты кода и шаблоны технической документации, они не обладают знанием физического контекста, параметров компонентов, нормативных требований и бизнес‑целей проекта. Поэтому без участия инженера‑генератора идеи и программиста‑интегратора полученный результат остаётся непроверенным и потенциально ошибочным. Приведены практические примеры из реальных проектов (генерация драйверов для шаговых двигателей, автоматическое написание тест‑скриптов, составление ТЗ и подбор компонентов), где LLM выступали лишь ускоряющим инструментом. Описаны рекомендации по эффективному использованию нейросетей: чёткое ТЗ, разбиение задачи на небольшие блоки, обязательная верификация и сохранение контекста. Делается вывод, что нейросети сейчас являются полезными помощниками, но не заменой человеку в роли идеи и интеграции.

Два месяца назад я писал на Хабр о первом релизе Funxy — гибридного языка программирования. Тогда это был эксперимент по созданию своего языка с выводом типов, императивного, с функциональными возможностями.

С тех пор вышло несколько релизов. Мы исправили много ошибок, переписали рантайм и добавили недостающие инструменты. Хочу рассказать, что изменилось.

Стабильность: десятки багфиксов — падения на валидном коде, рекурсия, edge-кейсы VM

Рантайм: tree-walk интерпретатор → стековая VM (быстрее, легче по памяти)

Язык: const, return, лямбды (\x -> x + 1), list comprehensions, block syntax для DSL

Типы: strict mode, flow-sensitive typing

Тулинг: LSP и дебаггер

Embedding: встраивание Funxy в Go-приложения как скриптовый движок

Здравствуйте, меня зовут tmaxx, и я алкоголик понял что такое монады. И, естественно, рассказываю об этом всем вокруг, в том числе и вам. Конечно, это Далеко Не Первая Статья О Монадах на Хабре, но ещё один альтернативный взгляд на проблему, думаю, не помешает.

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

(>>=) :: forall a b. m a -> (a -> m b) -> m b
return :: a -> m a

Не понятно на Хаскеле? Вот примерный эквивалент на Java:

<A, B> Monad<B> bind(Monad<A> ma, Function<A, Monad<B>> famb); <A> Monad<A> ret(A a);

Все равно остались вопросы? Почему именно такая сигнатура? Что в ней такого особенного, что она используется абсолютно во всех реальных программах написанных на функциональных языках? Попробуем разобраться.

В Python код является данными. Функции, классы, модули и даже стек вызовов можно исследовать во время выполнения программы. Этот механизм называется интроспекцией.

Интроспекция активно используется во фреймворках, логировании, тестах, dependency injection контейнерах и отладчиках. При этом многие разработчики пользуются ей неосознанно.

Разберем, что это такое, зачем нужно и как применяется на практике.

Привет! Меня зовут Артём. Я Scala Tech Lead в компании “Криптонит” и автор Scalabook — русскоязычной базы знаний по Scala и функциональному программированию. В прошлой статье я разбирал можно ли программировать без циклов. Сегодня хотелось бы подлить масла в огонь и продолжить разбирать альтернативы императивным циклам в мире функционального программирования.

Данная статья посвящена свёрткам (folds) и развёрткам (unfolds). Это модели вычислений, работающие поверх рекурсивных типов данных, таких как связанные списки, деревья и т.д. Свёртки и развёртки образуют мощную пару абстракций: если свёртки предназначены для потребления рекурсивных структур данных, то развёртки ответственны за генерацию структур данных из некоторого начального состояния.

Допустим у нас есть связанный список:

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

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

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

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

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