Почитав некоторое количество отзывов на нашумевшую статью If Humans Are No Longer Writing Code, Why Use Code In a Form Designed For Humans to Read? предложу вам пару своих соображений. Но сначала об основных идеях статьи с длинным подзаголовком:
There is no longer a reason to use human programming languages. 97% code size reduction and 50x efficiency increase in code execution can be achieved if we move to coding Intent instead of code
Во-первых, я категорически советую прочитать этот текст и посмотреть обширные ссылки на источники в конце текста. И это не потому, что я согласен с выводами автора. Скорее я с ними не согласен. Но столь глубокие и одновременно полезные рассуждения встречаются не каждый день. Так что прочтите, не пожалеете.
Для тех, кто не станет читать простой пример из текста:
def calculate_discounted_price ( original_price, discount_rate ): discount_amount = original_price * discount_rate final_price = original_price - discount_amount return max (final_price, 0 )
Вот что на основании такого кода нужно машине: загрузить значение из стека со смещением 0, умножить на значение со смещением 1, вычесть результат из смещения 0, сравнить с нулем, выполнить условный переход, сохранить результат в регистр и вернуть управление. Шесть операций, без имен, без пробелов, без ключевых слов. Пять строк кода на Python существуют для того, чтобы человек мог их прочитать. Шесть машинных операций существуют для того, чтобы процессор мог их выполнить.
Во-вторых, идея текста не ограничивается тезисом: зачем писать код, понятный для людей если писать и читать его будет ИИ. Это базовая идея, но статья не только об этом. Да и с основным тезисом автор поступает достаточно аккуратно. 97% — оценка, верная для конкретного приложения в миллион строк, написанного на python (см. рисунок выше)
Для других языков и других приложений уровень «избыточности» будет другим. (раздел The Stack Dissolves статьи; в статье два раздела с номером 6, см. второй 6-ой раздел)
Конечно же текст содержит ряд предложений как могут выглядеть новые языки программирования. И это не ассемблер, не машинные коды, а вполне осмысленная вычислительная модель. Более того, автор задумывает как осуществить поэтапный переход в это светлое будущее.
Но не менее интересно, что этот переход позволит избежать значительного количества ошибок, произрастающих из «человеко-понятности» современных языков программирования. (см. первый раздел с номером 6. — The Error Revolution)
К сожалению, последующие разделы о том, как делать правильные спецификации и изготавливать программы (7. The Specification Boundary и 8. The Architecture) довольно лаконичны, но идея, в общем и целом, понятна.
Теперь о том, что не так. Привычка мерять все количеством токенов за пару лет стала нашей второй натурой. Вряд ли экономия токенов входит в планы поставщиков LLM сервисов. Тем более, что избыточность программы лучше мерять лишними операциями, лишними тактами работы процессора если угодно. Проблема не в строчках кода, не в том, что команд в программе слишком много, а в том, что они могут выполнятся много-много раз. Происходит это отчасти за счет циклов и, в большей степени из-за многократных вызовов процедур. Причина такого положения дел не столько в «неправильных алгоритмах», а скорее в иерархической структуре программного обеспечения. Вызвать готовую функцию проще (для человека), чем написать свою. и даже проще, чем детально разобраться что и как делает эта готовая функция. Неприятная, но ожидаемая особенность большинства вызываемых функций в том, что они в свою очередь вызывают другие функции и часто это код из другого модуля (или пакета) или вообще remote procedure/method, т.е. не локальная процедура. Появление 30 с лишним лет назад ООП с его наследованием и полиморфизмом сделали разработку приложений «поверх» готовых фреймворков крайне несложным занятиям. Готовые библиотеки для взаимодействия с удаленной БД, брокером сообщений или еще каким-либо сервисом окончательно спрятали сложность под ковер. Желание побыстрее и подешевле запустить что-нибудь новенькое формирует структуру современного ПО
Следующая проблема, которую отметили многие комментаторы в том, что, приступая к разработке или модификации приложения мы не всегда достаточно четко представляем чего хочет заказчик. Как, впрочем, не представляет этого и он сам. Вся итерационная разработка выросла из этого очевидного наблюдения. В каком-то смысле происходит простая подгонка решения задачи под ожидаемый результат (прохождение тестов). Структура весеннего льда зависит от разницы ночных и дневных температур, структура программы — от частоты и размера приращений развиваемого продукта
Ну и третье неочевидное допущение автора статьи в том, что разработка развивается рационально в направлении повышения эффективности. Вряд ли это так. Продукты формируют технологии. Коммерческие или прочие интересы отдельных людей и организаций создают поле мотиваторов, которые заставляют нас выбирать один решения и отвергать другие. Рациональность ограничена еще со времен Герберта Саймона. И, как выяснилось позже, скрыта за ворохом когнитивных искажений. Повсеместно наилучшим ответом становится быстрый ответ. Кроме того, за эффективность одних групп заинтересованных лиц непременно платят другие. Собственно говоря, программное обеспечение часто выступает реквизитом такой игры в перетягивание влияния и ресурсов между группами стейкхолдеров.
Конечно, языки и практики программирования будут меняться. Вполне вероятно, что эти изменения будут включать и появление новых вычислительных абстракций (Разве это не история про DSL?). Часть из них даже будет полезной. Однако формирующим трендом станет не это. Вероятно, в ближайшей перспективе борьба развернется за попадание в контекстное окно и «привлечение внимания» модели. Будет выигрывать тот инструмент, навык, MCP-сервер, который LLM «захочет» использовать. Вряд ли это упростит код приложений. Скорее наоборот. А еще добавит к существую языкам программирования новые псевдоязыки написания «понятных моделям» спецификаций. Создавать новое просто, переделывать старое на порядки сложнее. Особенно если результат хочется получить уже вчера