Дейкстра: программирование на естественном языке — глупость, и вот почему

Я отправляю эту статью всем, кто говорит мне, что английский теперь стал высокоуровневым языком программирования, следующим уровнем абстракции в цепочке от машинного кода к <их любимому языку>. Обычно за этой аналогией следует: «Как большинство программистов никогда не смотрят на ассемблерный код, так и просмотр высокоуровневого исходного кода станет занятием лишь немногих».

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

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

Я думаю, разница между общением с чисто механическим существом и общением с разумной сущностью: в отличие от программ, которые являются чисто формальными языками, мы пишем учебники и статьи на смеси человеческого и формального языка. Часто мы вводим «достаточно формальные» нотации. И разумный читатель будет читать между строк — inter legere буквально означает именно это: читать между. Заполнять пробелы, соединять точки.

И на практике я нахожу _очень_ эффективным выражать ключевые идеи с помощью некоторого формального языка, где это применимо. Немного EBNF здесь, фрагменты Python или Prolog там или другие языки. И я нахожу LLM замечательными в заполнении пробелов и, что является темой здесь, в переводе нашего полуформального разговора в строгий формальный язык.

И я осмелюсь сделать ещё один шаг: я также нахожу LLM полезными для формулирования и уточнения технических предложений для рецензирования людьми и реализации под управлением LLM, и, конечно, эти предложения смешивают прозу на естественном языке с полуформальными и формальными деталями. Вспомните стиль PEP-12 и PEP-1. И затем они получают рабочие пакеты, каждый из которых включает спецификацию, как в SDD.

Похоже, пока всё работает отлично :-)

У меня такое же мнение с тех пор, как появились агенты для кодирования. LLM хороши в обобщении, поэтому я склонен использовать их для понимания кода. Однако чем больше я понимаю кодовую базу, тем более придирчив я к агенту. А чем меньше я знаю о кодовой базе, тем более открыт я к тому, чтобы позволить ему делать своё дело.

Я понял, что агент не пишет «хороший» код; вместо этого моё смутное понимание того, что я ожидаю, заставляет меня думать, что он это делает. Когда я смотрю на код ИИ, я вижу, что было больше нюансов и решений, которые нужно было принять до написания кода. Кто-то скажет, что спецификации было бы достаточно, но тогда я вспоминаю TLA+, разработанный Лесли Лэмпортом, чтобы помочь разработчикам критически мыслить о своих программах/алгоритмах. Сесть и формально записать, что я хочу сделать, помогает мне лучше понять проблему и прийти к реальному — не смутно определённому — решению.

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

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

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

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

Далее, RMS спросил бы: можешь ли ты сделать свой собственный компилятор программ на естественном языке с нуля?

Я знаю, у нас есть (очень дорогие) локальные модели, но подождите, пока у GPU появятся надлежащие онлайн-подписки для работы и прослушки для слежки.

Возможно, уместно:

Эксперимент по созданию языка, напоминающего естественные языки (английский и японский), не удался. -[1]- Уильям Р. Кук, AppleScript, HOPL IV

Теперь наши новые LLM отличаются, потому что они используют не «язык, напоминающий естественные языки», а настоящий естественный язык. Но урок всё равно поучителен, потому что он даёт нам некоторые эмпирические данные для сравнения с теоретическими аргументами Дейкстры.

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

Мне кажется, мы упускаем то, что то, что LLM делают для нас, на самом деле состоит из двух частей.

1. Это позволяет нам использовать естественный язык, позволяя нам быть нечёткими.

2. Это позволяет нам указывать, что мы хотим, на гораздо, гораздо более высоком уровне, чем обычно.

С нашими LLM эти две вещи неразрывно связаны. Я думаю, целое было бы гораздо, гораздо ценнее, если бы мы могли их разделить.

[1] https://dl.acm.org/doi/10.1145/1238844.1238845

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

Он всё ещё совершенно прав. Я обычно считаю, что машина «программируется на» том, что отслеживается в системе контроля версий. Так что пока ваш git-репозиторий отслеживает изменения в Java, он всё ещё программируется на Java, даже если Java была сгенерирована с помощью LLM. Я могу считать тезис этой статьи опровергнутым только тогда, когда большинство репозиториев начнут отслеживать естественный язык, а не языки программирования, как основные артефакты, определяющие поведение программного обеспечения.