Почему наш язык — лучший язык для программирования (ответ на манифест из 70-х)

Недавно на Хабре вышла статья «Почему наш язык — худший язык для программирования». Автор справедливо отметил проблему двусмысленности естественного языка (ЕЯ) и предупредил, что программирование словами приведет к хаосу.

Я начну с неожиданного: автор оригинальной статьи абсолютно прав.

Он прав, если мы говорим о программировании заклинаниями (vibe-coding) — популярном сегодня подходе, когда человек пишет в окно чата: «Сделай мне интернет-магазин с красивым дизайном», а потом тонет в неконтролируемой лапше сгенерированного кода. В формате свободной болтовни с ботом естественный язык для написания кода действительно ужасен.

Но естественный язык можно использовать по-другому. Можно не просто болтать с ChatGPT — это ошибочный метод программирования на естественном языке. Его надо использовать как основу для строгих декларативных спецификаций.

Инструменты вроде CodeSpeak (публичная альфа-версия от создателя Kotlin Андрея Бреслава, о которой я подробно писал в своей статье) уже сегодня демонстрируют свой огромный потенциал: если загнать естественный язык в рамки контрактов, он способен стать лучшим, самым высоким из доступных нам уровней абстракции.

Будущее разработки: перекладывание JSON-ов или контроль смыслов через ИИ?

Миф №1: «Придется писать в 10 раз больше текста»

Оппонент утверждает, что для точного описания логики на английском или русском потребуется в 10 раз больше слов, чем в коде. Практика CodeSpeak доказывает ровно обратное: объем того, что поддерживает человек, сокращается в 6–10 раз.

В CodeSpeak вместо написания кода вы пишете спецификацию в Markdown-файле .cs.md. Это не роман и не поток сознания. Это структурированный естественный язык, упакованный в жесткий Markdown-формат с четкими разделами (входные данные, структура вывода, требования).

Взгляните на реальный пример спецификации из моей статьи:

# EmlConverter Converts RFC 5322 email files (.eml) to Markdown using Python's built-in `email` module. ## Accepts `.eml` extension or `message/rfc822` MIME type. ## Output Structure 1. **Headers section**: From, To, Cc, Subject, Date as `**Key:** value` pairs 2. **Body**: plain text preferred; if only HTML, convert to markdown 3. **Attachments section** (if any): list with filename, MIME type, human-readable size ## Parsing Requirements - Decode RFC 2047 encoded headers (e.g., `=?UTF-8?B?...?=`) - Decode body content (base64, quoted-printable) - Handle multipart: walk parts, prefer `text/plain` over `text/html` - For `message/rfc822` parts: recursively format as quoted nested message - Extract attachment metadata without decoding attachment content

Здесь нет синтаксического шума, бойлерплейта или ручного управления памятью. Здесь описана чистая бизнес-логика и контракты ввода-вывода. LLM (например, Claude Opus) читает этот файл, генерирует код и тесты. Синтаксис программирования не умирает — он просто поднимается на уровень выше, скрываясь под капотом LLM-компилятора.

Миф №2: «Клубок логики» и ловушка зеленых тестов

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

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

В CodeSpeak ИИ не работает в режиме «перепиши мне всё». Обычно он ограничен рамками одной или нескольких связанных спецификаций. Изменение логики парсинга писем никогда не сломает модуль оплаты, потому что LLM работает строго в границах локального контракта.

А как же тесты? Да, LLM пишет их сама. Но здесь меняется роль человека: он становится архитектором смыслов. Разработчик больше не ищет пропущенные запятые в Python-скрипте, он проводит ревью спецификаций и сгенерированных тест-кейсов. Двусмысленность устраняется на этапе согласования требований человеком, а не на этапе генерации.

Миф №3: «Даже в точных науках нужен строгий формализм, а не слова»

Оппонент ссылается на аппаратные ограничения и математическую точность. Да, если вы пишете драйвер для видеокарты или ядро СУБД, вам нужен Rust или C++.

Но 90% софта в мире — это бизнес-логика. И здесь уместно вспомнить, как работают сами математики. Дональд Кнут в «Искусстве программирования» дает алгоритмы в строгом MIX-ассемблере, но обязательно подробно объясняет их на естественном языке.

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

В программировании будущего будет точно так же:

• Человек использует естественный язык для проектирования архитектуры и бизнес-правил.

• LLM берет на себя «механические вычисления» — трансляцию этих правил в Python, Java или Go.

Комментарии в коде — лучшее доказательство

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

Почему? Потому что код отвечает на вопрос «как», а естественный язык отвечает на вопрос «зачем». Код не способен передать высокоуровневую мотивацию и граничные случаи так же емко, как это делает человеческая речь. И именно эти комментарии сегодня помогают LLM-моделям при рефакторинге не терять суть задачи. Так почему бы не сделать эти «комментарии» самим источником истины (Source of Truth)?

Эволюция не остановится на Python

Мы уже прошли долгий путь: машинный код → ассемблер → C → Java/Python. Каждый шаг — это отказ от ручного контроля в пользу более высокой абстракции.

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

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

Пришло время перестать бороться с естественным языком и научиться его правильно готовить.

(Ссылка на мою статью с разбором архитектуры CodeSpeak: Архитектура вместо синтаксиса)

Что думаете? Готовы ли вы делегировать написание кода LLM, оставив за собой контроль контрактов, или продолжите вручную перекладывать JSON-ы до пенсии?