Repomap №... :) Для парсинга кода с отсечением лишнего в подобных проектах часто обращаются к treesitter (см. например https://aider.chat/2023/10/22/repomap.html). На Go к нему есть бинды. Однако, утилит делающих repomap на Go + treesitter до сих пор не встретил. Сам использую https://github.com/wyattcupp/codesnap, там тоже без treesitter. Жду, кто бы прикрутил это вместе :)
Сайт mindprison.cc это блог некоего https://substack.com/@dakara Кто он и насколько владеет экспертизой я не знаю. Какой-то айтишник :) Да и так ли это важно? Авторитетные эксперты тоже могут ошибаться или попросту врать в своих интересах. Мне понравились статьи на сайте, хотя не со всем могу согласиться и местами автор откровенно сгущает краски. Однако, он подкрепляет высказывания ссылками на ресерчи, можно поразбираться самому, не веря на слово. Из статьи которую приводил выше, к примеру, ссылка на интересное исследование Anthropic "On the Biology of LLM". Имхо, автор хотя бы пытается разобраться в темах о которых пишет, не просто компилирует подборки трендовых новостей о грядущих массовых увольнениях ;)
Из авторитетов в приведенной статье Yann Lecun, который озвучивает по сути то, что автор расписывает всю статью ссылаясь на исследования компаний: в развитии LLM огромный прогресс и это продолжится, но к AGI это развитие не ведёт, там пропасть, для преодоления которой нужны другие идеи и алгоритмы.
Как я понимаю, Cursor (как и Aider, Plandex и прочие), как раз в этом помогают, строя карту по коду (repomap) и убирая лишнее через tree-sitter, чтобы минимизировать контекст. В Cursor еще RAG как-то задействовали, судя по их заявлениям.
Да я может быть красочно описал. Локальные модели тянут, но задачи им даю попроще. Уровня: опиши создание библиотеки по доке, теперь создай, допиши юнит-тесты -- именно так, поэтапно, и конечно с более подробными промптами. В целом, на таких задачах существенной разницы по качеству кода с использованием больших платных моделей в Cursor я не увидел. Но в Cursor я могу попросить что-нибудь в стиле "спроектируй взаимодействие этих двух сервисов" и дать на входе оба репозитория с сотнями файлов, в Aider на моих локальных мощностях так конечно не прокатит. Хотя если его подключать к платным провайдерам, то подозреваю выход будет плюс-минус такой же.
Btw, для себя раньше интересовался Flutter, и понятно дело в отсутствие проектов по работе дальше простых примеров оно не пошло, я на своем бекенде сильно далек от мобильной разработки. Прям любопытно попробовать снова, с новым доступным нейро-инструментарием, глядишь дело дальше продвинется :)
Спасибо :) Использую на Linux и софт в целом тоже ориентирован на работу в Linux, в основном бэкенды для веба, плюс мелкие GUI. Код на Golang, редко Python или C (в последний без нейросетей я бы и не полез). Ну и Elisp ещё. Модели подбираю чтобы вписались в AMD Radeon 7900XTX (llama.cpp через Vulkan), однако последнее время использую связку с Macbook на M3, который на удивление шустро работает с LLM, по скорости не хуже чем на указанной видеокарте! AMD Radeon выбирал как более удобный для работы в Linux и память на этой видюхе 24G, но судя по всему Nvidia + CUDA всё ещё рулят здесь, так что мой вариант не оптимален.
Для проектирования хорошо подходят "рассуждающие" модели как DeepSeek R1. А для кодинга и в принципе любых задач с инструментами Qwen2.5 или Gemma. Последнее используемое это deepseek-r1-distill-qwen-32B на m3 + gemma-3-27B-it-QAT на Radeon. Aider позволяет с некоторыми ухищрениями прицепить модели от разных провайдеров и мне так удалось зацепить LM Studio на маке с Llama.cpp, так что режим "архитектор" в Aider использует Deepseek с мака, а для исполнения плана и создания файлов применяет локальную Gemma в Llama.cpp. С Cursor шаманств поменьше, "включил и работает", но и ограничений больше, главное из которых это жесткая привязка к VS Code в их собственном исполнении. Даже коллеги привыкшие для Go к Jetbrains Goland сильно плачут, мне же после Emacs вовсе непонятно как этим удобно пользоваться :) Тем не менее, если абстрагироваться от ограничений IDE, то Cursor в связке с DeepSeek-R1 для построения планов + Gemini 2.5 или Sonnet 3.7 для кода -- это прям огонь, позволяет анализировать и править код довольно жирных сервисов на Go (особенно с Gemini Pro, у которого огромный входной контекст).
В целом выбор моделей на мог взгляд есть некоторая вкусовщина. Определенно, для построения плана "что делать" лучшие результаты дают thinking-модели. А дальше реализацию по ним вообще не критично какой модели отдать, лишь бы понимала работу с инструментами. Так то результаты плавают от случая к случаю. Тем более, я тесты моделей не проводил, просто решаю свои задачки, поэтому мои рекомендации здесь определенно не точны. Для своих задач получите свои предпочтения.
Использую Aider и Cursor, последний поскольку работодатель оплачивает, а первый опенсорсный и легко прикручивается к разным IDE и моделям (у меня это Emacs + локальные модели на видеокарте через llama.cpp). По опыту применения у меня сложилось примерно такое же мнение, как у автора статьи, подобные инструменты хорошо годятся для автоматизации рутинных задач, для исправления простых ошибок в коде, даже порой помогают увидеть вещи которые своим взглядом упустил. Вероятно в будущем они смогут делать всё это лучше и быстрее. Но пока нужно очень тщательно смотреть не нарисовала ли сеточка шесть пальцев и ревьюить результаты. И действительно сложные вещи, где требуется глубокое понимание языка/платформы/библиотек пока проще оставлять на себя, даже не пытаться это промптить. Т.к. это как если бы вы все нюансы пытались описать джуну, а потом посмотрев результаты его работы просто переписывали код сами, чертыхаясь, что зря потратили время на объяснения. В любом случае, прогресс в инструментарии вокруг нейросетей за последние годы выглядит внушительно и результаты можно применять с большой пользой уже сейчас. Но отдача от них прямо пропорциональна вашей собственной экспертизе! Схема, когда ничего не понимающий в IT человек создает сложные программы всё ещё не работает. В будущем со strong AI полагаю заработает, а пока здесь много хайпа на теме и результаты стоит воспринимать скептически и внимательно анализировать восторженные отзывы. Однако, не стоит их также недооценивать!
А ведь альтернативных вариаций C довольно немало изобретено, и есть успешно развиваемые (как примеры можно вспомнить Zig или Hare). Конечно по популярности им очень далеко не только до прародителя, но и до того же Rust. Однако, в сравнении с Rust, они значительно понятнее разработчикам на C, так как исходная "база" языка оставлена, при этом дают современный тулинг (то чем хорош Rust), при этом быструю компиляцию и главное, устраняют основные проблемы, за которые ругают оригинальный С с неоднозначным синтаксисом, мутным препроцессингом и пр. Тут опять же не стоит прямо сравнивать с Rust, где логику программы приходится переосмысливать, чтобы уложить в сильно отличающуюся модель владения памятью и прочие особенности Rust. Вот в том же Hare код выглядит прям очень близко к C, но с более однозначным синтаксисом, более строгой обработкой ошибок и т.п. вроде как мелочами, но код как-то приятнее пишется и легче воспринимается (тут субъективно конечно). Жаль, что пока такие языки далеки от мейнстрима и маловероятно, что в ближайшем будущем их будут рассматривать как варианты для языка Linux kernel.
Вы открыли мне мир! :) Я как в прошлом веке научился таки вместо kill -9 использовать ":wq" (или ":wq!" для тяжелых случаев), так им и пользуюсь. Уже привычкой стало не трогать Ctl-C или Ctl-D в Vi :\
Чтобы осовременить архаично лайтовое содержание статьи добавлю актуальных ссылок, на ресурсы о современном GNU/Emacs, а не о том Emacs который воображают себе пользователи разных "современных IDE" :P К сожалению не помогу ссылками на Vim ибо практически им не пользуюсь, тут пусть местные вимеры подскажут. И в любом случае вимеры все сгорят в аду В общем вы поняли на какой я стороне.
Учебные материалы от System Crafters: https://systemcrafters.net/guides/#gnu-emacs -- у них там всякое по подписке, но с сайта просто см. ссылки на уроки и подкасты на Youtube. Там же про всякое сопутствующее в Lisp-style, как дистрибутив GNU/Guix и прочую linux-альтернативщину :)
Living an awesome life by Sacha Chua https://sachachua.com/blog/ -- блог гиковой филлипинки, который она ведет уже два десятилетия.
...вообще их конечно много больше, а часть из указанных имеют альтернативы, которые не хуже, даю ссылки для привлечения внимания, разобравшись и настроив эти плагины можно получить очень удобную в навигации и для редактирования среду.
Из последнего, чем начал пользоваться только в этом году: https://github.com/s-kostyaev/ellama + https://github.com/ahyatt/llm + llama.cpp (но тут можно и внешнего провайдера подключить) -- с некоторыми навыками программирования на Elisp можно достраивать под себя LLM-ассистентов под самые разные задачи (в том числе для написания нового кода на Elisp!). Не ощущал большой пользы от нейросетей в их чатовой инкарнации, пока не обнаружил интеграции с Emacs, просто теперь много всякой рутины делается локальной LLM на видеокарте, без утомительных промптов, поскольку один раз настроив их можно добавлять как новые команды в Emacs: как выделить кашу из текста и сделать markdown-таблицу, перевести на другой язык, поревьюить код. В готовом виде это же имеется в том же Jetbrains плагинами к разным "AI"-провайдерам, но в Emacs это удобно доделывать самому, сочетая в командах код Elisp с работой LLM под свои конкретные задачи. Ну опять жe emacs doctor получил более интеллектуальную форму :)
И напоследок, старая шутка про GNU/Emacs, которую почему-то упустили в статье: https://xkcd.com/378/ Если что это не шутка, just type "M-x butterfly" в редакторе.
Ага, это вероятно самый частый аргумент в спорах о выборе IDE: всё готовое против конструктора. Так то оно так, но когда десятилетия жизни уходят на работу с кодом и сопутствующие задачи, начинаешь ценить инструменты, которыми делаешь эту работу. И понимаешь, что проще вникнуть и настроить, чем всю жизнь делать какие-то действия неудобным и длинным путем, просто потому что авторы "мейнстримного" продукта не предусмотрели другого пути. В Emacs (как и полагаю в Vim) изначально пути нет вообще, его прокладываешь себе сам, но раз проложив бегаешь по нему очень быстро :) Поэтому, наш выбор -- только Linux, только Emacs! :)
Не соглашусь, хотя на Windows не пробовал но осуждаю :) Мой опыт это Linux и меньше Mac -- определенно, после других IDE, Emacs выглядит очень легковесно, скорость работы без нареканий даже на всяком убитом железе . Вообще же, в нём хватает старых кривых плагинов, которые что-то синхронно и медленно пытаются делать, но полезные и используемые массово плагины поддерживаются сообществом, эволюционируя в том числе по производительности. Последние лет пять много чего перевели на асинхронный режим, хотя в целом асинхронное исполненение кода в Emacs по-прежнему выглядит нестандартно. Тут бы движок бекенда радикально сменить, вероятно еще через десятки лет к этому придут :)
У меня лично на одном железе установленные Emacs и Jetbrains Goland при работе по сути в одних задачах, сравнения практически всегда не в пользу последнего. Не говоря уже об удобстве, тот же Magit в Emacs -- против архачных всплывающих диалогов и иерархических меню в современных IDE. В Jetbrains хотя бы озаботились всякими вариантами поиска, но до Emacs, где на поисковых диалогах весь интерфейс, по-моему всё ещё далеко по удобству.
Однако, ковыряясь в коде на Elisp, нередко замечал всякое типа, "если Windows, то...", подозреваю неэффективность может прятаться в таких ветках, где даже внешние утилиты вызываются на разных системах разные. Всё же основное использование Emacs исторически на unix-системах.
А так, у меня к примеру установлено >300 пакетов, первый старт Emacs с ними ~2 секунды (но это дистрибутив Doom Emacs, где пакеты предкомпилируются после установки). Дальше новые окна запускаются как клиенты к emacs-server и всю рабочую сессию запуски практически мгновенные за доли секунды.
Teledildonics mode как пример плагина в Emacs: https://youtu.be/D1sXuHnf_lo?si=uo3sNGG4EJdtz9-c -- в зависимости от количества скобок в текущем Lisp-выражении увеличивается амплитуда вибрации девайса, можно оценить все ли скобки закрыты. Глубже, еще глубже, aах, бесконечная рекурсия!
Про "тяжеловесность" Emacs борода тоже уходит в прошлый век, ну это уже прям неэтично так шутить, особенно когда смотришь сколько отъедают современные IDE и средства обработки текста :)
В общем и целом, как Vim с Emacs хоронили, так и будут пытаться хоронить, их это не задевает. Врядли они окажутся в топе по использованию, но у них достаточное обширное и что любопытно, пополняющееся новичками коммьюнити, чтобы успевать адаптироваться под меняющиеся условия мира. IDE приходят и уходят, Emacs с Vim остаются :) Для меня оба этих инструмента -- это примеры успешного и качественного софта.
Тут автор перевода подразумевает видимо лицензии вроде MIT или BSD. Тогда уж не "разрешенную" (её запрещали?), а разрешительную лицензию. Хотя и "пермиссивную" пишут, тоже звучит понятно.
Несколько некорректное заявление, что модели DeepSeek V1 и V2 были малоизвестны за пределами КНР. О них конечно не писали на каждом заборе, как о разработках лидеров в этой области, как ClosedOpenAI, Google или Meta, но поскольку модели были в опенсорсе, то они активно использовались энтузиастами и обсуждались в профильных сообществах. Судя по лайкам на huggingface или github вполне себе были известны.
А вдруг экстраполяция в моделях уже более точна, чем исторические записи? И в древнем Египте на самом-то деле была постоянная армия с бронетехникой? А Земля вообще плоская!
То же от Qwen2.5-coder. Первый ответ порадовал своей железной логикой! Но с уточненным вопросом модель уже справилась :)
Ответ про сестер
** Human🧘: У Анны 3 сестры и 1 брат, сколько сестер у брата Анны?
** Machine🐱: У брата Анны также 3 сестры, так как все сестры Анны также являются сестрами его брата. Брат Анны не считается сестрой, поэтому число сестер остается неизменным.
** Human🧘: Подумай. У Анны 3 сестры и 1 брат. То есть у брата тоже три сестры. Но при этом Анна тоже его сестра. Сколько всего сестер у брата?
** Machine🐱: Вы абсолютно правы. Анна также является сестрой своего брата. Следовательно, у брата Анны 4 сестры: 3 сестры Анны плюс Анна сама.
Именно так, попробовал этот вопрос в точности в постановке автора локально, на модели Qwen2.5-Coder (32B). Сначала получил ответ с выводами как у gpt4o, только Qwen сам явно выделил момент, что выше 100-й ступени подняться нельзя, и это плюс, т.к. gpt4o эту подробность опустил, а ведь вывод он сделал, если принять неявно такое условие, верный. Это две старшие модели себе уже понапридумывали бесконечную лестницу :)
Ответ на исходный вопрос от Qwen
Давайте разберем ваше движение. Вы начинаете на 100й ступени, и на каждом шаге вы перемещаетесь следующим образом:
1 шаг вниз: на 99-й ступени.
2 шага вверх: на 101-ю ступень (но так как мы не можем быть выше 100-й ступени, вы остаетесь на 100-й ступени).
3 шага вниз: на 97-й ступени.
4 шага вверх: на 101-ю ступень (снова остаетесь на 100-й).
5 шагов вниз: на 95-й ступени.
6 шагов вверх: на 101-ю ступень (опять остаетесь на 100-й).
И так далее. Видно, что каждый раз, когда вы пытаетесь подняться на ступени больше, чем осталось до верхней, вы остаетесь на верхней ступени. Это значит, что вы никогда не сможете уйти с верхней ступени и, соответственно, не дойдете до нижней ступени.
Таким образом, ответ на ваш вопрос — нет, вы никогда не дойдете до нижней ступени лестницы, продолжая эту последовательность движения.
Жаль на уточненном вопросе (с добавлением условия "Число ступеней неограничено вверх и вниз.") модель Qwen слилась. Вывод дала верный, но число шагов ошибочное, хотя выглядело всё красиво с формулами:
Заключение от Qwen по скорректированному вопросу
Понял, теперь давайте разберем вашу последовательность движений в условиях бесконечной лестницы.
Вы начинаете на 100й ступени и делаете следующие шаги:
Спускаетесь на 1 ступень: на 99-ю ступень.
Поднимаетесь на 2 ступени: на 101-ю ступень.
Спускаетесь на 3 ступени: на 98-ю ступень.
Поднимаетесь на 4 ступени: на 102-ю ступень.
Спускаетесь на 5 ступени: на 97-ю ступень.
Поднимаетесь на 6 ступени: на 103-ю ступень.
И так далее...
Общая формула вашего положения на n-ом шаге будет следующей:
На нечетных шагах (спуск): ( 100 - \frac{n(n-1)}{2} )
На четных шагах (подъем): ( 100 + \frac{n(n-1)}{2} )
После нечетного шага n, ваша позиция будет ( 100 - \frac{n(n-1)}{2} ).
Нам нужно найти такое n, при котором ( 100 - \frac{n(n-1)}{2} \leq 0 ). Это означает, что вы достигнете или опуститесь ниже нижней ступени.
Решим квадратное уравнение ( n^2 - n - 200 = 0 ) с помощью формулы: [ n = \frac{-b \pm \sqrt{b^2 - 4ac}}{2a} ] где ( a = 1 ), ( b = -1 ), ( c = -200 ).
Таким образом, на 15-м шаге вы достигнете позиции ниже нижней ступени. Следовательно, вы действительно доберетесь до нижней ступени, продолжив эту последовательность движений.
Ответ: Да, вы доберетесь до нижней ступени лестницы.
// формулы модель выдает в LaTeX, не знаю как это на Хабре визуализировать красиво
Верный же ответ 197 до 1 ступени (или 199 до 0 ступени) удалось получить только на просьбу явно промоделировать задачу, без формул, но это читерство :) В конце попросил оформить модель в виде кода на Go, который позволил бы проверить ответ, не вникая в формулы, тут уже модель справилась и дала простенькую программу, результаты по ней верные и легко проверяйтся. Вот это наш путь! :)
Сгенеренный код
package main
import (
"fmt"
)
func main() {
startStep := 100
currentStep := startStep
var n int
for {
n++
if n%2 == 1 { // Нечетный шаг: спуск
currentStep -= n
} else { // Четный шаг: подъем
currentStep += n
}
if currentStep <= 0 {
break
}
}
fmt.Printf("Доберешься до нижней ступени на шаге %d.\n", n)
fmt.Printf("Твоя позиция на шаге %d: %d\n", n, currentStep)
}
В общем, надо тщательно задавать условие, в данном случае, что ступени могут идти вверх бесконечно, а внизу ограничены 1 или 0 (смотря до куда хотим дойти -- до пола или до первой ступени :)
Мой вывод по моделям: пока что все они выглядят сомнительно, не стоит ожидать многого, чтобы не разочаровываться. Тем не менее некоторое очарование в них есть, особенно когда формулами красиво сыпят :)
Я, например, Qwen-coder использую как помощник в IDE (Emacs + ellama) по всяким мелким задачам и результат мне нравится. Такое парное программирование с джуном-котиком :) Если ему дать несложную задачу и объяснить детали, он выдаст годный результат! Если же полениться с постановкой, то потом сам себе припомнишь "зачем я с этим связался? самому же было проще сделать". А иногда, обьясняешь-объясняешь, а он тебе "мяу" в ответ...
Repomap №... :) Для парсинга кода с отсечением лишнего в подобных проектах часто обращаются к treesitter (см. например https://aider.chat/2023/10/22/repomap.html). На Go к нему есть бинды. Однако, утилит делающих repomap на Go + treesitter до сих пор не встретил. Сам использую https://github.com/wyattcupp/codesnap, там тоже без treesitter. Жду, кто бы прикрутил это вместе :)
Сайт mindprison.cc это блог некоего https://substack.com/@dakara Кто он и насколько владеет экспертизой я не знаю. Какой-то айтишник :) Да и так ли это важно? Авторитетные эксперты тоже могут ошибаться или попросту врать в своих интересах. Мне понравились статьи на сайте, хотя не со всем могу согласиться и местами автор откровенно сгущает краски. Однако, он подкрепляет высказывания ссылками на ресерчи, можно поразбираться самому, не веря на слово. Из статьи которую приводил выше, к примеру, ссылка на интересное исследование Anthropic "On the Biology of LLM". Имхо, автор хотя бы пытается разобраться в темах о которых пишет, не просто компилирует подборки трендовых новостей о грядущих массовых увольнениях ;)
Из авторитетов в приведенной статье Yann Lecun, который озвучивает по сути то, что автор расписывает всю статью ссылаясь на исследования компаний: в развитии LLM огромный прогресс и это продолжится, но к AGI это развитие не ведёт, там пропасть, для преодоления которой нужны другие идеи и алгоритмы.
Альтернативное мнение на тему скорого AGI: https://www.mindprison.cc/p/no-progress-toward-agi-llm-braindead-unreliable
Для ленивых вывод из статьи в одной картинке
Туда же в тему интервью с Яном ЛеКун, главным по
тарелочкамAI в Meta (организация запрещенная в РФ): https://youtu.be/BytuEqzQH1U?si=UF2OaApcOMzJoDsNКак я понимаю, Cursor (как и Aider, Plandex и прочие), как раз в этом помогают, строя карту по коду (repomap) и убирая лишнее через tree-sitter, чтобы минимизировать контекст. В Cursor еще RAG как-то задействовали, судя по их заявлениям.
Да я может быть красочно описал. Локальные модели тянут, но задачи им даю попроще. Уровня: опиши создание библиотеки по доке, теперь создай, допиши юнит-тесты -- именно так, поэтапно, и конечно с более подробными промптами. В целом, на таких задачах существенной разницы по качеству кода с использованием больших платных моделей в Cursor я не увидел. Но в Cursor я могу попросить что-нибудь в стиле "спроектируй взаимодействие этих двух сервисов" и дать на входе оба репозитория с сотнями файлов, в Aider на моих локальных мощностях так конечно не прокатит. Хотя если его подключать к платным провайдерам, то подозреваю выход будет плюс-минус такой же.
Btw, для себя раньше интересовался Flutter, и понятно дело в отсутствие проектов по работе дальше простых примеров оно не пошло, я на своем бекенде сильно далек от мобильной разработки. Прям любопытно попробовать снова, с новым доступным нейро-инструментарием, глядишь дело дальше продвинется :)
Спасибо :) Использую на Linux и софт в целом тоже ориентирован на работу в Linux, в основном бэкенды для веба, плюс мелкие GUI. Код на Golang, редко Python или C (в последний без нейросетей я бы и не полез). Ну и Elisp ещё. Модели подбираю чтобы вписались в AMD Radeon 7900XTX (llama.cpp через Vulkan), однако последнее время использую связку с Macbook на M3, который на удивление шустро работает с LLM, по скорости не хуже чем на указанной видеокарте! AMD Radeon выбирал как более удобный для работы в Linux и память на этой видюхе 24G, но судя по всему Nvidia + CUDA всё ещё рулят здесь, так что мой вариант не оптимален.
Для проектирования хорошо подходят "рассуждающие" модели как DeepSeek R1. А для кодинга и в принципе любых задач с инструментами Qwen2.5 или Gemma. Последнее используемое это deepseek-r1-distill-qwen-32B на m3 + gemma-3-27B-it-QAT на Radeon. Aider позволяет с некоторыми ухищрениями прицепить модели от разных провайдеров и мне так удалось зацепить LM Studio на маке с Llama.cpp, так что режим "архитектор" в Aider использует Deepseek с мака, а для исполнения плана и создания файлов применяет локальную Gemma в Llama.cpp. С Cursor шаманств поменьше, "включил и работает", но и ограничений больше, главное из которых это жесткая привязка к VS Code в их собственном исполнении. Даже коллеги привыкшие для Go к Jetbrains Goland сильно плачут, мне же после Emacs вовсе непонятно как этим удобно пользоваться :) Тем не менее, если абстрагироваться от ограничений IDE, то Cursor в связке с DeepSeek-R1 для построения планов + Gemini 2.5 или Sonnet 3.7 для кода -- это прям огонь, позволяет анализировать и править код довольно жирных сервисов на Go (особенно с Gemini Pro, у которого огромный входной контекст).
В целом выбор моделей на мог взгляд есть некоторая вкусовщина. Определенно, для построения плана "что делать" лучшие результаты дают thinking-модели. А дальше реализацию по ним вообще не критично какой модели отдать, лишь бы понимала работу с инструментами. Так то результаты плавают от случая к случаю. Тем более, я тесты моделей не проводил, просто решаю свои задачки, поэтому мои рекомендации здесь определенно не точны. Для своих задач получите свои предпочтения.
Использую Aider и Cursor, последний поскольку работодатель оплачивает, а первый опенсорсный и легко прикручивается к разным IDE и моделям (у меня это Emacs + локальные модели на видеокарте через llama.cpp). По опыту применения у меня сложилось примерно такое же мнение, как у автора статьи, подобные инструменты хорошо годятся для автоматизации рутинных задач, для исправления простых ошибок в коде, даже порой помогают увидеть вещи которые своим взглядом упустил. Вероятно в будущем они смогут делать всё это лучше и быстрее. Но пока нужно очень тщательно смотреть
не нарисовала ли сеточка шесть пальцеви ревьюить результаты. И действительно сложные вещи, где требуется глубокое понимание языка/платформы/библиотек пока проще оставлять на себя, даже не пытаться это промптить. Т.к. это как если бы вы все нюансы пытались описать джуну, а потом посмотрев результаты его работы просто переписывали код сами, чертыхаясь, что зря потратили время на объяснения. В любом случае, прогресс в инструментарии вокруг нейросетей за последние годы выглядит внушительно и результаты можно применять с большой пользой уже сейчас. Но отдача от них прямо пропорциональна вашей собственной экспертизе! Схема, когда ничего не понимающий в IT человек создает сложные программы всё ещё не работает. В будущем со strong AI полагаю заработает, а пока здесь много хайпа на теме и результаты стоит воспринимать скептически и внимательно анализировать восторженные отзывы. Однако, не стоит их также недооценивать!Отличный набор проектов и технологий для добавления в резюме! Всё равно резюме никто не читает.
А ведь альтернативных вариаций C довольно немало изобретено, и есть успешно развиваемые (как примеры можно вспомнить Zig или Hare). Конечно по популярности им очень далеко не только до прародителя, но и до того же Rust. Однако, в сравнении с Rust, они значительно понятнее разработчикам на C, так как исходная "база" языка оставлена, при этом дают современный тулинг (то чем хорош Rust), при этом быструю компиляцию и главное, устраняют основные проблемы, за которые ругают оригинальный С с неоднозначным синтаксисом, мутным препроцессингом и пр. Тут опять же не стоит прямо сравнивать с Rust, где логику программы приходится переосмысливать, чтобы уложить в сильно отличающуюся модель владения памятью и прочие особенности Rust. Вот в том же Hare код выглядит прям очень близко к C, но с более однозначным синтаксисом, более строгой обработкой ошибок и т.п. вроде как мелочами, но код как-то приятнее пишется и легче воспринимается (тут субъективно конечно). Жаль, что пока такие языки далеки от мейнстрима и маловероятно, что в ближайшем будущем их будут рассматривать как варианты для языка Linux kernel.
Вы открыли мне мир! :) Я как в прошлом веке научился таки вместо kill -9 использовать ":wq" (или ":wq!" для тяжелых случаев), так им и пользуюсь. Уже привычкой стало не трогать Ctl-C или Ctl-D в Vi :\
Чтобы осовременить архаично лайтовое содержание статьи добавлю актуальных ссылок, на ресурсы о современном GNU/Emacs, а не о том Emacs который воображают себе пользователи разных "современных IDE" :P К сожалению не помогу ссылками на Vim ибо практически им не пользуюсь, тут пусть местные вимеры подскажут.
И в любом случае вимеры все сгорят в адуВ общем вы поняли на какой я стороне.Учебные материалы от System Crafters: https://systemcrafters.net/guides/#gnu-emacs -- у них там всякое по подписке, но с сайта просто см. ссылки на уроки и подкасты на Youtube. Там же про всякое сопутствующее в Lisp-style, как дистрибутив GNU/Guix и прочую linux-альтернативщину :)
Living an awesome life by Sacha Chua https://sachachua.com/blog/ -- блог гиковой филлипинки, который она ведет уже два десятилетия.
https://www.reddit.com/r/emacs/ + https://www.reddit.com/r/emacsporn/ -- понятно было, что на реддите этого не могло не быть )
Популярные must have расширения, ради которых стоит всё это изучить:
https://orgmode.org
https://www.orgroam.com/
https://magit.vc/
Из трех компонентов выше можно построить как минимум бекап мозга с файловыми аттачами и версионированием :)
Рекомендуемое по личному опыту:
https://github.com/doomemacs/doomemacs (или для эстетов https://www.spacemacs.org/)
https://docs.projectile.mx/projectile/
https://github.com/Alexander-Miller/treemacs
https://emacs-lsp.github.io/lsp-mode/
https://github.com/abo-abo/avy
https://github.com/minad/vertico
https://github.com/joaotavora/yasnippet
https://github.com/flycheck/flycheck
...вообще их конечно много больше, а часть из указанных имеют альтернативы, которые не хуже, даю ссылки для привлечения внимания, разобравшись и настроив эти плагины можно получить очень удобную в навигации и для редактирования среду.
Из последнего, чем начал пользоваться только в этом году: https://github.com/s-kostyaev/ellama + https://github.com/ahyatt/llm + llama.cpp (но тут можно и внешнего провайдера подключить) -- с некоторыми навыками программирования на Elisp можно достраивать под себя LLM-ассистентов под самые разные задачи (в том числе для написания нового кода на Elisp!). Не ощущал большой пользы от нейросетей в их чатовой инкарнации, пока не обнаружил интеграции с Emacs, просто теперь много всякой рутины делается локальной LLM на видеокарте, без утомительных промптов, поскольку один раз настроив их можно добавлять как новые команды в Emacs: как выделить кашу из текста и сделать markdown-таблицу, перевести на другой язык, поревьюить код. В готовом виде это же имеется в том же Jetbrains плагинами к разным "AI"-провайдерам, но в Emacs это удобно доделывать самому, сочетая в командах код Elisp с работой LLM под свои конкретные задачи. Ну опять жe emacs doctor получил более интеллектуальную форму :)
И напоследок, старая шутка про GNU/Emacs, которую почему-то упустили в статье: https://xkcd.com/378/
Если что это не шутка, just type "M-x butterfly" в редакторе.
Ага, это вероятно самый частый аргумент в спорах о выборе IDE: всё готовое против конструктора. Так то оно так, но когда десятилетия жизни уходят на работу с кодом и сопутствующие задачи, начинаешь ценить инструменты, которыми делаешь эту работу. И понимаешь, что проще вникнуть и настроить, чем всю жизнь делать какие-то действия неудобным и длинным путем, просто потому что авторы "мейнстримного" продукта не предусмотрели другого пути. В Emacs (как и полагаю в Vim) изначально пути нет вообще, его прокладываешь себе сам, но раз проложив бегаешь по нему очень быстро :) Поэтому, наш выбор -- только Linux, только Emacs! :)
Не соглашусь, хотя на Windows не пробовал
но осуждаю:) Мой опыт это Linux и меньше Mac -- определенно, после других IDE, Emacs выглядит очень легковесно, скорость работы без нареканий даже на всяком убитом железе . Вообще же, в нём хватает старых кривых плагинов, которые что-то синхронно и медленно пытаются делать, но полезные и используемые массово плагины поддерживаются сообществом, эволюционируя в том числе по производительности. Последние лет пять много чего перевели на асинхронный режим, хотя в целом асинхронное исполненение кода в Emacs по-прежнему выглядит нестандартно. Тут бы движок бекенда радикально сменить, вероятно еще через десятки лет к этому придут :)У меня лично на одном железе установленные Emacs и Jetbrains Goland при работе по сути в одних задачах, сравнения практически всегда не в пользу последнего. Не говоря уже об удобстве, тот же Magit в Emacs -- против архачных всплывающих диалогов и иерархических меню в современных IDE. В Jetbrains хотя бы озаботились всякими вариантами поиска, но до Emacs, где на поисковых диалогах весь интерфейс, по-моему всё ещё далеко по удобству.
Однако, ковыряясь в коде на Elisp, нередко замечал всякое типа, "если Windows, то...", подозреваю неэффективность может прятаться в таких ветках, где даже внешние утилиты вызываются на разных системах разные. Всё же основное использование Emacs исторически на unix-системах.
А так, у меня к примеру установлено >300 пакетов, первый старт Emacs с ними ~2 секунды (но это дистрибутив Doom Emacs, где пакеты предкомпилируются после установки). Дальше новые окна запускаются как клиенты к emacs-server и всю рабочую сессию запуски практически мгновенные за доли секунды.
Teledildonics mode как пример плагина в Emacs: https://youtu.be/D1sXuHnf_lo?si=uo3sNGG4EJdtz9-c -- в зависимости от количества скобок в текущем Lisp-выражении увеличивается амплитуда вибрации девайса, можно оценить все ли скобки закрыты. Глубже, еще глубже, aах, бесконечная рекурсия!
Про "тяжеловесность" Emacs борода тоже уходит в прошлый век, ну это уже прям неэтично так шутить, особенно когда смотришь сколько отъедают современные IDE и средства обработки текста :)
В общем и целом, как Vim с Emacs хоронили, так и будут пытаться хоронить, их это не задевает. Врядли они окажутся в топе по использованию, но у них достаточное обширное и что любопытно, пополняющееся новичками коммьюнити, чтобы успевать адаптироваться под меняющиеся условия мира. IDE приходят и уходят, Emacs с Vim остаются :) Для меня оба этих инструмента -- это примеры успешного и качественного софта.
Тут автор перевода подразумевает видимо лицензии вроде MIT или BSD. Тогда уж не "разрешенную" (её запрещали?), а разрешительную лицензию. Хотя и "пермиссивную" пишут, тоже звучит понятно.
Несколько некорректное заявление, что модели DeepSeek V1 и V2 были малоизвестны за пределами КНР. О них конечно не писали на каждом заборе, как о разработках лидеров в этой области, как
ClosedOpenAI, Google или Meta, но поскольку модели были в опенсорсе, то они активно использовались энтузиастами и обсуждались в профильных сообществах. Судя по лайкам на huggingface или github вполне себе были известны.А вдруг экстраполяция в моделях уже более точна, чем исторические записи? И в древнем Египте на самом-то деле была постоянная армия с бронетехникой?
А Земля вообще плоская!То же от Qwen2.5-coder. Первый ответ порадовал своей железной логикой! Но с уточненным вопросом модель уже справилась :)
Ответ про сестер
** Human🧘: У Анны 3 сестры и 1 брат, сколько сестер у брата Анны?
** Machine🐱:
У брата Анны также 3 сестры, так как все сестры Анны также являются сестрами его брата. Брат Анны не
считается сестрой, поэтому число сестер остается неизменным.
** Human🧘:
Подумай. У Анны 3 сестры и 1 брат. То есть у брата тоже три сестры. Но при этом Анна тоже его сестра. Сколько всего сестер у брата?
** Machine🐱:
Вы абсолютно правы. Анна также является сестрой своего брата. Следовательно, у брата Анны 4 сестры:
3 сестры Анны плюс Анна сама.
Именно так, попробовал этот вопрос в точности в постановке автора локально, на модели Qwen2.5-Coder (32B). Сначала получил ответ с выводами как у gpt4o, только Qwen сам явно выделил момент, что выше 100-й ступени подняться нельзя, и это плюс, т.к. gpt4o эту подробность опустил, а ведь вывод он сделал, если принять неявно такое условие, верный. Это две старшие модели себе уже понапридумывали бесконечную лестницу :)
Ответ на исходный вопрос от Qwen
Давайте разберем ваше движение. Вы начинаете на 100й ступени, и на каждом шаге вы перемещаетесь следующим образом:
1 шаг вниз: на 99-й ступени.
2 шага вверх: на 101-ю ступень (но так как мы не можем быть выше 100-й ступени, вы остаетесь на 100-й ступени).
3 шага вниз: на 97-й ступени.
4 шага вверх: на 101-ю ступень (снова остаетесь на 100-й).
5 шагов вниз: на 95-й ступени.
6 шагов вверх: на 101-ю ступень (опять остаетесь на 100-й).
И так далее. Видно, что каждый раз, когда вы пытаетесь подняться на ступени больше, чем осталось до
верхней, вы остаетесь на верхней ступени. Это значит, что вы никогда не сможете уйти с верхней
ступени и, соответственно, не дойдете до нижней ступени.
Таким образом, ответ на ваш вопрос — нет, вы никогда не дойдете до нижней ступени лестницы,
продолжая эту последовательность движения.
Жаль на уточненном вопросе (с добавлением условия "Число ступеней неограничено вверх и вниз.") модель Qwen слилась. Вывод дала верный, но число шагов ошибочное, хотя выглядело всё красиво с формулами:
Заключение от Qwen по скорректированному вопросу
Понял, теперь давайте разберем вашу последовательность движений в условиях бесконечной лестницы.
Вы начинаете на 100й ступени и делаете следующие шаги:
Спускаетесь на 1 ступень: на 99-ю ступень.
Поднимаетесь на 2 ступени: на 101-ю ступень.
Спускаетесь на 3 ступени: на 98-ю ступень.
Поднимаетесь на 4 ступени: на 102-ю ступень.
Спускаетесь на 5 ступени: на 97-ю ступень.
Поднимаетесь на 6 ступени: на 103-ю ступень.
И так далее...
Общая формула вашего положения на n-ом шаге будет следующей:
На нечетных шагах (спуск): ( 100 - \frac{n(n-1)}{2} )
На четных шагах (подъем): ( 100 + \frac{n(n-1)}{2} )
После нечетного шага n, ваша позиция будет ( 100 - \frac{n(n-1)}{2} ).
Нам нужно найти такое n, при котором ( 100 - \frac{n(n-1)}{2} \leq 0 ). Это означает, что вы
достигнете или опуститесь ниже нижней ступени.
Решим неравенство:
[ 100 - \frac{n(n-1)}{2} \leq 0 ]
[ 200 \leq n(n-1) ]
[ n^2 - n - 200 \geq 0 ]
Решим квадратное уравнение ( n^2 - n - 200 = 0 ) с помощью формулы:
[ n = \frac{-b \pm \sqrt{b^2 - 4ac}}{2a} ]
где ( a = 1 ), ( b = -1 ), ( c = -200 ).
[ n = \frac{1 \pm \sqrt{1 + 800}}{2} = \frac{1 \pm \sqrt{801}}{2} ]
Приближенное значение:
[ n \approx \frac{1 + 28.3}{2} \approx 14.65 ]
Так как n должно быть целым числом, возьмем ( n = 15 ).
Проверим:
На 15 шаге (нечетное, спуск): [ 100 - \frac{15 \cdot 14}{2} = 100 - 105 = -5 ]
Таким образом, на 15-м шаге вы достигнете позиции ниже нижней ступени. Следовательно, вы
действительно доберетесь до нижней ступени, продолжив эту последовательность движений.
Ответ: Да, вы доберетесь до нижней ступени лестницы.
// формулы модель выдает в LaTeX, не знаю как это на Хабре визуализировать красиво
Верный же ответ 197 до 1 ступени (или 199 до 0 ступени) удалось получить только на просьбу явно промоделировать задачу, без формул, но это читерство :) В конце попросил оформить модель в виде кода на Go, который позволил бы проверить ответ, не вникая в формулы, тут уже модель справилась и дала простенькую программу, результаты по ней верные и легко проверяйтся. Вот это наш путь! :)
Сгенеренный код
В общем, надо тщательно задавать условие, в данном случае, что ступени могут идти вверх бесконечно, а внизу ограничены 1 или 0 (смотря до куда хотим дойти -- до пола или до первой ступени :)
Мой вывод по моделям: пока что все они выглядят сомнительно, не стоит ожидать многого, чтобы не разочаровываться. Тем не менее некоторое очарование в них есть, особенно когда формулами красиво сыпят :)
Я, например, Qwen-coder использую как помощник в IDE (Emacs + ellama) по всяким мелким задачам и результат мне нравится. Такое парное программирование с джуном-котиком :) Если ему дать несложную задачу и объяснить детали, он выдаст годный результат! Если же полениться с постановкой, то потом сам себе припомнишь "зачем я с этим связался? самому же было проще сделать". А иногда, обьясняешь-объясняешь, а он тебе "мяу" в ответ...