Главной темой форума 3 апреля 2026 года станет путь к инновационному и высокотехнологичному государству.
Не прячась за красивыми словами перейдём к делу: ниже вкратце описаны основные шаги и проекты стратегии по развитию и процветанию России до 2100 года.
Привет, Хабр!
Парсер‑комбинаторы и синтаксический анализ в целом — очень интересные темы. Однако материалов со сравнительно низким порогом входа маловато, а в существующих статьях на читателя сразу обрушивается поток терминов и формальностей.
Эту статью я позиционирую как введение в парсер‑комбинаторы «для чайников» (или «для самых маленьких» — как вам больше нравится). Цель: попытаться рассказать простым языком и с примерами так, чтобы Вы могли после прочтения написать свой парсер без какого‑либо предварительного опыта и знаний в области синтаксического анализа.
Приятного чтения!
Системные программисты годами живут в вынужденном компромиссе. Когда вы пишете ОС, гипервизор или драйвер ядра, у вас два пути. Первый — чистый ассемблер (NASM/GAS), где вы имеете 100% контроль над железом, но теряете систему типов и тонете в ручном управлении памятью. Второй — использование inline asm вставок в C/C++, которые превращают ваш код в строковый «черный ящик», ломают пайплайн оптимизатора и могут взорваться в рантайме из-за ошибки в одной букве (Fragile Constraints).
Мы решили исправить эту историческую несправедливость.
Спустя месяцы безумной разработки мы представляем AsmX Raptor Engine — первый в мире конвейер компиляции, где высокоуровневая типизация и машинные инструкции живут в едином, неразрывном абстрактном синтаксическом дереве (AST).
В этой статье мы заглянем под капот нового движка и разберем:
Frontend-Backend Split: Как Pratt Parser (алгоритм сортировочной станции) и логика lookahead навсегда избавили нас от костылей C++.
Reference Collapsing и CV-квалификаторы: Почему наш тайпчекер ударит вас по рукам, если вы попытаетесь перезаписать const или неправильно примените reinterpret_cast<T>.
Kernel-Mode Orchestration: Как мы научили компилятор быть Version-Agnostic и собирать модули ядра (.ko) под любую версию Linux на лету через вытягивание метаданных из dmesg.
Operand Bridge: Трансляция абстракций в интеллектуальные инструкции железа.
Мы не пытаемся заменить C++. Мы возвращаем инженерам абсолютный контроль над каждым байтом, не лишая их мощи статического анализа. Добро пожаловать в манифест эффективности AsmX Raptor.
Если в настоящее время вы являетесь Go-разработчиком, то вне зависимости от того, из какого языка программирования пришли в Go, вы наверняка когда-то задавались вопросом «А есть ли тут тернарный оператор?»
А вы знаете что в СССР у нас были свои языки программирования? Что ж, почему бы нам не посмотреть что мы можем возродить?
В этом тексте я покажу как собрать прошивку при помощи компилятора IAR и GNU Make файлов.
Собрать прошивку компилятором IAR с помощью GNU Make — это не просто возможно, это стандартный подход для автоматизации сборки, например, на CI/CD серверах, где использование IDE неудобно. IAR поставляется с набором консольных утилит, которые делают этот процесс вполне прямолинейным.
Это не отдельная статья, а продолжение статьи про теорию объектов в с++, почему объекты в плюсах такие какие есть. Все завершенные главы я также выкладываю на github'e в английском и русском варианте. Продолжаем разбираться в теории С++...
Отдельного разговора заслуживает идентичность объектов, потому что в реальном мире конкретные сущности обладают идентичностью и Сократ останется Сократом независимо от того, перекрасил ли он волосы, сменил адрес или умер, а государство остаётся тем же государством, даже если меняет флаг, конституцию или размер населения.
Чтобы отразить это в программе, объекты, представляющие конкретные сущности, нуждаются в своём определении идентичности, которая отделена от текущего состояния. Удобный способ ввести такую идентичность будет сделать некий токен идентичности, уникальное значение, которое выражает "кто это", а не "в каком он сейчас состоянии". Таким токеном может быть, например, адрес объекта в памяти, индекс в массиве, или табельный номер сотрудника в кадровой системе и проверяя равенство токенов идентичности, мы фактически проверяем тождественность объектов: один и тот же объект или разные.
На протяжении жизни программы конкретный объект может менять свои токены идентичности, потому что его могут переместить в другой участок памяти или переложить из одного контейнера в другой, или назначить ему новый идентификатор, но логическая идентичность сохраняется, если мы поддерживаем сопоставление между "старым" и "новым" токеном.
Если вы хоть раз встраивали Lua в свой проект — будь то игровой движок, высоконагруженный веб-сервер на OpenResty или конфигуратор сложного сетевого оборудования — вы знаете, за что мы его любим:)
А любим мы его — за компактность, быстроту, встраиваемость и предсказуемость. Не любим — за аскетичный синтаксис, отсутствие привычных конструкций и постоянное «изобретение велосипеда».
Эта статья — обзор диалекта Lattelua: зачем он нужен, чем отличается от других диалектов, и почему его особенно удобно использовать в уже существующих проектах, где Lua — встраиваемый язык.
UHT сгенерировал 4294 строки кода из одного моего заголовочного файла. Имена свойств, смещения в памяти, флаги сериализации, exec thunks для каждой функции - всё, чтобы движок в runtime знал о классе то, что C++ забывает после компиляции. Это третья и последняя статья в серии про внутренности Unreal Engine: K2Node → Blueprint VM → рефлексия. Разбираем, что внутри этих четырёх тысяч строк, зачем каждая из них, и как ими пользуются Details panel, GC, репликация и сама Blueprint VM.
Этот пост написан по мотивам выступления, с которым мы с Шисянь Ван ездили на конференцию Rust UnConf, организованную нью-йоркским сообществом Rust. Конференция UnConf собрала поистине потрясающий коллектив энтузиастов a Rust, в компании которых мы более двух часов посвятили глубоким техническим дискуссиям (а также поеданию мороженого). Далее при необходимости я буду ссылаться на опыт нашей компании Antithesis.
Каждый раз, когда вы соединяете ноды в Blueprint и нажимаете Play, Unreal Engine запускает маленький процессор. У него свои инструкции, свой стек, своя защита от бесконечных циклов. Он написан в ~4000 строках C++ и живёт в одном файле. Через него проходит каждый Event Tick, каждый Event BeginPlay, каждый вызов Blueprint-функции.
Этот процессор - Blueprint VM (Virtual Machine). И сегодня мы разберём его по винтикам.
Обратная сторона лаконичности знаков в языках программирования. Правила отсеивания неподходящих вариантов при выработке системы знаков для языка программирования.
Пока индустрия движется в сторону усложнения компиляторов, я задался вопросом: можно ли создать инструмент, который дает безопасность Rust, гибкость C и при этом не весит сотни мегабайт?
Так появился Flame — системный язык с компилятором в 226 КБ, который реализует управление памятью через статический анализ AST и предлагает альтернативный взгляд на обработку ошибок через патчинг дерева токенов.
Нередко при оптимизации приложений, написанных на языках со статической компиляцией (C, C++, Rust), наступает момент, когда стандартные методы оптимизации, такие как улучшение алгоритмов, подбор структур данных, флаги компиляции вроде -O3, перестают давать дополнительный прирост производительности. В этот момент многие вспоминают про фундаментальное ограничение статических компиляторов. В отличие от JIT, они не знают, какой код будет горячим, а какой холодным. JIT-компиляторы (JVM, V8, .NET) получают эту информацию в runtime и адаптируют оптимизации под реальную нагрузку. Статические компиляторы генерируют машинный код заранее и лишены информации о поведении программы в runtime. Для решения этой проблемы используется подход Profile Guided Optimization (PGO). Он позволяет собрать данные о выполнении программы и передать их компилятору для принятия более оптимальных решений при генерации кода. По сути, PGO - это способ дать статическому компилятору некоторые преимущества JIT, сохраняя при этом все преимущества ahead-of-time компиляции: отсутствие пауз на перекомпиляцию и полный контроль над билдом.
В наше время программирование стало очень доступным из-за развития инструментов и языков. Написать «привет, мир» может практически каждый, а количество фреймворков для JavaScript уже воспевается в шутках. Теперь, чтобы выделиться и впечатлить друзей и коллег, нужно спускаться глубже. Придумаем свой язык шуточный программирования!
В этой статье кратко рассмотрим базу компиляторов и мемные эзотерические языки программирования. В конце придумаем свой язык и попробуем его реализовать.
Это упрощенная статья, которая расширит ваш кругозор, а у некоторых вызовет интерес и любопытство погрузиться в тему.
Представьте, что вы читаете громкий заголовок: «Самая простая Turing‑complete архитектура SUBLEQ (всего одна инструкция!) и реализовали её на фотонных логических вентилях». Звучит как настоящий прорыв из научной фантастики — один‑единственный тип команды, и вот уже у нас полноценный универсальный компьютер, работающий на скорости света, без кремния, без транзисторов, с терагерцевыми частотами и энергопотреблением в разы ниже.
Но если копнуть глубже, сразу вылезают два больших «но». Первое — SUBLEQ действительно может быть Turing‑полной, но только при очень конкретных условиях. Второе — реализовать даже такую «простую» архитектуру на настоящих фотонных вентилях в железе оказывается совсем не тривиальной задачей. И именно об этом мы сегодня поговорим подробно, без хайпа, но и без излишнего скепсиса.
Эта статья — разбор реальной истории, которая происходит прямо сейчас, в 2026 году. Немецкий стартап Akhetonics из Мюнхена всерьёз взялся за all‑optical general‑purpose processor и выбрал для доказательства концепции именно SUBLEQ. Мы пройдёмся по всем нюансам: от теории одной инструкции до проблем фотонной памяти, от лабораторных прототипов до того, почему чистый SUBLEQ, скорее всего, останется красивым PoC, а в реальном продукте придётся расширять набор команд.
Готовы? Поехали.
Я занимаюсь разработкой компиляторов, то есть, пишу программы, преобразующие программы в программы. Иногда требуется нацелиться на более высокоуровневый язык, чем, скажем, простой ассемблер, и зачастую именно в таком качестве удобно взять язык C. Генерировать C не так страшно как писать от руки — в частности, потому, что генератор умеет не попадать в ловушки, связанные с неопределённым поведением. А когда пишешь на C вручную, именно неопределённого поведения следует особенно остерегаться. Здесь я опишу некоторые паттерны, которые обнаружил сам, и которые помогают мне результативно работать.
Считайте этот пост краткой подборкой тех вещей, которые мне действительно помогают. Рискуя, что меня могут обвинить в тщеславии, назову их «наилучшими практиками», хотя, это действительно мои рабочие практики, поэтому, если они вам понравятся — смело берите их на вооружение.
Признаюсь, я питаю слабость к классическому DOOM. Игре уже 31 год, но благодаря открытому исходному коду она живёт на всём — от смартфонов до осциллографов. В силу разных обстоятельств я стал сопровождать несколько пакетов, связанных с DOOM, в Fedora Linux.
Перед каждым релизом Fedora проводит массовую пересборку всех пакетов — и в этот раз chocolate-doom её не пережил. Виновник этому — маленький bool.
Язык активно улучшается, осталось недолго до bootstrapping'а! Также уменя есть планы писать LSP и загрузить язык на github linguist. Для последнего нужны репозитории (>200). Для тех, кому нечего делать, или кому просто не лень, попробуйте пописать программки на моем языке. Пока мало что можно будет написать, но, думаю, хотя бы что-то можно.
