В последнее время на хабре обострение навязшего в зубах еще в прошлом десятилетии синдрома обворованного.

Люди на полном серьёзе высчитывают, сколько им недодали бабла из-за налогов, поборов, неправильной фазы луны и обсуждают, как хорошо там, где нас нет. Вот, например, Штаты. Или Сомали. А тут — ух, скрытые налоги, теневой НДС, обман и насилие.

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

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

Когда-то давно, в те благословенные времена, когда программисты еще наивно полагали, что покрытие кода тестами — это показатель качества, я тоже разделял эту иллюзию. Восемьдесят процентов покрытия? Отлично! Девяносто? Великолепно! Сто? Да вы просто параноик, милейший, возвращайтесь в Скворечник, а то на ужин опоздаете.

А потом я написал библиотеку для мутационного тестирования. И понял, что все эти годы мы просто считали, сколько строк кода посещает тестовый раннер, гордясь собой, как малолетние дети, научившиеся считать до десяти.

Пара слов о том, как программисты разных конфессий справляются с самой очевидной задачей в Computer Science.

Примеры правильных и неправильных разворотов списка на десяти разных языках.

Метод программирования, именуемый аспектно-ориентированным, впервые явился миру в конце девяностых годов прошлого века, когда группа исследователей из Xerox PARC под руководством Грегора Кичалеса решила, что объектно-ориентированного подхода человечеству недостаточно. Они создали AspectJ — расширение для Java, призванное разрешить проблему, которую окрестили «сквозной функциональностью». Суть проблемы проста до безобразия: код логирования, обработки ошибок, проверки прав доступа и прочих служебных радостей размазывается по всему приложению, как масло по по́лу, превращая элегантную бизнес-логику в свалку повторяющихся конструкций.

Аспектно-ориентированное программирование предлагает выделить эти сквозные concerns в отдельные сущности — аспекты, которые можно применять к коду декларативно, не засоряя основную логику техническими деталями. В теории звучит как серебряная пуля. На практике AspectJ оказался инструментом, требующим от программиста понимания магических pointcut expressions и готовности смириться с тем, что код компилируется через специальный компилятор, производящий байткод, который отладить можно только с поллитрой, бубном или молитвенником.

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

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

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

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

Есть две категории программистов. Первая пишет тесты, вторая работает. Шутейка, конечно, на троечку, но в каждой байке, застрявшей в пабликах мёртвых заархивированных форумов, под пылью и нафталином, — можно нащупать слой гранита настоящей правды. Модное ныне «покрытие кода тестами» напоминает попытку оклеить айсберг новогодней мишурой — вроде и весело, но Титаник все равно пойдет на дно.

Я собираюсь рассказать о том, как правильно тестировать код в изоляции (интеграционные тесты — зверь из соседнего вольера, и о нем — в другой раз). Для этого нам потребуется пара определений. Фаззинг (от английского fuzzing) — это способ тестирования, при котором программе скармливают огромные объемы случайных, полуслучайных или вообще намеренно испорченных данных, с надеждой выявить уязвимости или баги. Изначально этот метод применялся в академической среде для поиска дыр в безопасности, но быстро перекочевал в руки здравомыслящих разработчиков. Property-based testing, в свою очередь, представляет собой подход к тестированию, где вместо проверки конкретных примеров типа «дважды два — четыре» мы формулируем общие свойства системы. Например: «если функция принимает список и возвращает список, то длина результата не должна превышать длину входа». А дальше уже инструмент генерирует тысячи, миллионы вариантов входных данных и проверяет, соблюдается ли это условие.

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

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

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

Чем мощнее становятся языковые модели, и чем шире они распространяются, — тем больше на нашу бедную головушку проливается дождей из лягушек. Еще десять лет назад можно было с уверенностью отличить графомана от литературно-одаренного человека, а хорошего разработчика — от вкатуна с претензией на экспертизу. Достаточно было посмотреть на пару абзацев текста (кода) — и становилось понятно: этот рифмует «кровь–любовь», а вон тот — сортирует коллекции брутфорсом.

Хороший прозаик никогда не поставит в одно предложение три прилагательных подряд, а хороший программист — не станет использовать связные списки вместо массивов под большой нагрузкой на доступ по индексу. Согласно банальной логике, эти кванторы существования обратимы: написал единожды алгоритм O(n³) там, где можно обойтись O(n·log(n)) — иди учи матчасть, а потом возвращайся к нам в теплый коллектив джунов.

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

Я поломался, поломался — и поломался на осколки. Признаю́: железные помощники Т9 действительно могут приносить пользу в разработке. Единственное, что мне не нравилось — то, что весь проект большой и хорошо натренированной модели не скормишь, а значит — неизбежны потери контекста, размывание смыслов и джойсовские галлюцинации.

Я уже давно понял: если мне нужно, чтобы что-то было сделано хорошо, — делегирование отпадает, придётся брать в руки молоток самому. Это касается любых жизненных аспектов: варки борща, замены сантехники, перевода Эдгара Аллана По или Антонио Мачадо на русский, или, там, программирования.

Когда БЯМ научились подключать сторонние MCP-сервера, произошел качественный скачок. Теперь не нужно файнтьюнить модель, можно файнтьюнить буковку «R» из акронима «RAG». Я-то лучше знаю, как правильно извлекать смыслы из моего личного контента. Если речь про код — лучше всего искать правду в AST.

Так и был зачат Ragex — MCP-сервер для семантического анализа кодовых баз с элементами чёрной магии. Проект, понятно, написан на Elixir, потому что ну а на чем еще?

joerl — это библиотека модели акторов для Rust, вдохновленная Erlang и названная в честь Джо Армстронга, создателя Erlang. Если вам когда-либо приходилось строить конкурентные системы на Erlang/OTP и вы думали: «Эх, был бы здесь хоть намек на систему типов», — то вот она, ваша прелесть. Я начинал этот проект просто потренироваться в расте немного, но меня затянуло и я довел ее более-менее до ума. Сам я на расте писать буду вряд ли, если кто-то ближе к телу захочет попробовать — буду признателен.

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

Сначала я просто хотел написать комментарий к моему предыдущему тексту, в котором я рассказал, как за день на расте мне удалось написать новую, неспецифицированную, глючную и медленную реализацию половины OTP.

Но пока я тот комментарий писал, внезапно оказалось, что, несмотря на общее положительное впечатление от раста, претензий к нему у меня набралось на целый текст. Ну что ж, заточите свои минусаторы, ниже —

Вскрытие показало, что я немного отстал от жизни, и язык программирования «Кровожадный краборжав» уже вполне себе пригоден для написания простеньких хелоуворлдов…

Ладно. В кои-то веки обойдусь без ёрничанья. Официально заявляю: я написал свою первую библиотеку на расте и мне понравилось. Раст — несомненно местами красивый и приятный для работы язык. Написание кода укладывается в зелёный диапазон плотности wtf/sec, а инструментарий заслуживает всяческих похвал (кроме кросс-публикации документации на https://docs.rs/, которая в 2025 году занимает час — хоть донаты шли, её-богу).

Итак, я написал библиотеку, которая позволит эрлангистам проще вкатываться в раст. Акторная модель притворяется краденой из эрланга, с примитивами GenServer и GenStatem, с деревьями супервизоров, с боксированными сообщениями, мэйлбоксами, и привычной терминологией. Библиотека названа joerl, светлой памяти Джо Армстронга, с которым мне посчастливилось быть знакомым, и который сильнейшим образом повлиял на менталитет разработчика во мне.

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

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

Я не говорю о бас-факторе (назовем его БФ первого рода, или БФ-1, в честь клея), который полностью спровоцирован дегенеративным дядькой, боящимся потерять работу, и оттого пишущем нечитаемый, только ему одному (им вдвоем с поллитрой) понятный, запутанный код. Если любой разработчик в команде не может, или не желает, объяснять свой код коллегам — его надо не просто выгнать, а повесить на позорном столбе перед воротам в ойти, чтобы всяк сюда входящий видел и знал, что бывает с такими вот саботажниками.

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

Надвигается очередной конец очередного года, в связи с чем люди неравнодушные к своей работе — наверняка собираются принимать участие в состязаниях «Advent of Code» в своих стеках. За последние несколько месяцев существенно ожесточились споры на предмет вайбкодинга (даже термин ублюдский придумали). Мне пришла в голову тривиальная мысль: а что, если вовлечь в соревнование ваших любимых стажё^W искусственных помощников?

Я лично собираюсь решать AoC по старинке, но при этом оставляю право AI посостязаться со мной в этом соревновании и даже обойти меня в нем. В комментариях к этому тексту я предлагаю публиковать решения, выполненные лично вами, или вашими раба^W помощниками, на всех возможных языках программирования. В англоязычном интернете — полно форумов, на которых люди делятся решениями и обсуждают их; хабр (ну, как минимум тот, про который мы иногда вспоминаем в кондитерском смысле) — идеальное место для подобных обсуждений на русском языке.

TL;DR: Cure — это функциональный язык программирования для виртуальной машины BEAM (Erlang/Elixir/Gleam/LFE), который привносит математические доказательства корректности кода прямо во время компиляции. Используя SMT-солверы (Z3/CVC5), Cure проверяет типы зависимые от значений, верифицирует конечные автоматы и гарантирует отсутствие целых классов ошибок ещё до запуска программы.

Проект выходит из стадии «наколенная поделка» и переходит в разряд «MVP».

Основная проблема IT-отрасли, на мой непросвещенный взгляд, заключается в том, что жизнь обучает нас профессии примерно так же, как учителя начальной школы — арифметике. Сначала нам говорят: делить на ноль нельзя. А потом оказывается, что ещё в XVII веке один маркиз по имени Гийом Франсуа Лопиталь научился. Нам говорят: квадратный корень можно извлекать только из положительных чисел. А потом — хоба — оказывается комплексными бывают не только обеды. И так далее.

С чего начинается обучение компьютерным наукам? — С некоторого количества теории, которая скучная и непонятная, как и любая полностью оторванная от практики теория, — а потом — с примеров. Мы открываем REPL и некоторое время забавляемся с ней, как с калькулятором.

Я не верю, конечно, ни в какую демократию (кроме оригинальной афинской 2½ тысячи лет назад, где кворум состоял из трёх с половиной образованных богатых неглупых людей, а остальные были безголосыми рабами и женщинами). Как я уже где-то говорил, существуют исторические свидетельства того, к чему привели первые проявления этой самой демократии: пару тысяч лет назад люди проголосовали распять одного там назаретянина.

Поэтому когда в качестве аргумента за ту, или иную парадигму, — я вижу какие-то индексы, голосования и прочую статистически значимую оценку vox populi, меня это раздражает. «Миллионы мух не могут ошибаться» — так себе аргумент. Поэтому мнение «коммьюнити разработчиков» — практически всегда облыжное, поверхностное, и, в целом, неверное. У каждого в руках свой молоток, а про многообразие саморезов люди en masse если и слышали, то краем уха и в качестве анекдота.

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

Несмотря на то, что сам я ушел из большого ООП¹ более десяти лет назад, причем, надеюсь, навсегда, я всегда крайне вяло и неохотно участвую в баталиях тупоконечников и остроконечников: я абсолютно убежден, что для разных типов задач лучше подходят разные инструменты, и выхолощенное ФП заставит всех вокруг создавать тонны никому не нужного бойлерплейта для тривиального круда, а кристальное ООП — воткнет все возможные палки в колёса при реализации бизнес-процессов. Любой из современных языков программирования позволяет смешивать эти подходы, а микросервисная архитектура — даже гостеприимно приютит несколько языков и сред под одной крышей.

Тем не менее, хотя я никогда не считал себя евангелистом функционального подхода, и уж, тем более, не примыкал к стану воинствующих пуристов, меня постоянно свербил вопрос: что же все-таки не так с ООП, если лично мне быстрее, проще и понятнее — реализовывать свои проекты на функциональном эликсире?

И вот, наконец, меня озарило. Объектная модель всем хороша в однопоточной среде. Даже банальная асинхронность приносит кучу совершенно нерелевантных проблем: мьютексы любого сорта — это порождение дьявола. В игрушечных примерах из книжек они езе как-то работают, но действительно _многопоточный_ код на них написать фактически нереально. Среда, которая буквально приглашает разработчика ошибиться и разрушить тотальность функций потенциальным дедлоком — не должна иметь права на существование в принципе.