[О блоге] [наверх] [пред] [2022-07-03 21:06:33+03:00] [1663d9d463041807b70067497fe45249e45b7755]
Темы: [vim]

vim9script vs Neovim

Спросили меня тут про vim9script:

    Мне кажется, что это сложный и отчасти тупиковый путь. В таком
    контексте Lisp (и конкретно ELisp) в Emacs выглядит как изначально
    более рациональное решение. Смотрел ли ты в сторону neovim с его упором
    на поддержку Lua?

И вот мои мысли на этот счёт:

    Меня тоже посещали аналогичные мысли, когда я впервые услышал про то,
    что в Vim пилят новый язык. Поддержка других языков, кроме vimscript,
    была давным давно: видел/использовал плагины на Perl и Python. Но их
    использование было связано в первую очередь, насколько мне запомнилось,
    банально отсутствием асинхронных задач в Vim. С их появлением в Vim8, я
    больше плагинов не на vimscript уже не встречал. Я писал когда-то их на
    Python, так как он был и основным рабочим языком у меня, но позже как-то
    само собой всё переписалось на vimscript.

    Мне кажется что неявная killer-feature программирования на vimscript это
    то, что ты постоянно находится в экосистеме редактора. У тебя идёт не
    кусок кода на Perl/Python/Lua/Tcl/whatever, а потом внезапный вызов
    vim.run("kj$R$3lrk4r") абракадабры интерактивного ввода, а ты пишешь на
    языке в котором прямо в его скрипте можно написать "normal gg:%d"
    какой-нибудь. Когда пишешь "mark '", "@/ = 'pattern'", "execute smth",
    то все его задействованные переменные, метки и регистры являются родными
    объектами редактора. Вместо программирования на чём-то в интерпретаторе,
    делая API вызовы к редактору, ты находишься в контексте редактора
    постоянно. Всё это позволяет прямо мгновенно на коленке взять и писать
    себе скрипт для какой-нибудь автоматизации. Не полноценную программу на
    настоящем большом языке, делая API вызовы к редактору, а именно писать
    внутри редактора. Не знаю как корректнее выразиться, но это всё прям на
    ощущениях.

    И поэтому у меня давным давно не возникает применять что-то кроме
    vimscript для скриптования Vim-а. Vimscript пускай и странен, и некрасив
    и уродлив местами (всякие странные переносы, "call"-ы например), но по
    возможностям он вполне себе предоставляет кучу всего (словари, списки,
    лямбды, даже методы -- не существенно отличаясь от всяких более
    привычных Python/JavaScript/Lua). Для знакомых с Py/JS -- в vimscript
    очень небольшой порог входа и куда более тесная интеграция с редактором.
    Я думаю поэтому и не приживаются его плагины на сторонних языках,
    особенно после появления асинхронных задач в Vim8. Я писал на Python,
    думал что это точно будет удобнее, ведь я и вне редактора его
    использовал, но положительных воспоминаний у меня не осталось, хотя по
    сути там точно такие же "normal ..." вызовы можно было делать например,
    но не чувствовался profit от неиспользования vimscript-а.

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

    Что он мне дал бы дополнительного, как пользователю редактора? Я знаю
    только про встроенный LSP клиент. В Vim-е это был бы вопрос одного
    плагина. More sane defaults -- слишком субъективно, да и какая разница
    будет ли на пару строк больше/меньше в .vimrc? Всё равно без
    персонифицированного .vimrc не обойтись.

    То есть, Neovim должен иметь какую-то крутую killer-feature чтобы
    переход на него (прозрачно у меня не вышло ни разу -- он не полностью
    обратно совместим) стоил того. LSP не является такой feature. Может быть
    Lua как альтернатива vimscript? Просто Lua можно было и прежде
    использовать в Vim. Причины того, что сторонние языки не приживаются я
    описал (как мне они видятся). В Neovim это мог бы быть luajit с
    увеличенной производительностью. Пока это единственная возможная
    killer-feature.

    Которая теперь полностью нивелируется vim9script. В случае с Neovim мне
    надо бы было полностью на другом языке переписать свои плагины. Это не
    малая работа. И изучать этот новый язык Lua (лично я на нём год писал,
    мне он нравится, но многие никогда с ним не пересекались). В случае с
    vim9script, "конвертация" vimscript в vim9script -- небольшая работа.
    Этот новый язык не отличается кардинально от старого. Плюс ещё более
    дружелюбен к тем, кто писал на Py/Lua/JS/whatever. Переделать vimscript
    на vim9script -- существенно менее трудозатратно, при этом, как заверяет
    Брэм (ну и другие люди в рассылке), можешь получить ускорение на
    порядки.

    В итоге: трудозатрат на порядки меньше, профит в производительности
    получишь. И опять у Neovim не выходит ни одной killer-feature стоящей
    рассмотрению перехода на него. Ну и я не забуду что Vim собирался на
    старом ноутбуке за пару минут, а Neovim -- пару часов, что не очень
    приятно (хотя я и понимаю что не каждый день этим занимаешься). Меня не
    очень привлекают решения разработчиков Neovim: если Lua это вполне себе
    хорошее решение (в вакууме для произвольного редактора), то MessagePack
    совершенно не ясен, как будто это какой-то highload проект.

    От vimscript в Neovim не избавиться: так как написаны тысячи плагинов на
    нём. Смысла переписывать хотя бы часто используемые (surround, fugitive
    какие-нибудь) -- никто не нашёл. Сейчас их переделать под vim9script и
    они ещё и быстрее станут. А как язык, vim9script ещё ближе стал к
    привычным современным Py/JS.

    Не исключено что я просто так сильно привык к vimscript что мне он
    заходит и мне с ним легко. Но вот Neovim сколько не существует, но не
    смог заинтересовать ничем, что не требовало бы приличных трудозатрат без
    ясного понимания нафига это надо. А Брэм (и команда) придумали нечто,
    благодаря чему можно без существенных затрат всё ещё сделать красивее и
    удобнее (с точки зрения программирования) и без тормозов. Почти бесплатно.

    Помнится что у Neovim изначально была killer-feature в виде асинхронных
    задач. На нём можно было писать любую асинхронщину на Lua. Но Брэм
    сделал асинхронные задачи в Vim8, которые оказались гораздо удобнее для
    использования и очень простые.

    Vim на протяжении всей своей истории демонстрировал что Брэму нужен
    пинок под зад. Регулярно nvi что-то вкусное изобретал, становился неким
    конкурентном с killer-feature, но в Vim впиливали похожу штуку которая
    была зачастую лучше/проще/яснее. Огромная ценность Neovim в том, что он
    был пинком для создания асинхронных задач в Vim8, ещё какого-то
    функционала (типа balloon-ов и popup-ов, lambda, packages, если не
    придумываю). И вот он был пинком для создания очень простой (с точки
    зрения порога входа) vim9script, который, такие как я, сразу же рвутся
    попробовать и быть им довольным.

    Колоссальная ценность Vim-а же ещё в его плагинах. Если потеряется с
    ними совместимость, то задаёшься вопросом "а нафига мне это тогда
    надо?". Редактор в котором не будет аналога surround/repeat/abolish мне
    не нужно. Писать это с нуля? Даже не могу представить какая killer
    feature в редакторе могла бы появится чтобы заставила меня пойти на это.
    А Брэм даёт возможность развивать и улучшать свой experience новыми
    фичами, не ломая уже рабочие мощнейшие отлаженные инструменты (плагины).

    Neovim говорит ещё о более чистом API, возможности использования разных
    GUI, встраивания в броузеры и IDE. Возможно разрабатывать сам Neovim
    существенно удобнее и проще. Возможно (легко поверю!) Lua внутри него
    существенно помогает. Но конечного profit-а для меня, как пользователя
    это не даёт никакого. Был бы разработчиком инструмента (редактора), то
    наверное бы это играло роль. А как конечный пользователь меня не
    интересует насколько там красивее и проще внутри Neovim-а всё, если я
    при этом не вижу чтобы на всём этом появлялись полезные мне killer
    feature. Это как бы внутренняя кухня, меня не затрагивающая.

    [оставить комментарий]