> Я сомневаюсь, что без построения AST можно корректно выполнить рефакторинг кода.
Корректно, наверное, нет, точнее может получится, что не всегда. С другой стороны и с IDE я никогда в жизни не выполню рефакторинг, не проверим потом код при помощи git diff. У меня нет 100% доверия к тулам, что они сделают все правильно. То есть перед тем, как я отправлю код в репозиторий — я точно буду глазами все просматривать.
> которые выполняют рефакторинг вроде rename method или rename variable?
Я вам привел ссылку выше на плагины для php vimawesome.com/?q=php%20cat%3Alanguage (может быть лучше или больше, я не знаю, я php не знаю). Там есть, например, какой-то php-refactoring.
С другой стороны, например, у меня есть плагин python-mode, который строит AST и может выполнить много разного рефакторинга, но я им не пользуюсь, просто не вижу смысла. Хватает vim команд и макросов с головой.
Мне казалось, что мы уже ответили на большую часть вопросов.
> Я пытаюсь доказать свою позицию о том, что в некоторых случаях возможности IDE превосходят возможности vim.
Все так. Согласен. А в некоторых Vim превосходят IDE. Даже IDE иногда превосходят друг друга.
> Вы фактически ответили, что все то, что за меня делает IDE, вы делаете руками. И вы называете это более эффективной работой и осознанным выбором.
Именно. Не одним только рефакторингом мы занимаемся на работе. И как я уже сказал выше «Тут я замечу, что в совокупности vim+zsh+tmux+command line tools дают мне это удобство. Не только vim. Может быть, без дополнительных тулов мне vim был бы не интересен.»
> Я согласен, что vim имеет свои преимущества. Однако, уж точно не при сложном рефакторинге кода.
Да, согласен.
> Для того, чтобы переименовать namespace, мне в PHPStorm достаточно нажать Shift-F6 и ввести новое имя.
Я PHP не знаю, но по контексту: если взять Vim из коробки, то нужно будет делать все руками при помощи command line tools и Vim. Advanced Vim пользователь точно не будет это делать по одному файлу. Если эта операция будет частая, то можно даже написать Vim plugin (может быть уже есть? vimawesome.com/?q=php%20cat%3Alanguage), который пользуясь «find, sed, xargs, grep» выполнит то, о чем вы говорите. Если нет, то разово используя те же тулы выполнит это. Замечу, что это будет еще и приобретенным опытом, который в будущем позволит выполнять похожие операция в других языках или просто каких-нибудь файлах-данных.
Если вы хотите вести объективный диалог, то давайте сначала определимся с целями. Доказать, что IDE лучше Vim или наоборот? Не получится, да и не охото. Поговорить о том, почему люди выбирают одно или другое — наверное, можно. Давайте поставим вопрос точнее.
У нас просто диалог получается из разряда — вы мне пытаетесь навязать IDE, а я просто говорю, что люди, использующие текстовые редакторы делают выбор осознанно. Бесспорно вы можете найти 1000 случаев, где IDE будет лучше любого текстового редактора.
> Действительно ли у вас объективно уходит столько же времени в vim, сколько у меня в IDE на один и тот же более-менее сложный рефакторинг?
Я никогда лично не замерял, сколько времени у меня выходит выполнить какой-то рефакторинг в Vim, а сколько в чем-то другом. Более того, я лично не знаю сколько времени у вас на это уходит. Поэтому я на этот вопрос ответить не могу.
Сейчас скажу, что эффективность и удобство у меня на том же уровне, по ощущениям, как было с Visual Studio и ReSharper. Я так же полезен компании, в которой я работаю. Они довольны моей работой, а я доволен компанией, в которой работаю.
> Что для вас «эффективность и удобство»?
— Под эффективностью я понимаю: помощь моих тулов в решении поставленных задач в срок, который будет удовлетворять меня и моего работодателя.
— Под удобством я понимаю: использование приобретенных знаний в решении поставленных задач. Тут я замечу, что в совокупности vim+zsh+tmux+command line tools дают мне это удобство. Не только vim. Может быть, без дополнительных тулов мне vim был бы не интересен.
> Ох, как же любят люди выдавать свою закостенелость за «мне так удобней». Нет, привычней, но не удобней, не быстрее и не точнее.
А по мне так вы просто слепо судите о том, о чем понятие не имеете. Я 8 лет работал в Visual Studio & ReSharper. Около 2х последних в Vim. Лично мне кажется, что я могу сравнивать, а вы нет. У вас знаний Vim не достаточно, чтобы сравнивать оба способа разработки.
> IDE предоставляет более широкий их набор, чем простой текстовый редактор с подсветкой синтаксиса.
Это ВАШ список того, за что вы выбрали IDE. Я безумно за вас рад. Мне то что с него? Более того, больше половины, если прям так хочется, можно подкрутить и в текстовых редакторах.
Я с вами полностью согласен, у IDE есть свои прелести над текстовыми редакторами. Я работал около 8 лет в IDE, а именно Visual Studio + ReSharper. Без последнего причем был как без рук. Не понимал, как вообще в редакторе можно что-то писать. Последние два года работаю 99% времени в Vim. Я не говорю, что Vim лучше, у него есть свои прелести, за которые я его выбрал на данном этапе, и почему я с него не слезу. Но, отвечая на ваш вопрос.
> Что эффективнее и удобнее использовать программисту в данном случае — vim или IDE?
Мне эффективнее и удобнее использовать Vim. Вам, как я понял, IDE.
> IDE сделает это быстрее и удобнее
Вы правильно понимаете, для вас IDE сделает все быстрее и удобнее.
Если немного капнуть в этом вопросе: программисты в основном работают за время. То есть время — это главный показатель того, как программист эффективен. Если за N времени один программист может сделать то же самое в IDE, как другой в Vim — это значит, что они одинаково эффективны.
Лично я клавиши нажимаю намного быстрее, чем кликаю мышкой. Поэтому лично для меня удобнее и быстрее будет Vim.
Давайте перенесем контекст немного. На автомобили и автобусы. Как проще добраться с дома до работы?
Особенности автомобиля:
— Нужно знать как водить автомобиль.
— Сломается — нужно чинить самому.
— Есть проблемы с трафиком — нужно изучать самые короткие маршруты самому.
— Если переехать в другую точку или найти другую работу — достаточно легко подобрать новый маршрут.
Особенности автобуса:
— Необходимо ждать автобуса.
— Если автобус не приедет, то придется идти пешком.
— С трафиком проблем нет, с поломками проблем нет (другой придет), заботиться ни о чем не нужно.
— Если переехать в другую точку или найти другую работу — немного более проблематичнее подбирать новый маршрут, особенно если есть пересадки, нужно попробовать и посмотреть что будет быстрее.
Есть еще куча всяких персональных особенностей каждого: на автомобиле еще можно будет и в магазин заскакивать, а вот на автобусе во время движения можно читать. В общем, кого не спроси — у каждого будет свой набор пунктов, почему он выбирает именно этот вариант. Более того, иногда мы знаем уже, что на автобусе будет быстрее добираться о одном из случаев, но выбираем автомобиль, потому что нам так приятнее и удобнее. А иногда на автомобиле будет в 2 раза быстрее, но вот получить права на вождение, а так же купить автомобиль, решить где его парковать и т.п. Мы так же будем давать советы своим знакомым, что на автомобиле/автобусе будет быстрее, но слушать нас никто не будет, потому что у каждого свое мнение, и каждому удобно разное.
Все так, я с вами соглашусь, лично для вас удобство не сравнимо, лично для вас трудозатраты будут другие.
Я лично не вижу проблем выполнить pull/push member рефакторинг в vim.
Рефакторить в разрезе файла или нескольких файлов — Vim так же вам позволит очень быстро выносить методы, переименовывать переменные и т.п. стандартными средствами редактора.
Если мы говорим о часто упоминаемом примере: переименовать название метода в огромном проекте. Да IDE с этим справится лучше, да с Vim нужно будет тупо grep-ать и sed-ить, а потом проверять при помощи компилятора, что ничего не сломалось. Но! Основаная проблема такого переименования как раз в не в том, чтобы код просто скомпилировался. Если проект действительно большой, то нужно решить еще две проблемы. Первое — это мета данные, всякие упоминания этого метода в help/json и т.п., с чем to IDE тоже поможет, но вручную проверить стоит. Проблема номер два — обозленные сотрудники, которым придется мерджить конфликты, подстраиваться под ваш рефакторинг. Если команда и проект действительно большие — вам этот рефакторинг еще пару месяцев будет вспоминаться. Лучшим способом отрефакторить такое — на уровне API построить новый метод и назвать другой obsolete, в этом случае IDE и vim отработают одинаково.
Поговорил вчера с одним из разработчиков OneDrive. Он намекнул мне, что одна из главных причин произошедшего не в том, что кто-то использует по 75Tb, а в том, что ботами создают много бесплатных аккаунтов и используя 15Gb бесплатно — создают себе типа RAID массивы. Думаю этим вызвано то, что с 15Gb перешли на 5Gb. Не понимаю, конечно, как их это спасет. Ну будут создавать в 3 раза больше бесплатных аккаунтов.
Да, нужно делать резервные копии с одного компьютера регулярно то, что синхронизируешь. В моем случае я использую Dropbox + iCloud для синхронизации документов, делаю их резервные копии с историей при помощи TimeMachine, а так же при помощи Arq Backup (тоже для OSX) делаю с них резервные зашифрованные копии в Amazon Cloud Drive (который Unlimited). В общем, раз настроил — больше нету вопроса никакой лени.
Тут встает вопрос, а где хостить? Дома? А если все сгорит, тогда потеряете все. Чем хороши облака: либо облако сгорит, либо дом. А вот если и то и то, то скорее всего апокалипсис, вам будет не до фоточек.
Корректно, наверное, нет, точнее может получится, что не всегда. С другой стороны и с IDE я никогда в жизни не выполню рефакторинг, не проверим потом код при помощи git diff. У меня нет 100% доверия к тулам, что они сделают все правильно. То есть перед тем, как я отправлю код в репозиторий — я точно буду глазами все просматривать.
> которые выполняют рефакторинг вроде rename method или rename variable?
Я вам привел ссылку выше на плагины для php vimawesome.com/?q=php%20cat%3Alanguage (может быть лучше или больше, я не знаю, я php не знаю). Там есть, например, какой-то php-refactoring.
С другой стороны, например, у меня есть плагин python-mode, который строит AST и может выполнить много разного рефакторинга, но я им не пользуюсь, просто не вижу смысла. Хватает vim команд и макросов с головой.
> Я пытаюсь доказать свою позицию о том, что в некоторых случаях возможности IDE превосходят возможности vim.
Все так. Согласен. А в некоторых Vim превосходят IDE. Даже IDE иногда превосходят друг друга.
> Вы фактически ответили, что все то, что за меня делает IDE, вы делаете руками. И вы называете это более эффективной работой и осознанным выбором.
Именно. Не одним только рефакторингом мы занимаемся на работе. И как я уже сказал выше «Тут я замечу, что в совокупности vim+zsh+tmux+command line tools дают мне это удобство. Не только vim. Может быть, без дополнительных тулов мне vim был бы не интересен.»
> Я согласен, что vim имеет свои преимущества. Однако, уж точно не при сложном рефакторинге кода.
Да, согласен.
> Для того, чтобы переименовать namespace, мне в PHPStorm достаточно нажать Shift-F6 и ввести новое имя.
Я PHP не знаю, но по контексту: если взять Vim из коробки, то нужно будет делать все руками при помощи command line tools и Vim. Advanced Vim пользователь точно не будет это делать по одному файлу. Если эта операция будет частая, то можно даже написать Vim plugin (может быть уже есть? vimawesome.com/?q=php%20cat%3Alanguage), который пользуясь «find, sed, xargs, grep» выполнит то, о чем вы говорите. Если нет, то разово используя те же тулы выполнит это. Замечу, что это будет еще и приобретенным опытом, который в будущем позволит выполнять похожие операция в других языках или просто каких-нибудь файлах-данных.
У нас просто диалог получается из разряда — вы мне пытаетесь навязать IDE, а я просто говорю, что люди, использующие текстовые редакторы делают выбор осознанно. Бесспорно вы можете найти 1000 случаев, где IDE будет лучше любого текстового редактора.
Я никогда лично не замерял, сколько времени у меня выходит выполнить какой-то рефакторинг в Vim, а сколько в чем-то другом. Более того, я лично не знаю сколько времени у вас на это уходит. Поэтому я на этот вопрос ответить не могу.
Сейчас скажу, что эффективность и удобство у меня на том же уровне, по ощущениям, как было с Visual Studio и ReSharper. Я так же полезен компании, в которой я работаю. Они довольны моей работой, а я доволен компанией, в которой работаю.
> Что для вас «эффективность и удобство»?
— Под эффективностью я понимаю: помощь моих тулов в решении поставленных задач в срок, который будет удовлетворять меня и моего работодателя.
— Под удобством я понимаю: использование приобретенных знаний в решении поставленных задач. Тут я замечу, что в совокупности vim+zsh+tmux+command line tools дают мне это удобство. Не только vim. Может быть, без дополнительных тулов мне vim был бы не интересен.
Вы меня не убедили.
> то было бы не плохо услышать от вас причины, которые вынудили вас дауншифтнуться до текстового редактора
Мне кажется, если бы первое было бы правдой, то этого вопроса бы не было.
> Что-нибудь отличное от…
Откуда вы взяли эти цитаты? Я такого не говорил.
А по мне так вы просто слепо судите о том, о чем понятие не имеете. Я 8 лет работал в Visual Studio & ReSharper. Около 2х последних в Vim. Лично мне кажется, что я могу сравнивать, а вы нет. У вас знаний Vim не достаточно, чтобы сравнивать оба способа разработки.
> IDE предоставляет более широкий их набор, чем простой текстовый редактор с подсветкой синтаксиса.
Это ВАШ список того, за что вы выбрали IDE. Я безумно за вас рад. Мне то что с него? Более того, больше половины, если прям так хочется, можно подкрутить и в текстовых редакторах.
> Что эффективнее и удобнее использовать программисту в данном случае — vim или IDE?
Мне эффективнее и удобнее использовать Vim. Вам, как я понял, IDE.
Вы правильно понимаете, для вас IDE сделает все быстрее и удобнее.
Если немного капнуть в этом вопросе: программисты в основном работают за время. То есть время — это главный показатель того, как программист эффективен. Если за N времени один программист может сделать то же самое в IDE, как другой в Vim — это значит, что они одинаково эффективны.
Лично я клавиши нажимаю намного быстрее, чем кликаю мышкой. Поэтому лично для меня удобнее и быстрее будет Vim.
Давайте перенесем контекст немного. На автомобили и автобусы. Как проще добраться с дома до работы?
Особенности автомобиля:
— Нужно знать как водить автомобиль.
— Сломается — нужно чинить самому.
— Есть проблемы с трафиком — нужно изучать самые короткие маршруты самому.
— Если переехать в другую точку или найти другую работу — достаточно легко подобрать новый маршрут.
Особенности автобуса:
— Необходимо ждать автобуса.
— Если автобус не приедет, то придется идти пешком.
— С трафиком проблем нет, с поломками проблем нет (другой придет), заботиться ни о чем не нужно.
— Если переехать в другую точку или найти другую работу — немного более проблематичнее подбирать новый маршрут, особенно если есть пересадки, нужно попробовать и посмотреть что будет быстрее.
Есть еще куча всяких персональных особенностей каждого: на автомобиле еще можно будет и в магазин заскакивать, а вот на автобусе во время движения можно читать. В общем, кого не спроси — у каждого будет свой набор пунктов, почему он выбирает именно этот вариант. Более того, иногда мы знаем уже, что на автобусе будет быстрее добираться о одном из случаев, но выбираем автомобиль, потому что нам так приятнее и удобнее. А иногда на автомобиле будет в 2 раза быстрее, но вот получить права на вождение, а так же купить автомобиль, решить где его парковать и т.п. Мы так же будем давать советы своим знакомым, что на автомобиле/автобусе будет быстрее, но слушать нас никто не будет, потому что у каждого свое мнение, и каждому удобно разное.
Я лично не вижу проблем выполнить pull/push member рефакторинг в vim.
Тогда это попадает под определение «Рефакторить в разрезе файла или нескольких файлов».
Если мы говорим о часто упоминаемом примере: переименовать название метода в огромном проекте. Да IDE с этим справится лучше, да с Vim нужно будет тупо grep-ать и sed-ить, а потом проверять при помощи компилятора, что ничего не сломалось. Но! Основаная проблема такого переименования как раз в не в том, чтобы код просто скомпилировался. Если проект действительно большой, то нужно решить еще две проблемы. Первое — это мета данные, всякие упоминания этого метода в help/json и т.п., с чем to IDE тоже поможет, но вручную проверить стоит. Проблема номер два — обозленные сотрудники, которым придется мерджить конфликты, подстраиваться под ваш рефакторинг. Если команда и проект действительно большие — вам этот рефакторинг еще пару месяцев будет вспоминаться. Лучшим способом отрефакторить такое — на уровне API построить новый метод и назвать другой obsolete, в этом случае IDE и vim отработают одинаково.