Какие языки программирования наиболее эффективны с точки зрения использования токенов?

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

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

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

Мы видели ТОН (кодировка JSON для большей эффективности токенов), но как насчет языков программирования?

Методология

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

Я нашел Зеркало GitHub набора данных, поэтому взял Claude Code и попросил его сравнить их, используя токенизатор Xenova/gpt-4 от Hugging Face — который является портом сообщества токенизатора GPT4 OpenAI.

Затем я попросил Клода Кода предложить выбор наиболее популярных языков программирования, который примерно соответствует моему опыту, а затем найти задачи, для которых были предложены решения. все 19 из этих языков, а затем пропустил их через токенизатор. Я не включил TypeScript, потому что в наборе данных Rosetta Code было очень мало задач.

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

Результаты

Обновлять: Многие спрашивали про APL. Я повторно выполнил меньший набор одинаковых задач по кодированию — он занял 4-е место с 110 токенами. Оказывается, знаменитая краткость APL не является плюсом для LLM: токенизатор плохо оптимизирован для своего набора символов, поэтому каждый из этих уникальных глифов (⍳, ⍴, ⌽ и т. д.) в конечном итоге превращается в несколько токенов.

Обновление 2: Читатель обратился к J — языку, о котором я никогда не слышал. Это язык массивов, подобный APL, но вместо специальных символов он использует ASCII. Он доминирует в среднем всего лишь с 70 токенами, что составляет почти половину Clojure (109 токенов). Языки массивов могут быть чрезвычайно эффективными с точки зрения использования токенов, если они избегают экзотических наборов символов. Если эффективность токенов окажется ключевым фактором, возможно, это будет очень интересный путь для развития языков.

Между C (наименее эффективным языком, который я сравнивал) и Clojure (наиболее эффективным) был очень значительный разрыв в 2,6 раза.

Неудивительно, что динамические языки были гораздо более эффективными в отношении токенов (отсутствие необходимости объявлять любой типы экономят много токенов), хотя JavaScript оказался самым многословным из проанализированных динамических языков.

Но что меня удивило, так это то, что как Токен-эффективность некоторых функциональных языков, таких как Haskell и F#, была едва ли менее эффективной, чем наиболее эффективные динамические языки. Это, без сомнения, заслуга их очень эффективных систем вывода типов. Я думаю, что использование типизированных языков для LLM имеет очень много преимуществ – не в последнюю очередь потому, что они позволяют компилировать и быстро получать обратную связь о любых синтаксических ошибках или галлюцинациях методов. С LSP это становится еще более полезным.

Если предположить, что 80% вашего контекстного окна — это чтение, редактирование и сравнение кода, использование Haskell или F# потенциально может привести к значительно более длительному сеансу разработки, чем использование Go или C#.

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