Несколько дней назад попалась мне одна статья про то, что Vim достаточно хорош как инструмент для разработчика. В комментариях разгорелось очередное противостояние приверженцев vim против остального мира. Мыслей по данному вопросу накопилось достаточно много, поэтому считаю разумным сформулировать их уже в виде статьи. Адепты vim говорят о том что, якобы, освоив vim и полностью настроив его под себя можно получить ощутимую прибавку в скорости разработки. Я же считаю иначе. Лично я в работе использую PhpStorm, поэтому буду сравнивать с vim именно его. Так же оговоримся, что рассматривать инструменты я буду в контексте, деятельности вэб-разработчика. А для наглядности рассмотрим как одни и те же задачи будут решаться в IDE и в Vim. Рабочие инструменты берем в состоянии "из коробки". Предполагаем что на компьютере уже установлен vim или IDE в коробочном варианте.
Начало
Итак есть проект к работе над которым нужно подключиться. Есть репозиторий в котором ведется работа над проектом и дамп базы данных. Какие действия требуются для начала работы? В шторме создается проект сразу из репозитория и автоматически загружается в рабочий каталог. Остается только добавить локальную базу данных, импортировать дамп, подтянуть зависимости и настроить подключение к локальному Xdebug. Все это делается встроенными в IDE средствами. Единственная сложность с которой придется столкнуться - нам придется удерживать повышенный контроль над ходом мыслей во время перекладывания руки с клавиатуры на мышь/тачпад, ведь по заверениям пользователей vim мысль резко обрывается, стоит только оторвать руки от клавиатуры.
В случае с vim придется установить плагин для работы с git, а уже потом скачивать проект. Не знаю есть ли плагин для работы с базами в vim, но даже если и есть время на его поиск, установку и настройку может оказаться больше чем просто развернуть дамп из командной строки в терминале. И это будет первый раз когда нам придется покинуть рабочее окружение. В дальнейшем мы будем вынуждены закрывать рабочее окружение каждый раз, когда нам потребуется какой-то плагин, а требоваться они будут неприлично часто.
Первая задача
Итак получаем первую задачу по проекту. Какой-то функционал ведет себя совсем не так, как должен, и то и вовсе падает с ошибкой. Приступаем. Скорость навигации по каталогам в поисках нужных файлов будет примерно одинаковой потому, что файловый менеджер - он и в Африке файловый менеджер, однако в PhpStorm он уже есть, а для vim снова нужен плагин. И вновь мы тратим драгоценные минуты на установку необходимого функционала.
Если в процессе работы мы встретим в legacy-код, то для начала его надо хоть как-то бы привести в читаемый вид. В IDE придется исполнить аккорд на клавиатуре Alt+Shit+L, однако в этом вопросе vim отличается только аккордом. Точнее у него их несколько.
В IDE, благодаря умному анализу кода, ничего особенного не предпринимая, мы сразу увидим какие переменные не используются, какие циклы окажутся вечными, какие условия никогда не изменятся, а значит мы увидим большинство проблемных мест, просто открыв файл. Vim же предлагает нам внимательно вникать в каждую строчку и выискивать все самостоятельно, проявляя весь свой талант разработчика. Сколько уйдет на это времени и насколько сильно утомится разработчик от такой работы сказать сложно. Видимо именно из-за этого перенос рук с клавиатуры на мышь сбивает vim-овцев c мысли.
Что мы имеем? Мы еще не написали ни одной строчки кода, а разработчик, использующий vim уже потратил ощутимое количество своего ресурса.
Следующим шагом логично посмотреть в дебагере как ведет себя приложение, какие данные откуда и куда ходят, какие значения пишутся в переменные и как они используются. Расставляем брекпоинты (в шторме это тоже можно делать с клавиатуры) и нажимаем Shift+F9. Перед нами откроется полная картина происходящего. IDE выведет все значения переменных не только в окне дебагера, но и наложит их на редактор кода. Можно будет отследить все подключаемые файлы и цепочки вызовов. Сможет ли сделать это vim? Пускай знатоки подскажут в комментариях.
На этапе рефакторинга пользователь vim столкнется с непреодолимыми проблемами. Он не сможет одной кнопкой провалиться в конкретный метод или класс, не сможет быстро переименовать что-то, что используется больше чем в одном месте. Если что-то будет удаляться, vim не подскажет ему, что этот файл используется в другом месте и удаление может поломать систему еще больше. Не узнает он и о том, что и переименование может потянуть за собой цепочку ошибок в других местах.
А если что-то пошло не так? Сможет ли пользователь vim откатиться по локальной истории и вернуть все взад? Или предлагаете коммитить построчно?
А что если мы разрабатываем интерфейс API и нам нужно покидать на него запросы и посмотреть какие приходят ответы? Без проблем - в IDE есть встроенный HTTP-клиент и мы можем баловаться с запросами так, как захотим, а что предлагает нам vim-комьюнити? Использовать штатный консольный клиент операционной системы? Но для этого мы вновь вынуждены покинуть рабочее окружение. И пока ведется разработка, мы так и будем скакать из одного окружения в другое.
Что дальше?
А дальше будут другие задачи. И знаете что? Их тоже можно подключить в свою IDE. PhpStorm из коробки умеет подключаться к таким сервисам, как Jira, Trello, YouTrack, Redmine, Bugzilla, Git, Asana и другим. Вы даже можете отслеживать время затраченное на решение задач. Здесь vim уверенно проигрывает, потому что не рассчитан на командную работу.
Пока что используя, vim мы не получили какой-то существенной прибавки в производительности, а скорее даже наоборот. Так чем же могут похвастаться пользователи vim? Предлагаю рассмотреть аргументацию самих vim-еров чтобы попытаться разобраться в вопросе. Аргументы я искал в комментариях к указанной выше статье, в других статьях и на просторах интернета.
Почему vim?
Vim производительный и может легко открыть файл в несколько гигов.
Да, это правда. А еще правда то, что разработчику не нужно открываться многогиговые файлы. Единственное для чего может пригодиться эта возможность - просмотр логов. Но зачем, когда всю необходимую информацию можно получить в отладчике?
Владея десяти-пальцевым методом вы получаете прибавку в скорости.
Да, но причем здесь vim? Или тот факт что управляется он только с клавиатуры как-то ускорит вам процесс рефакторинга? Современная разработка это по большей части чтение и анализ кода. Владея слепым методом вы просто будете писать быстрее и в vim, и в IDE. А учитывая то, что непосредственно на набор текста уходит меньше всего времени разработчика суммарно вы ничего не выигрываете. А для тех у кого руки приклеены к клавиатуре есть бесчисленное множество шорт-комбинаций и в IDE. Если хотите, можете даже vim-плагин поставить в IDE и радоваться. Для чего нужно отказываться от остальных возможностей IDE, мне не понятно.
Весь функционал vim направлен на то, чтобы пользоваться им без использования мыши. Отсюда многообразие команд. А из многообразия следует их изощренность, которая таковая лишь на первый взгляд.
Отнюдь. Nano тоже работает без мыши. Я, помню, даже DOS-среда разработки Turbo Pascal позволяла комфортно работать без мыши. Просто вместо вменяемого Text User Interface в vim применяется шаманская клавиатурная магия, возникшая стихийно на заре программирования, когда самого понятия «User Interface» еще существовало.
Со своим конфигом от vim можно прийти куда угодно и сразу же получить свою сборку.
Для этих же целей служат файлы .idea
Если чего-то нет в vim, то всегда можно написать самому.
Отлично, но тогда надо признать что редактор нужен только для того чтобы потешить ваше самолюбие, похвастаться тем что вы написали очередной крутой плагин для vim, вместо того чтобы решать задачи. По сути вы просто умело решаете проблемы, которых у вас никогда не было бы, если бы вы сразу использовали IDE.
Вместо заключения
В заключение расскажу одну притчу, которую придумал сам. Жили-были два мужика. Иван, да Матвей. И каждый год они вспахивали поля плугом, а осенью собирали с полей урожай. И чтобы урожай был хорошим - каждый из них как мог усовершенствовал свой плуг. Добавляли в него новые фичи, улучшали эргономику. Иван даже стул к нему приделал на колесиках, чтобы пахать сидя можно было. Но в какой-то момент их пути разошлись. Матвей купил себе трактор и стал собирать урожая кратно больше чем Иван. А Иван обозлился на Матвея и каждый раз проходя мимо трактора Матвея плевал в него, недовольно бормоча про то, что лучше плуга ничего нет и все эти тракторы жутко неудобны и громоздки, да и заправлять их все время надо и запчасти покупать. И как не пытался Матвей убедить Ивана купить себе трактор, но ничего у него не вышло.
Комментарии (72)
Gordon01
02.11.2021 15:12+10В IDE, благодаря умному анализу кода, ничего особенного не предпринимая, мы сразу увидим какие переменные не используются, какие циклы окажутся вечными, какие условия никогда не изменятся, а значит мы увидим большинство проблемных мест, просто открыв файл. Vim же предлагает нам внимательно вникать в каждую строчку и и выискивать все самостоятельно, проявляя весь свой талант разработчика.
Сам пользуюсь вскодом, вим использую только как простой консольный редактор, но то что вы пишете неверно от слова совсем. Монолитная модель закончилась, мы потихоньку переходим на language server которые работают независимо от редактора: https://microsoft.github.io/language-server-protocol/
Вот так это работает в виме: https://youtu.be/h4RkCyJyXmM?t=3362
Сомневаюсь, что вы работаете со скоростью парня из видео.
Следующим шагом логично посмотреть в дебагере как ведет себя приложение
Вы ошибочно полагаете, что разработка через отладку — самый эффективный способ разработки.
А что если мы разрабатываем интерфейс API и нам нужно покидать на него запросы и посмотреть какие приходят ответы?
Пользуюсь Stoplight Studio. https://stoplight.io/studio/
maxxl2
02.11.2021 18:52Вы ошибочно полагаете, что разработка через отладку — самый эффективный способ разработки.
Расскажите поподробнее, пожалуйста, про то, что в данном контексте значит "способ разработки". Вы говорите о, например, TDD vs. debugging или о чем-то другом? Мне было бы интересно узнать ваше мнение об эффективных способах разработки.
Dreamka Автор
02.11.2021 19:43Сомневаюсь, что вы работаете со скоростью парня из видео.
Плюс/минус так же.
Jack_Rabbit
03.11.2021 14:23+1Скорость разработки имеет очень отдаленное отношение к скорости написания кода. Помимо этого сложно сделать хорошее автодополнение не имея локального индекса всего проекта, а также дерева зависимостей.
artem_larin
02.11.2021 15:28+4В общем и целом со статьей согласен, но вот тут хочу добавить комментарий к следующему утверждению:
>>Просто вместо вменяемого Text User Interface в vim применяется шаманская клавиатурная магия, возникшая стихийно на заре программирования, когда самого понятия «User Interface» еще существовало."Шаманство вима имеет вполне определенную логику, оно возникло не стихийно. После vi был vim, а теперь эстафету подхватил neovim, и все эти редакторы исповедуют один и тот же подход. Если бы это было "шаманством", то было бы сомнительно почему эти более современные версии vi имеют такую же логику. А логика простая - сократить кол-во интерактивных прорисовок UI и нажатий на клавиши при работе с текстом на удаленном сетевом терминале, в условиях сетевых тормозов, слабого канала связи. Например, курсор находится на позиции X:
Xsome.property.value="abc 123"
Юзеру нужно заменить abc 123 на другое значение. Работая скажем в нано, придется сначала переводить курсор к началу слова abc, затем стирать abc 123, каждое действие требует отправки команд на удаленный сервер, перерисовки курсора и текста, что занимает сетевой трафик и время. Шаманство вима в данном случае позволяет обойтись всего 3 нажатиями:Перемещаем курсор в начало значения проперти нажатием f" (мнемонически команда запоминается как "find символ")
Одной командой удаляем внутреннее содержимое нажатием ci" (мнемонически это запоминается как change inside парный_символ_кавычка)
Как видно, действий на порядок меньше (буквально 2 действия против десятка в нано или прочем "обычном" редакторе), потребленного сетевого трафика на порядки меньше, отсюда скорость работы с текстом - на порядки быстрее. И это удобно при точечном редактировании каких-то настроечных файлов на удаленном сервере. А в IDE наверное да, не очень удобно, вим все же не для этого придумывали.
А шаманством команды вима кажутся только пока не увидишь, что многие из них имеют вполне конкретные мнемоники, типа f - это find, с - это change, и т.д.
Xeldos
02.11.2021 15:48+6> буквально 2 действия против десятка в нано или прочем «обычном» редакторе
Хоть я и нежно люблю vim, у меня от него глубокая детская травма и стокгольмский синдром, но в «обычном редакторе» вы выполняете простые механические действия, участвует почти исключительно мышечная память, в то время как в vim надо постонно думать — «так, мы находимся в каком режиме? Редактирование, надо перейти в командный, так, где именно у нас курсор? ага, в этой синтаксическо-семантической позиции у нас работае механика №15, вызываемая волшебным сочетанием C+A+D, ой, лишний символ стёрся, ничего, сейчас поправим, всего-то десяток легко запоминаемых клавиш, и мы вызвали историю последних правок и теперь совершенно элементарно находим в ней...».
aelaa
02.11.2021 16:01+10Ни разу не приходилось держать в голове "в каком я режиме". Режим по умолчанию один - командный, остальные включаются по мере необходимости и выключаются сразу после этого.
netch80
03.11.2021 13:29> так, мы находимся в каком режиме? Редактирование
Показывается внизу: пишет "-- INSERT --"
(Может, это не по умолчанию. У меня конфиг vim начинается с:set nocompatible
set ruler
set showcmd
set showmode
syntax on
Но я не представляю, кому нужно без такого работать.)
> надо перейти в командный, так, где именно у нас курсор?
А зачем для перехода в командный режим — курсор?
Вообще же в любом визуальном редакторе надо видеть курсор, чтобы что-то делать. Не вижу тут отличий.
> ага, в этой синтаксическо-семантической позиции у нас работае механика №15, вызываемая волшебным сочетанием C+A+D
эээ… чего?
Вроде у него нет такого…Xeldos
03.11.2021 22:10+1Не просто видеть курсор. Осознавать, где он. В начале строки, в середине слова, перед не-словарным символом, после не-словарного символа… В блокноте, nano, в qbasic наконец ты просто механически делаешь и видишь результат — нажимаю на стрелку, курсор двигается, нажимаю del, символ стирается, и так далее. В vim надо включать мозг. Думать не только о задача, а ещё об инструменте. Осознавать инструмент постоянно, каждую секунду.
При этом, повторюсь, я нежно люблю vim, мне не комфортно в однорежимных редакторах. И игра на пианино в vim действительно завораживает, как и игра на обычном пианино, но если просто нужно послушать музыку, проще её включить.
Revertis
02.11.2021 16:15+8А логика простая - сократить кол-во интерактивных прорисовок UI и нажатий на клавиши при работе с текстом на удаленном сетевом терминале, в условиях сетевых тормозов, слабого канала связи.
А, то есть vi-vim-neovim решают проблему, которой в общем-то почти не бывает у разработчиков.
artem_larin
02.11.2021 16:19Да, поэтому штатного редактора JetBrains разработчику средней руки должно хватить за глаза.
Revertis
02.11.2021 16:25+7Ну вот, я сижу на бесплатных продуктах JetBrains уже лет 12-13, и считаю, что ничего лучше просто нет.
artem_larin
02.11.2021 16:44+1Да, продукты JetBrains изначально были очень хороши, но на мой взгляд последние годы стали деградировать в плане юзабилити, стабильности и keyboard-centric подхода. Я сам работаю на них давно, но сейчас постепенно перехожу на другие решения. Например, докерами и их логами управляться мне проще через tmux, less и bash, которые можно юзать даже на винде через обычную сборку msys2 которая используется для создания дистрибутива гита, и командную строку, потому что в Идее это вроде реализовано, но работает нестабильно, тормознуто и неудобно. Есть желание вообще отказаться от Идеи, lsp в этом плане мне кажется многообещающей идеей.
0xd34df00d
02.11.2021 20:53+1Вам повезло, что для ваших языков эти продукты есть и адекватного качества.
borisxm
02.11.2021 17:01+5Статья основана на изначально неверном посыле: phpstorm, clion, intellij и прочие, это заточенные изготовителем на конкретные задачи инструменты. Причем один не может полноценно стать другим. vim/neovim — это платформа, которую можно заточить самому (или по руководствам) на выполнение необходимых функций. Например, с помощью плагина coc.nvim можно подключить кучу coc-расширений, включая coc-phpstan.
Кроме того, можно создать несколько конфигураций разные задачи, и в тоже время иметь под рукой легковесный редактор для правки всякой мелочевки.
А вот потом уже можно сравнить фичи, скорость, потребление памяти, и обнаружить, что уже не все так однозначно.Dreamka Автор
02.11.2021 18:44-4Для каждой задачи должен быть свой инструмент, а не один универсальный. Можно и вилкай в зубах ковырять, но для этих целей существуют зубочистки. А у вилки другие задачи.
aelaa
02.11.2021 21:22+1Отличная логика. Для редактирования кода - редактор кода, для гита - git, для дебага - дебаггер, для задач - Jira... IDE тут не вилка, а швейцарский нож, и им ковырять в зубах не лучше
Dreamka Автор
02.11.2021 21:53Раз уж Вы заговорили про швейцарский нож, то, как любитель ножей, похвастаюсь своим Victorinox в котором есть зубочистка =)
Нож
karon
03.11.2021 10:45В инструмент входит и окружение
Это и работа с гитом\свн, с базой, встроенный дебагер гораздо удобнее внешнего, не говоря уже о удаленном.
Тут скорее что для плюсов, один инструмент, для пхп другой
Shtucer
02.11.2021 17:43
>что файловый менеджер - он и в Африке файловый менеджер, однако в PhpStorm он уже есть, а для vim снова нужен плагин.
:Sex
:help netrw
SergeiMinaev
02.11.2021 18:16+3В дальнейшем мы будем вынуждены закрывать рабочее окружение каждый раз, когда нам потребуется какой-то плагин, а требоваться они будут неприлично часто.
а для vim снова нужен плагин. И вновь мы тратим драгоценные минуты на установку необходимого функционала.
Такие вещи настраиваются один раз.
Без проблем - в IDE есть встроенный HTTP-клиент и мы можем баловаться с запросами так, как захотим, а что предлагает нам vim-комьюнити? Использовать штатный консольный клиент операционной системы? Но для этого мы вновь вынуждены покинуть рабочее окружение. И пока ведется разработка, мы так и будем скакать из одного окружения в другое.
Не вынуждены мы ничего покидать. Или вы переход в другое окно называете покиданием рабочего окружения? Лично я несколько окошек (vim, repl питона, bash) воспринимаю как целое рабочее окружение.
Если хотите, можете даже vim-плагин поставить в IDE и радоваться. Для чего нужно отказываться от остальных возможностей IDE, мне не понятно.
Я честно пытался использовать vim-плагин в vscode, но он, во-первых, тормозил, а во-вторых поддерживал не всё, что есть в vim-е. Что именно не поддерживал, уже не помню, но я постоянно "спотыкался".
Для этих же целей служат файлы .idea
Не всегда. Мне по кайфу, что при ssh-подключении к сервакам у меня vim выглядит и работает точно так же, как локальная версия.
Просто вместо вменяемого Text User Interface в vim применяется шаманская клавиатурная магия, возникшая стихийно на заре программирования, когда самого понятия «User Interface» еще существовало.
Эта самая шаманская магия vim - не динозавр, но акула.
Aldrog
02.11.2021 18:44Я честно пытался использовать vim-плагин в vscode, но он, во-первых, тормозил, а во-вторых поддерживал не всё, что есть в vim-е. Что именно не поддерживал, уже не помню, но я постоянно "спотыкался".
В JetBrains аналогично, лаги при вводе и почти неработающий undo. Если бы не это, с радостью пользовался бы их продуктами, а так приходится довольствоваться вимом.
Благо, coc даёт и удобную навигацию, и предупреждения на код высвечивает.
Dreamka Автор
02.11.2021 18:51Эта самая шаманская магия vim - не динозавр, но акула.
Vim в целом не очень-то дружелюбен к пользователю - новичку. Ведь не зря столько мемасиков про то что из него можно выйти только с помощью reset-а )))
mickvav
02.11.2021 19:07Ну то есть на vimtutor вас не хватило - жаль.
Dreamka Автор
02.11.2021 19:35Когда я первый раз столкнулся с vim - никто мне про vimtutor не говорил. Чтобы его пройти - надо знать про его существование.
netch80
03.11.2021 13:32Вообще-то, чтобы пользоваться любой программой, надо вначале хоть что-то про неё прочитать — и в первую очередь как из неё выйти.
Да, есть какие-то общие правила типа «раз Windows, то Alt+F4», но они не абсолютны.
Tutor тут как отдельная сущность просто не нужен.
Кстати, vim при старте по умолчанию говорит про ":help".
Так что тут исключительно ваша провина.
saidelman
03.11.2021 14:13+1Кстати, vim при старте по умолчанию говорит про ":help".
Это если просто запустить
vim, без аргументов. Есть люди, которые попадают в vim совершенно не имея таких намерений. Например, ЕМНИП git по умолчанию именно vim открывает для всего, что требует редактирования текста. И тогда вместо дружелюбной стартовой страницы сразу открывается файл, дифф, сообщение коммита или что-то такое. Так что если пользователь не указал системную переменнуюEDITOR=nanoили не настроил сам git использовать иной редактор, то только vim только хардкор.Наверняка немало найдётся людей, которые именно так впервые сталкиваются с vim'ом :)
netch80
03.11.2021 14:21+1> Например, ЕМНИП git по умолчанию именно vim открывает для всего, что требует редактирования текста.
По-моему, таки редактор по умолчанию? Который в большинстве дистрибутивов — ужасный nano. Вот если ничего не выставлено — да, vim (или вообще vi).
Ну тут я согласен, что в Unix можно в vi и случайно попасть.
Если автор статьи столкнулся с такой ситуацией… да, соболезную. У меня было в первый раз так же — попал случайно и вышел только закрыв окно telnet :) но потом пошёл искать доку. Но я от этого не говорю, что редактор безусловно плохой — проблема в окружении.saidelman
03.11.2021 15:43Я когда-то тоже угодил в такую же ловушку :) То есть был в каком-то дистрибутиве, где дефолтным был vi/vim. Не знаю, где какой дефолт сейчас.
Помню, что какая-то утилита однажды дала мне сообщение в духе "У вас не установлено значение переменной
EDITOR, мы обнаружили следующий список установленных редакторов: %список%. Выберите, какой из них вы хотите использовать сейчас". Но вообще не помню, что это было такое.
Dreamka Автор
02.11.2021 19:01Не вынуждены мы ничего покидать. Или вы переход в другое окно называете покиданием рабочего окружения? Лично я несколько окошек (vim, repl питона, bash) воспринимаю как целое рабочее окружение.
Несколько окон и и единое пространство в IDE - разные вещи. До банального - как раскидать разные инструменты в vim по 2 или 3 мониторам?
mickvav
02.11.2021 19:09А почему работу с мониторами нужно перекладывать с операционной системы на редактор? Или вы один файл в двух местах хотите открыть и одно место держать на одном мониторе, а другое-на другом?
Dreamka Автор
02.11.2021 19:31+1Просто чтобы не плодить бесчисленное кол-во открытых окон. Возможно для кого-то это не проблема, но я не люблю перегруженность пространства.
tarekd
02.11.2021 18:37+7В IDE, благодаря умному анализу кода, ничего особенного не предпринимая, мы сразу увидим какие переменные не используются, какие циклы окажутся вечными, какие условия никогда не изменятся, а значит мы увидим большинство проблемных мест, просто открыв файл. Vim же предлагает нам внимательно вникать в каждую строчку и и выискивать все самостоятельно, проявляя весь свой талант разработчика.
Какой-то vim у Вас неправильный
saurterrs
02.11.2021 18:47+5А почему вы сравниваете решение для разработки на PHP, собранное на основе JetBrains IDEA (хоть и поставляемая готовым пакетом) с голым vim?
Вы уж или тоже берите готовую сборку вима, которых достаточное количество, или берите голую IDEADreamka Автор
02.11.2021 18:49-3Вы про IntelliJ-IDEA? Это другая IDE, если не ошибаюсь, для Java. Делать из нее средство разработки на PHP - глупое занятие. Так же как и пичкать vim всеми плагинами, для всех языков.
borisxm
02.11.2021 19:25+2Так же как и пичкать vim всеми плагинами, для всех языков.
В этом и есть ваша проблема в понимании идеологии vim'a: без плагинов, это просто мощный редактор, причем по умолчанию, многие возможности ни на какие хоткеи не повешены. А вот последующая конфигурация и плагины уже позволяют навертеть все что угодно.
Причем совершенно необязательно делать универсальный комбайн в рамках одной конфигурации: можно создавать «рабочие места» под любые задачи. Например, отдельно для C/C++, отдельно для Python, отдельно для PHP/JS/HTML, а по умолчанию иметь простой и удобный редактор с табами.
loltrol
02.11.2021 19:30Искать смысл в использовании vim vs ide это то же что и спорить какой цвет лучше - красный или зелёный. Потому что зелёный лучше, это всем известно.
saurterrs
02.11.2021 19:36+1Если мне не изменяет память, есть Idea. Всё остальное это набор плагинов поверх. Да, они очень глубоко интегрированы и написаны теми же разработчиками, что не отменяет факта.
И это хорошо, это модульность. Модульность == расширяемость.
qrKot
02.11.2021 19:49+1Вы про IntelliJ-IDEA? Это другая IDE, если не ошибаюсь, для Java.
Вы ошибаетесь, это та же самая IDE. Различие - в наборе предустановленных плагинов и дефолтных настройках. IntelliJ IDEA Ultimate отлично работает Goland'ом, WebStorm'ом и Android Studio'ей одновременно, "просто включи плагин"
netch80
02.11.2021 20:01+11На соседнем форуме значительно более предметно (хоть и сквозь заметный флейм) разбирают эту тему. В частности, там рассказывается, что для vim, neovim и прочих есть достаточное количество плагинов, чтобы не поднимать IDE вообще; да, их надо собрать, но и на это есть готовые рецепты.
Автор же данной статьи, похоже, не в курсе, что современный редактор типа vim это тоже комбайн с тысячами вариантов расширенных возможностей через плагины — он воспринимает текстовый редактор как что-то в духе notepad (а в случае vim ещё и постоянно проезжается по непривычному интерфейсу). Выглядит как просто невежество и нежелание хоть как-то изучить предмет критики перед публикацией. Хотелось бы надеяться, что ошибаюсь, но пока причин к такому смягчению не вижу.
MKMatriX
03.11.2021 13:47Рабочие инструменты берем в состоянии "из коробки"
Изначально не правильный подход) Все равно что сравнивать macOs и винду предполагая что вы покупаете для мака собственно мак, а для винды набор комплектующих и диск.
Вим для тех, кому настроек пхпшторма мало. Собственно я так за пару лет полюбить шторм и не смог. Он крайне приятен, у него целая куча всего очень нужного и полезного, и местами сильно удобней чем везде, но увы расширять его крайне сложно. Например хотите вы быстро фильтровать таблицы в базе, а не просто искать их. Или хотите нормальный vim мод, а то ideaVim применим разве что для печати.
Поэтому позвольте чуть-чуть пояснить кто все же выбирает вим. Вим выбирает человек заранее желающий не только настраивать плагины, но и писать их. Просто потому что. Он готов написать свой плагин для создания локальных копий, скачивания базы, или даже добавления удаления пользователей из редактора. У него уже есть куча bash скриптов, и странных привычек в оформлении кода. Т.е. у него уже есть настроенный под него годами вим. Что кстати решает часть проблем. Например как-то на старой работе появилось требование "перед любым ветвлением или циклом должен стоять комментарий", и в шторме никак нельзя без плагина добавить такой тип ошибок. Т.е. есть регулярка, но если не хочется взять джаву и дописать такой плагин, то проверяй руками. Эту регулярку проще встроить в хуки гита, чем в шторм. В общем с любым не стандартным требование шторм не справится.
Я ни в коем случае не ругаю шторм. В нем отличный поиск двойным шифтом, удобно что можно смотреть базу в нем (хоть и посредственно), можно там же работать с запросами (хоть и плохо), и достаточно приятный рефакторинг, но главное в нем есть Goto definition, который даже с intelphence работает так себе.
Из минусов шторма можно отметить то, что он приучает к работе через классы и многословно. Т.е. код получается с слишком большим уклоном в ооп ради ооп. И без шторма его читать становится проблематично.
Aldrog
03.11.2021 14:21Вим выбирает человек заранее желающий не только настраивать плагины, но и писать их. Просто потому что. Он готов написать свой плагин для создания локальных копий, скачивания базы, или даже добавления удаления пользователей из редактора.
Не согласен, я не пишу плагины и не планирую. Использую вим потому что ничего удобнее для редактирования кода не встречал, а для других задач меня полностью устраивает иметь отдельные программы: отдельное окно с редактором, отдельное с отладчиком, отдельное для запуска скриптов и работы с гитом.
У него уже есть куча bash скриптов
Вот это — да, у меня тоже есть.
и странных привычек в оформлении кода
Нестандартные правила оформления не люблю, ограничиваюсь стандартными для своего стека clang-format + clang-tidy.
MKMatriX
03.11.2021 15:50Не согласен, я не пишу плагины и не планирую.
Очень многое теряете) Хотя можно называть плагинами кастомные сниппеты или настройки клавиатуры. Я например в саблайме настроил так, что выделив true/false и нажав "!" я получу false/true соответственно. Ну а плагин писал для создания системы файлов папок для компонентов. Ну и быстрой навигации по фреймворку.Aldrog
03.11.2021 17:11Ну а плагин писал для создания системы файлов папок для компонентов.
Я обычно bash-скрипты для подобных целей пишу, и вызываю в отдельном окне терминала. Не очень понимаю, что мне даст возможность вызывать их по бинду из редактора.
Ну и быстрой навигации по фреймворку.
Вот это могу понять, но всерьёз изучать ради этого vimscript / Lua + Neovim API не готов.
MKMatriX
03.11.2021 17:27Я обычно bash-скрипты для подобных целей пишу, и вызываю в отдельном окне терминала. Не очень понимаю, что мне даст возможность вызывать их по бинду из редактора.
В целом да, особо преобразовывать баш скрипты можно только если выделенный код уже содержит инфу полезную для создания файлов. В моем случае это названия папок.
Вот это могу понять, но всерьёз изучать ради этого vimscript / Lua + Neovim API не готов.
Тоже верно, но lua это почти js, и я его заодно знаю из плагинов к wow. Плагин я опять таки писал к саблайму, для чего узнал заодно пайтон, и честно говоря апи нужно внимательно изучать, только для каких-то оптимизаций. В противном случае можно просто знать положение курсора, а дальше обойтись уже внешними средствами. А для быстрой навигации вообще fzf подойдет)
0xd34df00d
03.11.2021 23:04+3Вот это могу понять, но всерьёз изучать ради этого vimscript / Lua + Neovim API не готов.
К счастью, под neovim можно писать и на других языках. Я потихоньку пишу плагин на хаскеле для поддержки ещё одного языка, например.
Jack_Rabbit
03.11.2021 14:18Какое-то странное сравнение IDE и текстового редактора. Самое важное отличие между ними - это глубина анализа. IDE формирует индекс проекта, вычисляет зависимости, типы, и делает кучу других вещей, чтобы лучше "понять" структуру кода. Во многом именно это и определяет преимущества и недостатки.
Да, действительно, многие современные редакторы вроде Vim или VS Code могут достаточно неплохо анализировать код в открытом файле или папке и выполнять простые инспекции вроде проверки используется ли переменная или нет.
В случае с IDE вроде PHPStorm количество инспекций гораздо больше и они более сложные.
Самые простые примеры - это всегда истинные или ложные условия или обращение к несуществующему, закрытому или устаревшему (deprecated) свойству или методу объекта, проверки типов, исключений, и т.д. Более сложные примеры - это анализ граничных условий. Грубо говоря, если переменная инициализируется в условии, а потом она используется вне условия, то IDE покажет ошибку.
Именно это позволяет отлавливать огромное количество скрытых и неявных ошибок на ранней стадии и сэкономить кучу времени.
Второй важный плюс IDE - это быстрый поиск и рефакторинг. На больших проектах это очень важно.
Ну и о более точном контекстном автодополнении тоже забывать не стоит.
Aldrog
03.11.2021 14:28То, что вы описали, сейчас модно выносить в отдельный language-server, и JetBrain'овский CLion с точки зрения индексирования и анализа кода работает точно также, как Neovim с плагином coc.
Jack_Rabbit
03.11.2021 16:04-1LSP - это совсем иная история. Можно подумать, что все упирается в автодополнение.
Основное преимущество IDE перед обычными редакторами - это в первую очередь инструменты рефакторинга и анализа кода. Более "умное" автодополнение здесь - это скорее приятный бонус.
Естественно, эти все плюшки не бесплатны. IDE нужно больше ресурсов на составление индекса, дерева зависимостей, карты типов, и кучи прочих вещей.
Нужно также понимать, что IDE нужны не всем и не всегда.
netch80
03.11.2021 16:13+2> Основное преимущество IDE перед обычными редакторами — это в первую очередь инструменты рефакторинга и анализа кода. Более «умное» автодополнение здесь — это скорее приятный бонус.
Их тоже выносят в LSP.
RomeoGolf
03.11.2021 17:10+4… плевал в него, недовольно бормоча про то, что...
Когда человек плюется и кидает банновые шкурки в молчащего меня, заявляя, что это я плююсь и кидаю банановые шкурки в него — это вызывает недоумение на грани негодования.
Когда человек самостоятельно придумывает мифы, а потом доблестно, успешно, безжалостно и сокрушительно разносит их в клочья — это вызывает усмешку и заставляет вспомнить слово «демагогия».
По поводу заголовка статьи и несуществующего в моей реальности противопоставления я уже писал тут, кому лениво идти по ссылке, можно глянуть подспойлерВбрасыватели «VIM vs IDE» — угомонитесь, пожалуйста. Нет никакого «vs». Никто не заставляет никого вылезать из уютной IntellijIDEA, нырять в темный страшный vim и собирать в нем ынтырпрайз-проекты на яве. Есть дохренищщщща задач для нормального текстового редактора вне IDE и помимо конфигов. Вот просто навскидку, первое, что в голову приходит:
— тексты с не-WYSIWYG разметкой: LaTeX, markdown и подобное. Особенно если это надо лишь время от времени, а не 40 часов в неделю
— старые языки, например asm PDP-11. Представьте себе, он еще не помер, и процессор серийно выпускается.
— новые языки, например, ассемблер NM6403-6407.
— Чужие языки, например, надо чей-то код внезапно однажды на питоне посмотреть и поправить, хотя по работе питон не нужен от слова абсолютно.
— огромные по размеру таблицы данных в виде plain text, которые завесят наглухо практически любой другой редактор. Причем, с прекрасной возможностью поиска по этим данным путем регулярок, а также выборки нужной пачки этих данных.
— сложные и регулярные манипуляции с текстом, например, периодически необходимое преобразование опять же данных, полученных в текстовом виде (результаты записи контрольных приборов, полученных от сторонней организации, повлиять на формат записи нельзя), с выборкой и заменой части этих данных по какому-то (не буду слишком подробно) правилу, тут скрипты vim влегкую уделывают любые макросы. Причем, макросы там тоже есть.
— необходимость работать с зоопарком кодировок с перебросом текста на кириллице из одних кодировок в другую — vim удивительно всеяден и позволяет делать это настолько легко, что не надо совсем задумываться над процессом и последовательностью операций.
Некоторые из этих вопросов решаются настройкой любимой IDE под использование постороннего компилятора, но это потратить изрядно времени на такую настройку, потом, однозначного соответствия, скажем, сишным операциям в питоне или асме не будет, все равно боль, а в vim привычно, быстро и легко.
Некоторые вопросы решаются другими средствами. Но зачем? Если есть инструмент, который перекрывает этот спектр с запасом (я еще не все вспомнил, за что люблю vim).
Это кое-что из того, что в моей повседневной работе встречается более-менее регулярно. И VIM здесь великолепен портясающей настраиваемостью, подсветкой синтаксиса под все, что надо (и очень легко добавить еще), скриптуемостью, всеядностью по кодировкам, форматам конца строки и размерам, кучей возможностей редактирования, поиска и замены из коробки, переносимостью между кучей ОС (забрал свой vimrc — и на чужой машине ты как дома), встраиваемостью сторонних утилит в процесс редактирования и поиска (типа ctags из простого), и, черт побери, ругаемой всеми модальностью, которая поначалу кажется чем-то диким, а потом не понимаешь, как без нее другие обходятся. Многое из этого (и еще много чего не перечисленного) есть и в других редакторах, но все это есть в одном месте. Наверное, emaсs не хуже. Говорят, в принципе, такой же, я не пробовал. Но nano, mcedit и тому подобное… Конфиги править — может быть.
Да, для шарпа я буду пользоваться студией, для явы — идеей, благо теперь есть и бесплатные версии, возможностей которых для меня хватает. Но IDE для LaTeX? Для PDP-11? Или вспоминать, как работает iconv (передаваемы параметры и все такое), и где-то добывать ее под винду, когда интернета на рабочей машине нет, и вообще он далеко?
Я не знаю, кто хуже — веган, который всех остальных при каждом удобном случае брезгливо честит трупоедами, или любитель шашлыка, пытающийся перепрошить вегана. Не надо так.
Притчу ответную тоже написал, иллюстрирующую обратную точку зрения (это не мешки ворочать), но очень уж длинно получилось, так что стер.
P.S. Для песочницы выбирать настолько холиварную тему — это, как сейчас принято говорить, такое себе… Чес-слово, светодиодик на ардуинке смотрелся бы лучше.Dreamka Автор
03.11.2021 18:27P.S. Для песочницы выбирать настолько холиварную тему — это, как сейчас принято говорить, такое себе… Чес-слово, светодиодик на ардуинке смотрелся бы лучше.
Ну если и открывать какие-то двери, то с ноги =) Я много лет просто читал хабр, и побаивался что-то писать. Думал что мое мнение никому не интересно, что на хабре пишут только настоящие крутые дядьки, которые уж точно гораздо компетентнее меня, но тема зацепила и появилась мысль о том что в целом-то я ничего не теряю. Ну заминусят - так просто останусь вечным читателем. А если будет хотя бы небольшой положительный отклик - можно будет подумать о том, чтобы написать что-то еще.
А со светодиодиками на ардуинке я не умею, хотя все время вспоминаю о том, что стоило бы выделить на это время.
Xeldos
03.11.2021 22:16> огромные по размеру таблицы данных в виде plain text
Вот тут кстати да. Не отнять. Открыть на винде гигабайтный лог и ещё и работать в нём — никаких проблем, волшебное совершенно чувство.
le2
04.11.2021 18:08+1недавно я зашёл по ssh на леговский компьютер ev3. 300 МГц и 64МБ ОЗУ.
Закинул два файла .tmux и .vimrc и я уже там как дома. Правда плагины vim'овские пришлось снести так как какой-то из них тормозил.
То есть я мог комфортно изменять файлы и даже компилировать в привычной среде.
Vim хорош, когда нужно открывать проект на нескольких языках программирования и сверх больших. Из 20+ библиотек раскиданных по разным местам на диске. Через ctags сделать общую навигацию до желаемого уровня, вплоть до сишных функций компилятора. Везде будет подсветка синтаксиса и привычные тебе настройки.
Есть отдельная боль как портирование библиотек. Иногда это занимает недели. Там не нужно писать, а нужна быстрая навигация, чтение и точечное исправление.
Vim хорош когда требуется удаленная работа, работа на системном уровне, чтение конфигов и прочего.
Морально-психологическая радость в том что vim принадлежит тебе и ты управляешь изменениями, когда IDE может радикально измениться по воле одной из корпораций. Нет выученной беспомощности.
Для тех кто использует один язык программирования и узкую сферу деятельности, преимуществ никаких с VIMом не будет.
kubrack
05.11.2021 15:25+2О полноценной разработке, мой случай.
Работал в vim (потом neovim) с Clojure.
Доп плагинов всего два:
LSP (+ clojure_lsp сервер) - линтер, статанализ, дополнение. Строго говоря, в nvim это уже не плагин, но упоминаю так как в одной строчке конфигурации и доустановке сервера нуждается.
fireplace - интеграция с REPL, контекстный хелп, eval, display source, stacktrace.
Решил перейти на IntelliJ Idea, так как не хватало полноценного go-to-definition. То есть gd в пределах файта работает и в голом виме, и [d из fireplace хорошо находит и показывает реализацию, gf открывает файл по ns, но хотелось чтоб открыть файл с реализацией и прыгнуть на нее ([d показывает ее просто внизу, файл не открывает). Да и просто если честно все вокруг в идее, хотелось глянуть что такое полноценное IDE.
В идее скачал Clojure плагин который в поиске топ-1 с большим отрывом. Он платный, но я рассудил что наверное самый продвинутый. Подключился замечательно к обоим своим REPL.
На этом проекте есть особенность - REPL у меня как правило открыто два:
один локальный, в тестовом env. Здесь можно запускать тесты, но нет реальных данных.
второй запущен на сервере и проброшен через ssh. Здесь реальные данные, но нельзя запускать тесты.
Получается такой воркфлоу: работаю с реальными данными, сохраняя файл удаленно и синкая с удаленным реплом, а когда нужно запустить тест - сохраняю и синкаю соответственно с локальным. В виме это реализовано двумя макросами, каждый 2 нажатия:
autocmd BufNewFile,BufRead *.clj,*.edn :let @r = ":w\n:Connect 55555 .\ncpr"autocmd BufNewFile,BufRead *.clj,*.edn :let @s = ":w\n:silent !scp % research:/home/me/repos/%\n:redraw!\n:Connect 44444 .\ncpr"Где 55555 и 44444 - порты соотв. локального и удаленного реплов, cpr - REPL reload. То есть нажимая две кнопки, я сохраняю куда нужно и синхронизирую. @ и r - все это локально, @ и s - удаленно. Или дабл @ для повтора последнего варианта.
Где осталась последняя версия файла - легко увидеть гитом, ну и @s @r сделать перед закрытием не сложно, чтоб сбросить туда и туда. Секундной задержки и вывода scp в строке статуса при @s достаточно, чтобы не перепутать.
Понятно что это все как правило не для одного и не для двух файлов, буферов открыто много, благо в неовиме навигация по ним уже наглядная с дополнением списками.
Вот эту фичу я не смог реализовать в идее. То есть можно открыть проект по scp, или примонтировать локально (уже не айс), но это будет отдельный проект. Я не смогу, работая над одним файлом, запускать его то тут то там, не персохраняя его явно с кучей кликов мышей.
По поводу остальных преимуществ: go-to-definition в проекте в идее так и не получил, только локальный. Может быть плохо искал.
Анализатор в идее откровенно тупее чем clojure_lsp (не недостаток т к наверное это того плагина анализатор и можно было подключиться к тому же LSP что и вим).
Дебагер кложе не нужен) Все остальное есть в виме в той конфигурации что я описал.
Вернулся в вим.
kubrack
05.11.2021 15:31UPD: только что полез еще раз в документацию к clojure_lsp и сконфигурировал в виме полноценный go-to-definition, с открытием исходника даже из jar. Извиняюсь что сперва ввел в заблуждение. я недавний пользователь lsp. Получается хотя бы мне статья пользу принесла, спасибо)
kalbas
Vim должен быть против Emacs, вот это была бы топ-статья.
Tiendil
Топовая, но бессмысленная :-)
artem_larin
Т.е. у вас есть ответ на вопрос что же лучше - Вим или Емакс? Тогда поделитесь! А то я например и тот и другой использую, и всё не могу определиться. Ощущаю прям раздвоение личности.
Fell-x27
Да.
netch80
Тут будет порция субъективности, но я с emacs не подружился из-за многочисленных M-x C-c C-v M-x длинная-многословная-команда — просто задолбало их набирать, когда можно в разы короче под любой альтернативой :) Ну и набор «меты» через всякие alt, которые работают не в каждом терминале, без «исконной» обстановки emacs (локальный терминал плюс Space Cadet Keyboard) это регулярное приключение.
А после того, как я узнал, что у Столлмана давний RSI, который плохо совместим с подобными тяжёлыми комбинациями и длинными последовательностями… уже не знаю, что и думать. Я, скорее всего, RSI не подвержен, но со стороны всё это попахивает странным мазохизмом…
Tiendil
То есть ни у кого не будет объективного ответа, потому что у них очень разные культуры использования.
Соответственно, такая статья может привести только к холивару.
Следовательно, она будет топовой из-за срача, но малополезной.