В блоге hofstede.it представлен Bespokeязык программирования, в котором исходный код оформляется как вежливая просьба, а не как приказ. Компилятор не обязан принимать мутацию, выраженную приказом, а при сбое движок исполнения не падает, а «подаёт в отставку в запечатанном конверте». В том же наборе материалов фигурируют ещё несколько проектов: переработанный классификатор AI-комментариев, плата, спроектированная в эксперименте на простом английском, решение криптограммы и минималистичный браузер на C.
Что именно изменилось
Bespoke задаёт другой тон взаимодействия с компилятором. Объявление переменной оформляется как письмо: разработчик просит выделить слот для целого числа и инициализировать его нулём. Мутация разрешена, но при условии, что программист признаёт причиняемое ею неудобство. Запись вида x = 5; порождает диагностику B-101 Blunt Imperativeдиагностику о мутации, выраженной приказом, а не вежливой просьбой: компилятор не обязан принимать такую мутацию, поэтому компиляция приостанавливается, пока разработчик не обдумает своё поведение. Сообщение диагностики требует переформулировать запрос как вежливый вопрос.
Ветвление устроено не как приказ, а как вопрос, задаваемый «суду». Обычный if описывается как обвинение — «это условие истинно, теперь делай, как я говорю». Вместо него язык ставит перед судом гипотетический вопрос: сначала идёт фраза с предложением рассмотреть условие, затем ветка для истинного случая, затем ветка для противоположного и завершение. При заданном значении истинности выбор ветки детерминирован. Суд назван церемониальным, потому что не может быть подвержен лоббированию ни одной из сторон.
Функция не захватывает управление и не возвращает значение, а предлагает небольшое ограниченное сотрудничество — объявляется как дипломатическая процедура с именем и входными параметрами. Вместо «бросить исключение» компонент сообщает о неловком затруднении и смиренно поднимает его на благосклонное рассмотрение. Обработка непредвиденных обстоятельств — деликатная попытка с последующим сострадательным приёмом: блок открывается предложением действовать с величайшей осмотрительностью, содержит условие о сбое с именованным «прискорбным обстоятельством», ветку на любой исход и завершение.
Защита общих данных строится на протоколе SharedLedgerправиле, по которому любой доступ к общему журналу оформляется вежливым запросом эксклюзивного доступа с обещанием освободить его по завершении работы: при соблюдении протокола данные защищены от гонок. Мьютекс представлен как «Request for Exclusive Audience» — просьба о временном единоличном доступе с обещанием освободить его по завершении работы. Порядок получения доступа при этом может различаться: вежливость не определяет планирование потоков и не устраняет взаимные блокировки. Если два потока ждут ресурсы друг друга, каждый уступает первым, и рантайм фиксирует это не как deadlock, а как Exemplary Stalemate of Mutual Deferenceобразцовое противостояние взаимной уступчивости, при котором пауза терпится бесконечно. По той же причине потоки никогда не убивают и не завершают принудительно — Companion Worker Threadрабочий поток, который завершается не по команде, а по формальному приглашению получает формальное приглашение завершиться.
Управление памятью следует тому же принципу: автоматическая сборка мусора не предполагается, вместо неё нужно официально обратиться к groundskeeperслужбе, которая освобождает память по официальному обращению вместо автоматической сборки мусора. Проверяется и орфография: диагностика B-204диагностика о небританском написании слова требует британского написания, поскольку буква «u» не опциональна в вежливом обществе, и предлагает писать set_colour. диагностика B-310диагностика об отсутствии завершающей благодарности в запросе отклоняет безупречно сформулированный запрос, если в нём нет завершающего «Thank you».
Предыстория
В статье на Хабре эволюция описана так: первые ламповые компьютеры были огромны по размерам, потребляемой мощности и стоимости, изготавливались штучно, а их программирование существовало где-то на периферии выделяемых на компьютеризацию бюджетов. Затем появились полупроводники, микросхемы малой, средней и высокой интеграции, позже микропроцессоры, и компьютеры постепенно становились обыденностью — сначала как мейнфреймы, позже как персональные, включая рабочие станции и бытовые поделки для энтузиастов и тинейджеров.
Этим компьютерам нужны были программы — для бизнеса, для развлечения, для чего угодно, и программисты постепенно стали массово востребованы «как колдуны, использующие магические заклинания на языках программирования». Цепочка в статье выглядит так: больше компьютеров — больше пользователей, больше пользователей — больше ассортимент потребных программ, больше ассортимент — нужно больше программистов. В итоге программисты из придатка к большому компьютеру превратились в краеугольный камень цифровой цивилизации, а по доходам начали конкурировать с врачами, юристами и наркодилерами.
Долгое время взаимодействие с компьютером требовало изучения «языка заклинаний», потому что писать программы могли только программисты на языках программирования. Обычные пользователи без стороннего программиста оказывались полностью беспомощны и были ограничены уже имеющимся софтом. Возможность говорить с компьютером на человеческом языке раньше описывалась лишь в фантастике, где компьютеры общались с оператором обычным человеческим языком — со всеми его проблемами неоднозначности, недосказанности и требования понимать контекст.
Почему это сделали
Bespoke решает проблему грубого тона программирования. Авторы утверждают, что программирование приобрело неудачный тон: мы «kill» процессы, «abort» транзакции, «throw» исключения, «break» циклы и «execute» инструкции, захватываем блокировки без спроса, мутируем значения без извинений и приказываем машине return, как будто это лабрадор. Отсюда требование вежливых формулировок и диагностики вроде B-101, B-204 и B-310.
При этом Bespoke не ускоряет софт и не предотвращает ошибки конкурентности. Его предлагаемые бинарники обычны, а исходный код имеет информационную плотность, сравнимую с договором XIX века. Язык задаёт вопрос: если мы собираемся проводить дни, требуя от машин невозможного, нельзя ли хотя бы быть приятными в этом.
Классификатор AI-комментариев решает другую задачу — отличить комментарии, написанные человеком, от сгенерированных языковой моделью. После обучения обнаружилось, что он почти всегда называет вероятными Kimi K2.7Одна из шести LLM-моделей, на которых обучен классификатор AI-комментариев; её стиль перекрывается со всеми остальными моделями, поэтому при классификации назначенную ей вероятность перераспределяют в основном на Grok и Claude. или glm, потому что стили этих двух моделей перекрываются со всеми остальными, и суждение классификатора размазывается по ним. Поэтому на этапе классификации вероятность, назначенную этим двум моделям, перераспределяют обратно по остальным пропорционально тому, сколько массы они отняли при обучении: Kimi K2.7 отдаёт в основном Grok и Claude, а glm — примерно поровну всем остальным. Затем вероятности перенормируют, чтобы получить априорное соотношение 50/50 для человек/робот вместо исходного 1/7, поскольку на практике важно лишь, написан комментарий человеком или сгенерирован роботом.
Что это меняет на практике
Классификатор даёт сбалансированную точность 77 % и печатает предсказанный процент, который калиброван, то есть читается как вероятность правильности вердикта. В интерфейсе можно кликнуть по любой части классифицируемого текста и увидеть, какие признаки активируются на этом фрагменте и как они влияют на общий вердикт. Для диагностики ошибок используется матрица неточностейтаблица, по которой видно, сколько раз каждый класс был определён верно и сколько раз его спутали с другим, где «robot» считается положительным классом: при известном человеческом вводе классификатор правильно определяет его как человеческий в 73 % случаев, при известном роботском — в 80 % случаев. Путь через семь классов позволяет показать разбивку по моделям LLM рядом с основным предсказанием и, возможно, лучше уловить сложную форму поверхности, разделяющей человеческий и машинный текст.
По данным источников, благодаря развитию ИИ миллионы не-программистов написали свои первые программы, но не стали от этого программистами и не приобрели ценный опыт и знания для освоения профессии разработчика ПО. Им это и не нужно — им просто нужно, чтобы компьютер делал то, что они хотят по работе или для развлечения. Профессия программиста вряд ли исчезнет даже в отдалённой перспективе, потому что кто-то должен разрабатывать и поддерживать сам ИИ, а «стул шатается» под теми, кто пишет код без разбора, — под говнокодерамитеми, кто пишет код без разбора он начинает шататься уже сегодня.
Ограничения и открытые вопросы
Генерация машинного кода по человеческому описанию всё ещё далека от сценария, когда «сказал пару слов, ответил на уточняющие вопросы и получил готовый код на выбранном языке или сразу скомпилированный бинарный файл, который работает и не падает». Авторы статьи на Хабре предвидят резонные комментарии о том, что всё не так хорошо, как кажется идеалисту, далёкому от разработки ПО, с примерами, как именно не всё так хорошо, и соглашаются: пока всё ещё не так хорошо, но намного менее плохо, чем говорят скептики и хейтеры. Ограничение связано с текущим уровнем технологии, а не с принципиальной невозможностью: авторы предлагают смотреть на вопрос шире, а не сиюсекундно, и указывают, что мы сегодня очевидно намного ближе к сценарию, где компьютер помогает человеку без посредников — выполняя голосовые команды, размышляя и самостоятельно принимая решения в широких и сравнительно волатильных рамках промпта, но не жёсткой логики конечного автомата.
У классификатора AI-комментариев остаётся проблема: при L1-нормализованных признакахприведении суммы абсолютных значений признаков к единице вероятности логистической регрессии становятся очень малыми. Для смягчения применяется отдельный проход: он берёт уже обученную модель и подбирает температурный коэффициент kмножитель, который делает предсказания более резкими, то есть сильнее разводит близкие вероятности — так, чтобы предсказания экстремизировались в зависимости от квадратного корня длины входного текста. Автор не планирует продолжать работу, потому что новые условия sourcehutплатформы для размещения и совместной работы над кодом запрещают использовать её для размещения кода, сгенерированного LLM. Кроме того, он прямо объясняет, что не станет доводить код до высокого качества: это побочная задача, на которую он не может тратить много времени.
Открытый вопрос Bespoke сформулирован как приглашение подумать о вежливости: если мы собираемся проводить дни, требуя от машин невозможного, нельзя ли хотя бы быть приятными в этом.
