LINUX.ORG.RU
ФорумTalks

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

 ,


0

4

Тут наткнулся на интересный лонгрид. Имеется ввиду эффективность использования токенов при работе с ИИ агентами. Мы ведь на всех парах летим в светлое будущее, где кодит ИИ, а мы сидим под пальмой и хлебаем смузи. Так о чём это я.

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

Так вот, главный вывод из данного эксперимента следует не удивительный, большинство динамически типизируемых языков более эффективны по токенам, чем статически типизируемые. Но некоторые статические языки уверенно уделывают некоторые динамические. Т.е. дело не только в самой типизации, но и в конкретной имплементации. [вброс]Пламенный превед сишникам и жабаскриптерам 😛[/вброс]

Более общий вывод напрашивается интересный. Вместо бесконечных срачей на тему чей шворц длиннее какой язычок луче, у нас вырисовываются объективные, легко проверяемые критерии, какие фичи полезны для япов будущего, а какие не очень. Когда список утрясётся, останется собрать все полезные фичи в один яп, а все бесполезные выкинуть. И вуаля, вкалывают роботы кодит ИИ, а мы все идём хлебать смузи.



Последнее исправление: yvv1 (всего исправлений: 1)
Ответ на: комментарий от MoldAndLimeHoney

ˈruːbɪ — британское и американское произношение слова ruby

Раби

Откуда вы это берете? Свидетели ютаба.

Loki13 ★★★★★
()
Ответ на: комментарий от Loki13

Откуда вы это берете? Свидетели ютаба.

Из под лайнакса!

yvv1
() автор топика
Последнее исправление: yvv1 (всего исправлений: 1)
Ответ на: комментарий от cobold

надо сделать язык специально для ИИ

В советских учебниках так описывали Лисп и Пролог :)

question4 ★★★★★
()
Ответ на: комментарий от Loki13

Откуда вы это берете?

Оттуда же, откуда «хидеры» и «бейкеры». Один уверенно ляпнул, остальные подхватили.

question4 ★★★★★
()
Ответ на: комментарий от Stanson

Закон Мура такой закон оказался, что прям всем законам закон. Аж на несколько лет. Я уж молчу про все эти маркетинговые сказки о квантовых компьютерах.

Можно хотя бы общее направление подсветить, что за маркетинговые сказки о квантовых компьютерах? А то я в домике, возможно, отстал от жизни.

VIT ★★
()

Лисп, в идеале. Потому что там есть метапрограммирование в нормальном виде.

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

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

lovesan ★★☆
()
Ответ на: комментарий от MKuznetsov

imho хуже всего LLM будет с генерацией lisp

Ничего подобного. Современные ассистенты как раз справляются в тем же Common Lisp наотлично. Я лично пробовал Codex-5.2 для этого.

И лисп проще воспринимается ими, и четче, чем полотна копипасты и бойлерплейта на каком-нибудь питоне.

И да, они понимают даже макросы и макросы считывателя.

lovesan ★★☆
()
Ответ на: комментарий от sabacs

Они лучше всего и работают со спецификациями. Вроде например из текста сделать YAML/XML, это для них так называемый Structured Output.

Поэтому же и DSL на лиспе для них будет проще.

Еще, многословные язычки порождают проблему контекста. Не в том плане, что для многословных язычков его не хватает (у Gemini вон миллион токенов контекст), а в том плане что чем контекста больше, тем больше LLM путается и тупит. И под конец, с большим количеством кода, она начинает вообще глючить и галлюцинировать. Это просто природа LLM такова.

lovesan ★★☆
()

наткнулся на интересный лонгрид

Хотел пошутить про ЛИСП, а он и правда на первом месте.

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

no-such-file ★★★★★
()
Последнее исправление: no-such-file (всего исправлений: 1)
Ответ на: комментарий от lovesan

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

То есть к спецификациям, DSL, макросам лиспа и так далее.

lovesan ★★☆
()
Ответ на: комментарий от no-such-file

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

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

«доказательство корректности» нафиг не нужен оказывается

Этого вывода никак не следует из топика. Важный момент.

yvv1
() автор топика
Последнее исправление: yvv1 (всего исправлений: 1)
Ответ на: комментарий от yvv1

чем строже компилятор, тем лучше иишные агенты справляются с кодом для него

Ну да, а почему растишка сосёт? Даже всякие хаскели и окамли не тянут в итоге, именно потому что накладные расходы на «доказательства».

Этого вывода никак не следует из топика

Очень даже следует, как один из факторов.

PS: меня кстати удивил результат Си. Но не потому ли он такой получился, что ИИ пытался кодить «безопасно» на Си, а не как диды завещали с кучей UB и переполнений.

no-such-file ★★★★★
()
Последнее исправление: no-such-file (всего исправлений: 2)
Ответ на: комментарий от no-such-file

Ну да, а почему растишка сосёт?

Это кто так сказал? Как раз таки наоборот.

Даже всякие хаскели и окамли не тянут в итоге, именно потому что накладные расходы на «доказательства».

В топике раскрыта только тема лаконичности самого кода. Но когда иишный аген его анализирует/генерирует, он делает десятки API вызовов на один запрос. А это тоже влияет на расход токенов. И вот тут растовый бороу чекер делает большую разницу, позволяя агенту разрулить многие проблемы на стадии компиляции за меньшее кол-во API колов, ещё до прогонки тестов.

Так что не нужно делать поспешных выводов.

yvv1
() автор топика
Последнее исправление: yvv1 (всего исправлений: 2)
Ответ на: комментарий от no-such-file

Но не потому ли он такой получился, что ИИ пытался кодить «безопасно» на Си, а не как диды завещали с кучей UB и переполнений.

Не поэтому. А потому на сишечке любая задачка превращается в реально бл.ское кол-во бойлерплейта.

yvv1
() автор топика
Ответ на: комментарий от yvv1

позволяя агенту разрулить многие проблемы на стадии компиляции за меньшее кол-во API колов, ещё до прогонки тестов.

Это магическое мышление. LLM не «разруливает» ничего, он оперирует паттернами

В топике раскрыта только тема лаконичности самого кода.

Лаконичность кода имеет прямое отношение к валидности кода и эффективности LLM-помощников. Из-за размывания векторов внимания, KV-кеша и так далее

lovesan ★★☆
()
Последнее исправление: lovesan (всего исправлений: 1)
Ответ на: комментарий от yvv1

На самом деле на всех языках где нет нормального метапрограммирования.

lovesan ★★☆
()
Ответ на: комментарий от lovesan

Это магическое мышление. LLM не «разруливает» ничего, он оперирует паттернами

Это не магическое мышление. Это так работает ии агент. Он отправляет API запрос LLM провайдеру, получает код, прогоняет его через rust-analyzer, отправляет второй запрос с сообщениями об ошибках, получает уже правильный код. Два запроса - проблема решена. С менее строгими языками на это может легко уйти 10 или 20 запросов, и токены улетают со свистом. Это грубый пример, но суть отражает.

yvv1
() автор топика
Последнее исправление: yvv1 (всего исправлений: 1)
Ответ на: комментарий от yvv1

У тебя контекст в тыкву превратится, от всего этого засирания им пердежом тулов, еще раз

Я так пробовал логи анализировать. Чем дальше тем тупее.

Или вот.

У меня вот тут рядом в чате с Gemini 3 Fast длинный чат «про жизнь» и про философию. Под конец даже эта продвинутая модель начала откровенно глючить и путаться. Естественно, так то пофиг, новый чат заведу. Но в контексте разработки ПО это неприемлемое поведение.

Высеры инструментов и куча мусора в описании типов и прочего - снижают эффективность LLM, а не увеличивают.

Потом что они не «понимают», они оперируют контекстом и семантическими подстановками.

lovesan ★★☆
()
Ответ на: комментарий от Obezyan

Белки истерички которые дупля не отбивают в данной теме и ведутся на хайп и маркетинг.

я тут клод попробовал... тот что новый, кленовый, решетчатый (имеется ввиду опус 4.6).

Разница с тем что было год-полтора назад - небо и земля просто. Он пишет код и пишет весьма неплохо.

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

AndreyKl ★★★★★
()
Ответ на: комментарий от question4

LLM не скобки считают, они по-другому работают.

То как они работают это ближе всего к семантической трансформации, макросам и исполнению DSL, еще раз.

Скобки им даже удобны как меньший нойз в токенах. Поэтому в т.ч. всякие APL проигрывают Clojure

lovesan ★★☆
()

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

Если бы, допустим, джава была популярнее питона, то public static void сделали бы одним токеном.

PolarFox ★★★★★
()
Ответ на: комментарий от lovesan

У тебя контекст в тыкву превратится, от всего этого засирания им пердежом тулов, еще раз

А без тулов бесполезняк даже метаться, ничего хорошего не выйдет. Чтоб контекст не засирался, нужно разбивать задачу на подзадачи вменяемого размера. У меня фича на расте как правило занимает максимум 50К токенов на контекстное окно размером в 200К (т.е. я расходую ~25%). Далее я начинаю новую фичу в новой сессии. Спеки сохраняются между сессиями само собой.

yvv1
() автор топика
Ответ на: комментарий от yvv1

Проблема не в размере возможного контекста, а к тому что он стремится к энтропии из-за механизма attention в трансформерах.

Больше мусора - больше энтропии

В итоге то что генерирует энтропию, станет ненужно, даже с продвинутыми LLM, тупо из-за цен

lovesan ★★☆
()
Ответ на: комментарий от Gary

Я понимаю когда это говноприложуха-однодневка в аппсторе, а если это прошивка рентген аппарата или электроники в самолёте?

занимаюсь формальной верификацией.

так вот таки да, на данном этапе большие надежды на ИИ. недавно ИИ доказал лемму Полищука-Шпильмана на lean. Это стоило ориентировочно $200 и заняло по моему 3 дня. порядка 2000 строк сложно читаемого кода... но ведь у нас есть пруф-чекеры, соотвественно, нафиг тот код читать.. а пруф-чекер его пропускает , значит ошибок нет.

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

так что мы в новой эпохе уже практически. для тех кто программирует у меня не очень то новости.. работа с новым клодом гораздо быстрее идёт. у меня просто на много. но есть данные что на порядок.. это как станок против ручной выточки деталек..

так же призываюстя высказавший похожее мнение Enthusiast

AndreyKl ★★★★★
()
Последнее исправление: AndreyKl (всего исправлений: 2)
Ответ на: комментарий от no-such-file

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

не скажи, доказательства как раз нужны. только вот они действительно их сами и сделают ...

AndreyKl ★★★★★
()
Ответ на: комментарий от lovesan

Больше мусора - больше энтропии

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

yvv1
() автор топика
Ответ на: комментарий от VIT

Можно хотя бы общее направление подсветить, что за маркетинговые сказки о квантовых компьютерах?

Ну долбодятлы внезапно выяснили, что чем больше кубитов, тем больше неопределённость результата вычисления. :)

В общем, вершиной практически полезного применения квантовых компьютеров на сегодняшний день является разложение числа 21 на простые множители 7 и 3 на специально созданном за много миллионов денег для решения исключительно этой задачи квантовом компьютере.

Т.н. «ИИ» мало чем отличается от этого. Бабла крутится и пилится тоннами, хайпа тоже навалом, а вот практической пользы - тоже почти никакой.

Stanson ★★★★★
()
Ответ на: комментарий от Stanson

Ход мыслей понятен, спасибо! А вы сами то к квантовым вычислениям имеете отношение, хотя бы доступ к реальному оборудованию или модели?

VIT ★★
()
Ответ на: комментарий от AndreyKl

Он пишет код и пишет весьма неплохо.

Для простых задач – да. Для чего-то более серьезного – нет. Gemini при использовании Thinking for Math and Code чуть лучше Claude, при использовании по-умолчанию (Fast) пишет код хуже чем ChatGPT. Это ситуация на сейчас.

Obezyan
()
Ответ на: комментарий от Obezyan

Для простых задач – да.

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

а теперь прибавьте к этому возможность гарантировать надёжность кода. опять же с помощью ИИ. мне кажется или программисты выпадают из этого цикла на 90% ?

AndreyKl ★★★★★
()
Последнее исправление: AndreyKl (всего исправлений: 1)
Ответ на: комментарий от AndreyKl

Тут дело не в том что это не предел, а в том что чем глубже в лес тем сложнее верифицировать.

Никто не может дать гарантии что сеть не научится обходить решатели и другие средства проверки. Мы сейчас буквально – обезъяны, которым дали калькулятор и мы его изучаем.

Obezyan
()
Ответ на: комментарий от Obezyan

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

AndreyKl ★★★★★
()
Ответ на: комментарий от Obezyan

Тут дело не в том что это не предел, а в том что чем глубже в лес тем сложнее верифицировать.

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

AndreyKl ★★★★★
()
Ответ на: комментарий от AndreyKl

Я в курсе что такое math solver. Теория это хорошо, вот только каждый решатель это реализация теории, которая может содержать еще неизвестные нам ошибки самой реализации. А сети очень хорошо умеют подстраивать ответы. Понимаете о чем я?

Obezyan
()
Ответ на: комментарий от Obezyan

Это не солвер. это пруф чекер. система проверки формальных доказательств.

если в этой системе сформулировано утверждение и потом доказано и принято чекером, значит оно является математически верным (с очень высокой степенью надёжности).

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

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

AndreyKl ★★★★★
()
Последнее исправление: AndreyKl (всего исправлений: 3)
Ответ на: комментарий от VIT

А вы сами то к квантовым вычислениям имеете отношение, хотя бы доступ к реальному оборудованию или модели?

Имел недолго, почти 10 лет назад, когда это ещё не было модно и IBM не страдало русофобией в терминальной стадии.

Квантовый компьютер тащемта достаточно простая для понимания штука, если объяснять по-человечески, а не как для инвестора. И ничего в нём эдакого нету в смысле программирования. Такое себе вычислительное устройство, даже если не рассматривать дикую стоимость и эпическую ненадёжность.

Если интересно, то принцип работы квантового компьютера и написания программ для него я подробно объяснил человеческим языком тут: ЛОР научи программировать квантовые компьютеры (комментарий)

Stanson ★★★★★
()
Ответ на: комментарий от Stanson

IBM продолжает работы, два года назад я был в T.J. Watson по другим делам, но поскольку друзей-знакомых там много, ходил в лабораторию на втором этаже, беседовал с причастными. Там сейчас немножко насекретили, и я даже знаю почему. Ну ладно, тема все равно не про это. Непонятно, зачем писать то, что вы написали с самого начала, если знаете, как на самом деле.

VIT ★★
()
Ответ на: комментарий от lovesan

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

Люди добавляют проверку баланса после каждого редактирования, и если не сходится, правка отклоняется. Но это такое себе решение.

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

Puzan ★★★★★
()
Ответ на: комментарий от Puzan

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

Наверное, для этого нужно, чтобы токены соответствовали формам. Возможно ли это хотя бы теоретически? А хрен его знает, я в ллмках разбираюсь слабовато.

Nervous ★★★★★
()
Ответ на: комментарий от cobold

Было уже 80+ лет назад. APL называется. Но T9 на стероидах в него не могёт.

beastie ★★★★★
()
Ответ на: комментарий от Nervous

Наверное, для этого нужно, чтобы токены соответствовали формам.

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

Puzan ★★★★★
()
Последнее исправление: Puzan (всего исправлений: 1)
Закрыто добавление комментариев для недавно зарегистрированных пользователей (со score < 50)