Автор эссе назвал Common Lisp лучшим языком для кода с нейросетями

Эссе начинается с тезиса: если одни языки программирования лучше других, то один из них лучший, и теперь, когда код пишут нейросети, это Common Lisp. Это мнение автора, а не результат исследования.

Первый довод, скорость обратной связи. Нейросети пишут код очень быстро, поэтому медленной частью стала проверка, работает ли программа, а перед ней, пересборка, которая, по словам автора, может занимать несколько минут. Когда код писали люди, это почти не имело значения, теперь длина цикла обратной связи определяет, как быстро можно строить продукт. В Common Lisp, пишет автор, этого цикла почти нет: там нет настоящего различия между временем чтения, компиляции и выполнения (автор ссылается на эссе Пола Грэма «What Made Lisp Different», май 2002). Common Lisp работает на основе образа (image): программа, это живой образ в памяти, и новая версия функции сразу заменяет старую без перезапуска.

Второй довод, ошибки. В большинстве языков ошибка роняет программу, и нейросети приходится читать логи падения и запускать всё заново. В Common Lisp программа не падает, а останавливается и открывает отладчик со всем стеком и всеми переменными; нейросеть можно направить на отладчик, она внесёт исправление, и программа продолжит работу. По мнению автора, насколько ему известно, Common Lisp, единственный популярный язык, который умеет всё это сразу.

Третий довод, макросы. Lisp означает «обработка списков»: код записывается списками, например (+ 1 2), это и программа сложения, и список из символа + и чисел 1 и 2. Это тот же вид списков, в которых язык хранит данные, поэтому все инструменты для данных работают и с кодом: программа может взять другую программу, изменить её (например, превратить (+ 1 2) в (* 1 2)) и сразу запустить. Отсюда макросы, функции, которые принимают код и возвращают вместо него новый код, то есть позволяют добавлять в язык новые конструкции. В Lisp пишут не просто программу, а сначала язык для своей предметной области, а затем программу на нём.

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

Четвёртый довод, краткость и цена. Благодаря макросам программы на Lisp часто гораздо короче, и чем больше программа, тем заметнее разница. По личному опыту автора, его приложения на Common Lisp получаются примерно в шесть-семь раз короче версий на Python (это не измеренный бенчмарк). Меньше кода, меньше токенов, а за токены платят, поэтому разработка дешевле. Кроме того, в контекстное окно нейросети помещается большая часть программы. По опыту автора, многие ошибки нейросетей возникают, когда она меняет один фрагмент, не видя остальных; с Common Lisp это случается реже.

Пятый довод, стандарт. Common Lisp, стандарт ANSI, не обновлявшийся с 1994 года, и автору это нравится: в примере с ERP язык под продуктом никогда не меняется, и ничего, что пользователи построили сверху, не ломается.

Автор разбирает и два очевидных возражения. Первое: нужных библиотек часто нет, в Quicklisp, основном менеджере пакетов Common Lisp, пара тысяч проектов, в npm, миллионы. Автор отвечает, что это уже не проблема: современные программы зависят от миллионов строк чужого кода из пакетов, которые постоянно оказываются скомпрометированными, а нейросеть может написать нужную часть или перенести библиотеку целиком, причём, как ему кажется, переносить код она умеет очень хорошо. Второе: так мало людей знают язык, что инженеров трудно найти. По мнению автора, это не важно: лучшие технические специалисты, те, кто хорошо учится, так что на собеседовании кандидатам стоит предложить выучить Common Lisp, и по скорости освоения будет видно, кто справляется. Вывод эссе: в следующий раз пишите программу на Common Lisp.

Ключевые факты

Главный довод: когда код пишет нейросеть, узким местом становится проверка результата, и Common Lisp почти убирает цикл пересборки, новая версия функции заменяет старую в живом образе без перезапуска.
Вместо падения программа на Common Lisp останавливается и открывает отладчик со всем стеком и переменными; нейросеть можно направить на него, она исправит ошибку, и работа продолжится.
Макросы позволяют строить предметный язык под задачу; автор прогнозирует, что компании дадут пользователям менять продукт с помощью нейросети, и такой язык сделает правки точнее.
Краткость: по личному опыту автора, приложения на Common Lisp примерно в шесть-семь раз короче версий на Python (это не бенчмарк); меньше токенов и больше программы в контекстном окне.
Стандарт ANSI не обновлялся с 1994 года, для автора это плюс; нехватку библиотек (в Quicklisp пара тысяч проектов) и инженеров он считает несущественной.

Почему это важно

Эссе формулирует популярную мысль в одной точке: если код пишет нейросеть, то выбор языка определяется не тем, удобно ли его набирать, а тем, как быстро можно проверить результат и как дёшево обходится работа с моделью. Автор связывает известные свойства Common Lisp, живой образ, отладчик вместо падения, макросы, краткость, именно с этой экономикой. Это рассуждение, а не доказанный вывод.

Кому это важно

Разработчикам, которые много пишут код с помощью нейросетей и страдают от долгих пересборок и перезапусков. Тем, кто интересуется Lisp и предметными языками. Руководителям, которые думают о стоимости токенов и о том, дать ли пользователям менять продукт самим.

Как это применить

Прямого руководства в эссе нет: оно заканчивается призывом писать следующую программу на Common Lisp. Практически из текста следует идея направить нейросеть на отладчик остановленной программы, чтобы она исправила ошибку и продолжила выполнение. Для пробы можно сравнить, как на вашей задаче получается размер кода и цикл правок в Common Lisp и в привычном языке. Конкретные реализации и инструменты в эссе не названы.

Можно ли доверять

Это мнение, а не исследование. Цифра про шести-семикратную краткость, личный опыт автора с собственными приложениями, без бенчмарка. Измерений работы нейросетей на Common Lisp в сравнении с другими языками нет, реальные компании и продукты не приводятся: пример с ERP гипотетический. Утверждение о единственном популярном языке с такими свойствами сопровождено оговоркой «насколько мне известно». Единственный внешний источник, эссе Пола Грэма 2002 года. Автор в тексте не указан.

Риски и подводные камни

Автор сам называет два ограничения: в Quicklisp пара тысяч проектов против миллионов в npm, и мало людей знают язык. Его ответы, «нейросеть напишет или перенесёт библиотеку» и «кандидаты выучат язык на собеседовании», это предположения без подтверждений. Прогноз о том, что пользователи будут сами менять продукты с помощью нейросетей, тоже остаётся прогнозом. Довод про замороженный стандарт 1994 года, оценка автора; обратная сторона в эссе не рассматривается.

«В Common Lisp ваша программа не упадёт, она остановится и откроет отладчик со всем стеком и всеми переменными.»

— автор эссе