C++ *

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

У длинной задачи возникают две практические проблемы. Первая: разработчику нужно уточнить одну деталь, но новое сообщение может вмешаться в текущую последовательность действий. Вторая: правило, переданное модели в начале разговора, постепенно отдаляется от текущего шага и может перестать влиять на ответ.

В Veai 5.16 для этих сценариев появились команда /btw и параметр strictness. Ниже разберём механику обеих функций, их ограничения и влияние частого повторения инструкций на контекст модели.

Все мы знаем, что языки делятся на динамические и статические: Python или JS позволяют молниеносно прототипировать, но расплачиваться нестабильностью в продакшене приходится потом, тогда как C++, Java или C# требуют прописывать типы сразу, оплачивая монументальную надежность замедлением разработки.

В 2006 году Джереми Сиек предложил разрешить этот конфликт концепцией постепенной типизации в работе «Gradual Typing for Functional Languages»: язык остается динамическим по умолчанию, однако разработчик может аннотировать типами отдельные модули или функции, не покрывая ими всю кодовую базу, а типизированный и нетипизированный код взаимодействуют через специальный динамический тип Dyn. Звучит как сказка — быстрое прототипирование с постепенным наращиванием стабильности. Однако при детальной проработке вскрылись фундаментальные нюансы: в серии последующих работ Сиек, Таха, Вадлер и другие показали, что стыковка типизированного и нетипизированного кода требует операции приведения типа (cast), а дизайн этого каста упирается в противоречие между тремя желаемыми свойствами — надёжностью системы типов (soundness), собственно постепенностью (gradual typing) и отсутствием рантайм-обёрток на границах (no wrappers).

Позднее сообщество, и я в том числе, переосмыслило третью вершину: no wrappers — это забота о производительности и прозрачности рантайма, безусловно важная, но с позиции программиста, а не математика-оптимизатора, правильнее говорить о удобстве разработчика (developer-friendly). Это свойство вбирает в себя no wrappers как частный случай, добавляя понятные сообщения об ошибках, низкий порог входа и отсутствие многослойных типовых аннотаций, ведь если ради производительности приходится городить бесконечные теоремы типов, такая система едва ли приживётся на суровом рынке опенсорса.

Так родилась трилемма Святого Грааля системы типов: выбрать можно любые два свойства, а третье неизбежно пострадает, и в этой статье мы разберём, как создатели языков пытались достичь всех трёх и на какие компромиссы шли.

Всем здрайвствуйте я Titled и я создал форк llama.cpp где реализовал все свои жаветные мечты сейчас расскажу что это было и почему я написал такооой длиный заголовок.

Разберем как я это реализовал и почему это может вам помочь !

Я заметил, что стал копипастером задач в ИИ-агента и обратно, а из программиста превратился в GUI-тестера. Не самая моя любимая работа.

Сначала наваял простой скрипт на Python: сделать скриншот, ткнуть мышью в координаты. В итоге тихим сапом это выросло в круглосуточный конвейер, который ведёт задачу от тикета в YouTrack и общения с пользователем до доказательства в живом 2D/3D-интерфейсе и коммита. И ещё писатель документации со скриншотами в придачу.

Рассказываю, как оно росло, какие были грабли и сколько строк в итоге занял наследник того самого «простейшего скрипта».

Вот в github:
https://github.com/Divetoxx/Piano

🎹 Основная философия: «Ритмическое дирижирование без ошибок»
Главное новшество этого фортепиано заключается в том, что пользователю никогда не нужно беспокоиться о неправильном воспроизведении нот.
Идеальная высота звука (Гц): Каждая частота и высота звука точно запрограммированы в плотные векторы нот. Математически невозможно сыграть неправильную ноту или допустить ошибку!
Время ваше: Время, интервалы и эмоциональный темп совершенно не ограничены. Нажимая на клавиатуру или мышь, ВЫ динамически создаете ритм и временную структуру. Вы не просто нажимаете на клавиши — вы дирижируете шедевром!

CONTRACT умеет писать protobuf-совместимый wire-формат — и в 20 из 28 замеров обогнал по скорости настоящий libprotobuf, включая его собственный сгенерированный protoc-код. Разбираем три инженерных решения, которые это дали, и два сценария, где не получилось. CONTRACT — это C++ библиотека сериализации без кодогена и рантайм-рефлексии: схема объявляется один раз, в самой C+±структуре, и работает сразу под разные форматы.

Docker для userver удобен, но не обязателен. Как поставить зависимости через apt, собрать сервис нативно на Ubuntu и не утонуть в первой компиляции.

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

На Хабре периодически появляются статьи с анализом феномена Python - как один из самых медленных языков программирования стал королём нейросетей, и ответ всегда один: за счёт простого синтаксиса и развитой экосистемы. Но экосистема у C++ значительно больше и богаче, значит, дело не в ней и остаётся только синтаксис. А если проблема действительно в синтаксисе, тогда должен быть ответ и на другой вопрос: почему C++ не стал основой для исследований в этой (или любой другой) области?

Раньше я уже подходил к вопросу об эмпирической оценке сложности синтаксиса языков программирования, что называется «в лоб»: взять исходный код компилятора и посмотреть, сколько строк в нём занимает синтаксический анализатор. Ведь чем сложнее синтаксис, тем больше кода нужно, чтобы его распознать. И сотни тысяч строк кода только на анализ синтаксиса C++ - это измеримое свидетельство того, в какого монстра превратился C++ за сорок лет развития.

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

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

Часть 1 цикла о программировании Apple Scalable Matrix Extension (SME2) — от первых принципов до промышленной реализации GEMM.

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

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

SQL породил особую касту DBA (Database Administrators) и Data Engineers и сегодня человек, который пишет "простые запросы", может легко зарабатывать на уровне мидла, а сам язык стал настолько сложным, что современные диалекты (PostgreSQL, Oracle) - это полноценные языки программирования с процедурной логикой, где можно написать всё что угодно, от генератора фракталов до игрового движка.

Семейство 4GL оказалось "золотой клеткой" и прекрасно работали, пока нужно было сделать типичную форму "ввод-вывод", но как только требовалась нестандартная бизнес-логика или интеграция с внешним сервисом, инструмент упирался в свои границы и программистам приходилось дописывать "костыли" на низкоуровневых языках, что превращало разработку в адский коктейль из визуального дизайна и грязных хаков. И вместо исчезновения программистов, 4GL создали "архитекторов корпоративных систем", которые (например, SAP ABAP), стали невероятно дорогими специалистами, и тоже не устранил программирование, а просто переместил его из зоны "универсальных языков" в зону "дорогих и капризных инструментов", привязывающих компанию к конкретному вендору.

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

Как часто вы слышали: «Не доверяй компилятору, пиши вручную»? Похоже, эту идеологию пора сдавать в архив.

Автор специально собрал примеры, в которых «умный» код современного C++ либо проигрывает наивному, либо не даёт выигрыша, но при этом ухудшает читаемость и мешает оптимизатору. Тут и легендарный Q_rsqrt, и бит-хаки для подсчёта единичек, и вездесущие const&, и даже опасные фокусы с фильтрацией диапазонов. Всё с воспроизводимыми бенчмарками на Clang 21 и Ryzen 9. Если вы готовы пересмотреть багаж старых привычек – просим под кат.

Привет, Хабр!
Это первая статья из планируемого цикла про мой объектно-ориентированный подход к написанию кода для микроконтроллера stm32 (а именно камня stm32f303vc на отладочной плате stm32f3discovery) с использованием возможностей языка вплоть до стандарта c++20. Но обо всём по порядку.

Если вы когда-нибудь собирали проекты на C++, то практически наверняка получали ошибку от линковщика формата:

/usr/bin/ld: /tmp/ccYa2eaO.o: в функции «foo()»: foo.cpp:(.text+0x0): повторное определение «foo()»; /tmp/ccKEs5I7.o:main.cpp:(.text+0x0): здесь первое определение collect2: error: ld returned 1 exit status

Опытным C++ разработчикам эта проблема известна как ODR (One Definition Rule). Но корень этой ошибки выходит далеко за рамки «используй inline в .hpp» и «не определяй ничего в .hpp».

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

Некоторые альбомы должны звучать как один длинный трек. Рассказываю, как это устроено в Kalinka Player.

Мне кажется когда мы начинаем обсуждать с ИИ какое-то более менее конкретное техническое решение, которое, очевидно, должно существовать, мы обычно ожидаем чтобы он фактически дал подтверждение и недостающие детали. Но мне при общении с ИИ-агентом, в первую очередь интересно, сможет ли агент в ответ на некоторый сложный вопрос заставить меня (спрашивающего) изменить точку зрения то есть фактически опровергнуть исходную посылку-гипотезу на которую, технический вопрос, так или иначе всегда опирается! По моему это основной признак интеллекта — свобода не только отстаивать свою точку зрения, но и пытаться «заразить» этим собеседника.

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

Первую часть общения я описал как смог в предыдущей статье.

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

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

Дисклеймер: редактора, корректоров у меня нет, вычитать, нормально, столько текста я вряд ли в состоянии.

Но начать я хочу с более детальной формулировки задачи.

Профайлер показывает write() и worker файлового логгера среди верхних стеков. Однако системный профайлер не знает, какая из тысяч строк вывода в лог породила нагрузку. Отключать логирование совсем — ужасное решение. Как же связать файловый ввод-вывод с конкретными строками вывода в лог, каналами и backend?

Дисклеймер: не читайте эту статью, если вы фанат традиционных ценностей и от заголовка уже хотите написать в комментах, что мне стоит изучить базу. Читайте эту статью только если вы прогрессивный, веселый, любите инженерный угар и работающие проекты ♥

Про корпус я писала тут и тут. В этой статье я расскажу про бэк и мои решения!

Совместная разработка, и как найти лентяя в команде. История о том как я пришёл к созданию плагина для OpenSource.

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

А чтобы не читать всю статью инструменты можно быстро посмотреть

JETBRAINS MARKETPLACE

VISUAL STUDIO MARKETPLACE