Комментарии 129
Говоря более простым языком, программирование — это написание текста.
Нет
Автор написал херни, упоминув что такие темы сводятся к холивару. И написал ещё статью для холивара, не приведя даже толковых аргументов.
Любая модальная ерунда — это повышение когнитивной нагрузки на пустом месте, ибо теперь нужно помнить не только то, какое именно действие выполняется по нажатию каждой клавиши, а еще и в каком режиме мы сейчас находимся, в какой режим мы теперь хотим, и как нам перейти в него. Кратковременной памяти мало и так, и в итоге шутка о том, что VIM, на самом деле, имеет два режима — «бибикать» и «портить всё» — уже не кажется смешной.
Более того, программирование от ввода текста отличается очень сильно, и от интегрированной среды разработки в первую очередь требуется не экономия на перемещении курсора, а интеллектуальный подсказки, итеграция с отладчиком, профилировщиком, анализаторами, системами управления версиями и остальными утилитами, необходимыми разработчику даже больше, чем собственно текстовый редактор. В IDE для разработки UEFI-совместимых прошивок AMI Visual eBIOS, например, есть мастер IRQ routing'а, генератор GUIDов, интерфейс для быстрой настройки PCI/SMBus/IOAPIC-устройств, интерфейс для управления build-токенами и другие вещи, нужные именно для разработки прошивки. Понятно, что все это можно добавить и в VIM или EMACS, только вот почему-то пока никто не собрался…
Более того, программирование от ввода текста отличается очень сильно, и от интегрированной среды разработки в первую очередь требуется не экономия на перемещении курсора, а интеллектуальный подсказки, итеграция с отладчиком, профилировщиком, анализаторами, системами управления версиями и остальными утилитами, необходимыми разработчику даже больше, чем собственно текстовый редактор. В IDE для разработки UEFI-совместимых прошивок AMI Visual eBIOS, например, есть мастер IRQ routing'а, генератор GUIDов, интерфейс для быстрой настройки PCI/SMBus/IOAPIC-устройств, интерфейс для управления build-токенами и другие вещи, нужные именно для разработки прошивки. Понятно, что все это можно добавить и в VIM или EMACS, только вот почему-то пока никто не собрался…
ибо теперь нужно помнить не только то, какое именно действие выполняется по нажатию каждой клавиши, а еще и в каком режиме мы сейчас находимся, в какой режим мы теперь хотим, и как нам перейти в него
Иногда я еще забываю как дышать и сигнализировать сердце для его сокращения. Человеческий организм, самое глупейшее изобретение на земле!
Если у вас вот это перечисленное требует когнитивной нагрузки и выполняется сознанием — не завидую. В противном случае — не понимаю вашего сарказма. Любые режимы в интерфейсах — несомненое зло, и если их можно искоренить — их нужно искоренить.
Если у вас вот это перечисленное требует когнитивной нагрузки и выполняется сознанием — не завидую
Я тоже вам не завидую, если для нажатия клавиши на клавиатуре вашему мышлению требуется переход из подсознательного в сознание.
http://japsix.ru/wp-content/uploads/2015/03/Krivaya-zabyvaniya-Ebbingauza-e1427449657778.jpg
рекомендую.
А механика перехода по режимам в подсознание не уйдет ранее чем через тысячи повторений для каждого отдельного случая.
Т.е. вы тупо тратите годы на это чтобы просто сравняться и немного обогнать в эффективности набора и навигации пользователей IDE.
Про остальное умолчим, поскольку время, потраченное на превращение нечто в IDE вместе с кривой обучения, просто не окупается за время трудовой жизни человека, который начал этим заниматься после 20 лет.
рекомендую.
А механика перехода по режимам в подсознание не уйдет ранее чем через тысячи повторений для каждого отдельного случая.
Т.е. вы тупо тратите годы на это чтобы просто сравняться и немного обогнать в эффективности набора и навигации пользователей IDE.
Про остальное умолчим, поскольку время, потраченное на превращение нечто в IDE вместе с кривой обучения, просто не окупается за время трудовой жизни человека, который начал этим заниматься после 20 лет.
Т.е. вы тупо тратите годы
Прошел vimtutor и одну неделю попрактиковался. Видимо я гений?
Про остальное умолчим, поскольку время, потраченное на превращение нечто в IDE вместе с кривой обучения, просто не окупается за время трудовой жизни человека, который начал этим заниматься после 20 лет
Наверно у вас даже есть статистика на этот счет? Я начал использовать Vim года 3 назад, и сегодня считаю себя продвинутым пользователем этого редактора. Что то в ваших цифрах не стыкуется с истинной. Возможно то, что вы их сами придумали )
Видимо вам просто не дано осознать и провести анализ личной трудоспособности. трудозатрат на обучение. И взвесить два этих фактора максимально оградив от стороннего влияния (как, то общий рост навыков по мере получения опыта в профессии)
Впрочем, дворник тоже будет удивляться — какой прок от компьютера… метлой же удобнее.
У вас есть личные данные о том, сколько же времени вы его использовали, сколько настраивали, и какой результат в производительности труда?
Вот у меня есть мой опыт, по командам с которыми я работал, о том что пользователи vim с задачами уровня выше чем middle справляются так себе, а трудозатраты на поддержку их решений выше.
При том что мелкие и несложные задачи они действительно выполняют быстрее.
Впрочем, дворник тоже будет удивляться — какой прок от компьютера… метлой же удобнее.
У вас есть личные данные о том, сколько же времени вы его использовали, сколько настраивали, и какой результат в производительности труда?
Вот у меня есть мой опыт, по командам с которыми я работал, о том что пользователи vim с задачами уровня выше чем middle справляются так себе, а трудозатраты на поддержку их решений выше.
При том что мелкие и несложные задачи они действительно выполняют быстрее.
Видимо вам просто не дано осознать
Я вам привел две конкретные цифры, как вы их объясните в контексте вашей «статистики»?
У вас есть личные данные о том, сколько же времени вы его использовали, сколько настраивали, и какой результат в производительности труда?
Читайте выше.
Вот у меня есть мой опыт, по командам с которыми я работал, о том что пользователи vim
Вы пользовались Vim (более чем, просто открыть, добавить текст и закрыть)?
1 неделя и 3 года?
С тем же успехом вы могли бы привести частоту ваших посещений туалета за сутки…
То есть на вашу производительность это несомненно как-то влияет… но как — тайна покрытая мраком.
Прямо говоря — ваш результат труда это не процесс использования vim. Соответственно нас не интересует что вы считаете себя продвинутым пользователем.
Нас интересует другое — на проект с оценкой в 8000 человеко-часов вы теперь тратите 6789 часов.
При этом общие затраты на ваше обучение vim составили 7*8 + 3 * 365 * 1 (условно) = 1151 час
Общие трудозатраты 6789 + 1151 = 7940
Теперь осталось из выигрыша в 60 часов за 4 человеко-года вычесть долю полученную за счет общего накопления опыта. И в сухом остатке получить выигрыш от применения vim
Вот если у вас будет эта информация — тогда и поговорим.
А до тех пор… вы мне напоминаете лесоруба с топором
тогда как есть люди, которые работают вот так
https://www.youtube.com/watch?v=ipqC7k-4O5I
И, да, я пользовался и продолжаю временами пользоваться vim
С тем же успехом вы могли бы привести частоту ваших посещений туалета за сутки…
То есть на вашу производительность это несомненно как-то влияет… но как — тайна покрытая мраком.
Прямо говоря — ваш результат труда это не процесс использования vim. Соответственно нас не интересует что вы считаете себя продвинутым пользователем.
Нас интересует другое — на проект с оценкой в 8000 человеко-часов вы теперь тратите 6789 часов.
При этом общие затраты на ваше обучение vim составили 7*8 + 3 * 365 * 1 (условно) = 1151 час
Общие трудозатраты 6789 + 1151 = 7940
Теперь осталось из выигрыша в 60 часов за 4 человеко-года вычесть долю полученную за счет общего накопления опыта. И в сухом остатке получить выигрыш от применения vim
Вот если у вас будет эта информация — тогда и поговорим.
А до тех пор… вы мне напоминаете лесоруба с топором
тогда как есть люди, которые работают вот так
https://www.youtube.com/watch?v=ipqC7k-4O5I
И, да, я пользовался и продолжаю временами пользоваться vim
1 неделя и 3 года?
Да. Вы ведь сказали, что для использования Vim:
Т.е. вы тупо тратите годы на это чтобы просто сравняться и немного обогнать в эффективности набора и навигации пользователей IDE
Про остальное умолчим, поскольку время, потраченное на превращение нечто в IDE вместе с кривой обучения, просто не окупается за время трудовой жизни человека, который начал этим заниматься после 20 лет.
Тобишь несколько лет на изучение Vim до уровня сравнения в эффективности навигации пользователей IDE и вся жизнь на превращение Vim в IDE (чего никто и делать не собирается, откуда такие у вас идеи, я не знаю). Я вам сказал, что мне для комфортного использования потребовалась неделя, а для полноценного перехода с продукции JetBrains на Vim около 3х лет. Это мой личный опыт, а не те цифры, что вы взяли с потолка. Что вы на это ответите?
Соответственно нас не интересует что вы считаете себя продвинутым пользователем
Кого нас?
Прямо говоря — ваш результат труда это не процесс использования vim
Результат это не процесс, я с этим и не спорю, ведь это разные термины.
Нас интересует другое — на проект с оценкой в 8000 человеко-часов вы теперь тратите 6789 часов
Если вы оцениваете проекты человеко-часами, то я должен вас разочаровать — оценить эффективность редактора вам так не удастся. Видите ли, как правило под крупные проекты создаются специальные средства разработки, которые заметно облегчают и ускоряют процесс генерации исходных кодов и их модернизации. В качестве примера можете глянуть в сторону конфигуратора 1C или CUBA Studio. Возможно вы никогда с таким на практике не сталкивались, та как уровень проектов, с которыми вам приходилось работать либо не требовал этого, либо команда использовала предлагаемые вами расчеты и считала, что это слишком ресурсоемко. Как бы то ни было, ваш способ расчитать эффективность использования редактора глуп и безполезен.
Вот если у вас будет эта информация — тогда и поговорим
Нет, я не преследую цель говорить с каждым, кто когда либо слышал о редакторе Vim. Мы с вами поговорим, когда уровень вашей компетенции в области использования модальных и немодальных редакторов, а так же уровень ваших знаний в области конфигурации используемых вами иструментов сравнится с моим и вы мне это продемонстрируете. До тех пор, я не вижу смысла обсуждать эту тему с вами )
«Да. Вы ведь сказали, что для использования Vim:»
То есть 1 неделя и 3 года это не годы? :D У вас шикарная «лохика»
«превращение Vim в IDE (чего никто и делать не собирается, откуда такие у вас идеи, я не знаю)»
Если вы не программируете, а просто набиваете текст, то IDE вам конечно не нужно.
В противном случае вы сами признали, что эффективность работы в специализированых средах выше.
О чем тогда речь? Зачем еще vim?
«Если вы оцениваете проекты человеко-часами, то я должен вас разочаровать — оценить эффективность редактора вам так не удастся.»
Это вам не удастся, поскольку вы Аника-воин.
Вы задекларировали область использования vim как альтернативу тем же продуктам JetBrains. А значит области связаны с разработкой.
Есть метрики качества кода, которые косвенно связаны именно с инструментами. Более качественные инструменты позволяют создавать и поддерживать более сложные проекты.
Любой заметный эффект от инструментов вполне себе формализуем, доступен для анализа и в конечном итоге выливается именно к человеко-часы на разработку с использованием этого инструмента.
Это элементарная вещь и то, что приходится это объяснять вам, наглядно демонстрирует ваш уровень компетенции — «лесоруб»
Другой вопрос что мой уровень компетенции никогда уже не опуститься до вашего. И соответственно продемонстрировать его я бы и готов, но для того чтобы вы могли что-то понять вам нужно подрасти в своем для начала.
Поэтому остается только надеяться и ждать этого момента.
То есть 1 неделя и 3 года это не годы? :D У вас шикарная «лохика»
Похоже вы меня слушать не хотите.
Если вы не программируете, а просто набиваете текст, то IDE вам конечно не нужно
А вы программируете не набивая текст?
О чем тогда речь? Зачем еще vim?
Так незачем, не пользуйтесь. Вас там заставляют? Обратитесь в полицию! Я выступлю свидетелем.
Поэтому остается только надеяться и ждать этого момента
Ну я крайне рад, что ваш порыв «заткнуть за пояс» «недалеких» пользователей редактора Vim удовлетворен и вы можете со спокойной душой похвастаться вашим коллегам об этом )
На будущее, если вы захотите со мной подискуссировать на любую тему, вам нужно предварительно ознакомится с основами диалектики, так как все эти прыжки от одной темы к другой, уходы от ответа и взятая с воздуха статистика пока говорит не в вашу пользу. Это же хабр, а не курилка )
Прошел vimtutor и одну неделю попрактиковался
Я начал использовать Vim года 3 назад, и сегодня считаю себя продвинутым пользователем этого редактора.
1 неделя и 3 года.
Что из этого я не услышал?
А вы программируете не набивая текст?
Бывает и такое. Например, UML знаете?
Программирование это не только code monkey в вашем исполнении.
Так незачем, не пользуйтесь. Вас там заставляют?
Я пользуюсь именно тогда когда нужно.
В отличии от «популяризаторов».
Причина в другом. Нет желания видеть оболваненых, которых потом нужно переучитывать для нормальной работы.
P.S. Ну и желание дискутировать у меня умерло лет 8 назад. Поскольку с умными мы общий язык находим даже при разных вкусовых пристрастиях. А дискуссия ради нее самой или чтобы «моя была сверху» — уже не интересно.
Все остальное это возмущение идиотизмом отдельных личностей.
1 неделя и 3 года.
Что из этого я не услышал?
Читайте очень внимательно:
Т.е. вы тупо тратите годы на это чтобы просто сравняться и немного обогнать в эффективности набора и навигации пользователей IDE.
Прошел vimtutor и одну неделю попрактиковался
Где вы здесь увидели «3 года»?
Бывает и такое. Например, UML знаете?
Программирование это не только code monkey в вашем исполнении.
вы не программируете, а просто набиваете текст, то IDE вам конечно не нужно
То есть хорошая среда для программирования должна включать в себя графический редактор для постоения UML диаграм?
А дискуссия ради нее самой или чтобы «моя была сверху» — уже не интересно
Очень интересно )) Вы берете цифры с потолка, прыгаете с темы на тему, пытаетесь убедить меня в чем то, даже не зная моего отношения к этому вопросу, и при этом говорите, что вас не интересуют дискуссии для «моя была сверху». Мне кажется вы себя обманываете )
Где вы здесь увидели «3 года»?
Прочитал.
И свел вашу информацию в две цитаты.
Вы отказываетесь от собственных слов? Или будете утверждать, что после недели достигли более высокой производительности чем в IntelliJ Idea, PyCharm, PhpStorm?
То есть хорошая среда для программирования должна включать в себя графический редактор для постоения UML диаграм?
Вопрос был не о среде, а о том можно ли программировать не набивая текст.
Вам ответили — можно.
Прочитал.
И свел вашу информацию в две цитаты
То есть вы решили взять мои слова, каким то понятным только вам образом их объединить и выдать за мое утверждение?
Вы отказываетесь от собственных слов? Или будете утверждать, что после недели достигли более высокой производительности чем в IntelliJ Idea, PyCharm, PhpStorm?
Да, неделя и моя производительность в наборе и навигации немного обогнала по эффективности используемый мной ранее PHPStorm.
Вопрос был не о среде, а о том можно ли программировать не набивая текст.
Вам ответили — можно.
Зачем вы опять съезжаете с темы разговора? Мы обсуждаем здесь использование Vim и IDE. Вы считаете, что отсутствие в среде разработки графического редактора, позволяющего строить UML диаграммы делает эту среду разработки плохой? Или вы решили заговорить о разработке ПО вообще вне контекста нашего диалога?
тезис
И ваш вопрос
Априори подразумевает, что вы не знаете о возможностях.
Вам о них рассказали.
Если вы хотели узнать почему для программирования нужно не только набивать текст, то это отдельная тема.
Вы не умеете формулировать свои вопросы?
Именно.
О чем речь и шла, у code monkey возможен рост производительности.
Поскольку вы оцениваете проекты не трудозатратами (в человеко-часах), а в количестве и объеме кода.
Если вы не программируете, а просто набиваете текст, то IDE вам конечно не нужно.
И ваш вопрос
А вы программируете не набивая текст?
Априори подразумевает, что вы не знаете о возможностях.
Вам о них рассказали.
Если вы хотели узнать почему для программирования нужно не только набивать текст, то это отдельная тема.
Вы не умеете формулировать свои вопросы?
Да, неделя и моя производительность в наборе и навигации немного обогнала по эффективности используемый мной ранее PHPStorm.
Именно.
О чем речь и шла, у code monkey возможен рост производительности.
Поскольку вы оцениваете проекты не трудозатратами (в человеко-часах), а в количестве и объеме кода.
Априори подразумевает, что вы не знаете о возможностях
Возможностях чего? IDE? То есть вы утверждаете, что продукция JetBrains позволяет пользователю строить UML схемы без исходных кодов? )
Если вы хотели узнать почему для программирования нужно не только набивать текст, то это отдельная тема
Нет, вы подменяете понятия. Это вы заговорили о связи программирования с разработкой, я лишь хочу понять, как это связано с IDE и Vim? IDE облегчает разработку? Позволяет строить UML схемы?
Вы не умеете формулировать свои вопросы?
Скорее вы не хотите отвечать на мои вопросы )
Поскольку вы оцениваете проекты не трудозатратами (в человеко-часах), а в количестве и объеме кода
Очередное голословное утверждение. Вы не знаете, как я оцениваю проект.
О чем речь и шла, у code monkey возможен рост производительности
Т.е. вы тупо тратите годы на это чтобы просто сравняться и немного обогнать в эффективности набора и навигации пользователей IDE
Опять подмена понятий. Вы четко и ясно сказали, что для небольшого обгона в эффективности набора и навигации пользователя по проекту с помощью IDE пользователю Vim потребуются годы. Мне для этого потребовалась неделя. Вы признаете, что взяли цифры с потолка?
Возможностях чего?
Не набирать текст, но при этом заниматься программированием.
И таки не знаете судя по вашим репликам.
Очередное голословное утверждение. Вы не знаете, как я оцениваю проект.
Мы знаем, что вы их не оцениваете в человеко-часах.
Поскольку вы же сами поспешили меня разочаровать
Если вы оцениваете проекты человеко-часами, то я должен вас разочаровать — оценить эффективность редактора вам так не удастся.
И при этом утверждаете о повышении эффективности работы с кодом.
Поскольку вы не можете сказать, что стали тратить меньше времени.
И не привели никаких других метрик и критериев…
То остаётся лишь размер написанного.
В противном случае все ваши выкрики о том что стало лучше чистой воды балабольство
Мне для этого потребовалась неделя.
Неделю вы потратили на то, чтобы пройти vimtutor и попрактиковаться.
Для того чтобы стать продвинутым пользователем вам потребовалось 3 года.
И, да, вы по прежнему не в состоянии найти в vim все места где используется метод save одной конкретной модели из полусотни других имеющих такой же интерфейс.
То есть ваша самооценка о том, что вы кого-то там обогнали не соответствует действительности.
Не набирать текст, но при этом заниматься программированием
И так вы заговорили о разработке и UML, а затем съехали в абстрактный термин — программирования. Ок, пусть так. Сейчас вы утверждаете, что продукция JetBrains позволяет программировать без набора исходных кодов?
И при этом утверждаете о повышении эффективности работы с кодом
Поскольку вы не можете сказать, что стали тратить меньше времени.
И не привели никаких других метрик и критериев…
Совершенно верно, я руководствуюсь лишь собственными ощущениями, так как прекрасно знаю, что измерить эффективность не удасться. В отличии от вас, я стараюсь себя не обманывать, хоть и использую субъективные оценки.
Для того чтобы стать продвинутым пользователем вам потребовалось 3 года
Опять таки убеждаюсь, что вы меня не слушаете. Я очень ясно сказал:
Я начал использовать Vim года 3 назад, и сегодня считаю себя продвинутым пользователем этого редактора
С чего вы взяли, что я начал считать себя продвинутым пользователем только через 3 года? С чего вы решили, что для небольшого повышения эффективности нужно быть именно продвинутым пользователем Vim? Прекращайте подменять понятия.
И, да, вы по прежнему не в состоянии найти в vim все места где используется метод save одной конкретной модели из полусотни других имеющих такой же интерфейс.
И вот с эффективности мы уже перескакиваем на функциональность. Не углубляясь в детали отвечу — да не можем, так как Vim это не IDE. С другой стороны приходиться работать с крупными проектами и я не испытываю неудобств от этого. А вот чего мне не хватало в продукции JetBrains, так это модуля для генерации исходных кодов согласно особенностям проетка.
То есть ваша самооценка о том, что вы кого-то там обогнали не соответствует действительности
Я использую Vim не для того, чтобы кого то обогнать. Не нужно путать ваши приоритеты с моими.
Совершенно верно, я руководствуюсь лишь собственными ощущениями, так как прекрасно знаю, что измерить эффективность не удасться.
Вот на этой мажорной ноте и стоит закончить диалог.
Более того с неё же можете начинать любую статью о vim.
И статья не сильно пострадает, если эта фраза останется единственным текстом в ней.
В вопросах веры не спорят.
А вы тупо верите, знаний у вас ноль.
Отсюда и невозможность лично для вас оценить эффективность
И вот с эффективности мы уже перескакиваем на функциональность.
Это и есть эффективность.
Вопрос рефакторинга в приложении стоит везде, где объем кода больше нескольких тысяч строк.
И эта мелкая функциональность позволяет его провести быстро и безболезненно.
И эта мелкая функциональность позволяет его провести быстро и безболезненно
Вам стоит попробовать выполнять рефакторинг до того, как вы размазываете неудачное имя по всему проекту.
А как на счет генерации исходников? Это же наиболее частая задача, особенно в больших проектах с четкой структурой. Что на этот счет нам может предоставить IDE?
Я специально для вас поясню.
Рефакторинг это не просто переименование.
И, да, «до того» он просто неактуален.
Шаблоны и кодогегерация имеются и в IDE и отдельно от них.
Попробуйте изучить то, с чем работаете
Рефакторинг это не просто переименование.
И, да, «до того» он просто неактуален.
Шаблоны и кодогегерация имеются и в IDE и отдельно от них.
Попробуйте изучить то, с чем работаете
Рефакторинг это не просто переименование
Ну так и приводите примеры такого рефакторинга, для которого IDE действительно полезен.
И, да, «до того» он просто неактуален
Тобишь о «красная, зеленая, рефакторинг» вы не слышали?
Шаблоны и кодогегерация имеются и в IDE
Приведите пример генерации класса для задачи с отложенным выполнением и регистрацией его в конфиге. Ну или хотя бы пример генераци простого API контроллера для операций CRUD.
Попробуйте изучить то, с чем работаете
Vim настолько многогранен, что я учусь каждый день.
Ну так и приводите примеры такого рефакторинга, для которого IDE действительно полезен.
Легко.
Пример раз:
Есть поле в классе. У него есть явные вызовы (get/set), а есть неявные — например через Spring MVC обращение к полю модели.
В IDE мне достаточно вызвать "переименовать поле" и получить варианты где ещё переименовать, причём с учётом регистра.
Пример два:
Мне надо перенести метод из одного класса в другой. При этом не забыть переместить так же ещё и его объявление из интерфейса, да ещё и поменять область видимости с private на protected.
В IDE мне достаточно вызвать диалог "переместить метод" и получить варианты для всего этого. Так же, IDE любезно известит меня, что есть другие классы, которые используют этот метод и спросит что с ними делать.
Я уже отвечал на то, как следует проводить такого рода рефакторинг. Не размазывайте сомнительную логику и семантику по системе до тех пор, пока вы эту логику и семантику четко не определите. Как так у вас получается, что вы именнуете свойство или метод, реализуете на базе этого класса систему, а затем вдруг решаете, что у вас имя неподходящее?
Чтоб уж мой коммент не звучал слишком «тощим», отвечу на оба ваших примера:
1. Занимайтесь переименованием полей на этапе тестирования, до того, как класс будет напрямую использован в системе. Иногда приходится переименовывать поля в старых, часто используемых классах, к примеру если появляется новое поле, которое делает имя первого не уникальным, но по моему опыту скажу, что это настолько редкое явление, что какой то особой функциональности от редактора это не требуется, простого grep и 3 минут времени вполне достаточно
2. Слышал о такого рода рефакторинге, но лично никогда с ним не сталкивался. Занимался вынесением, а не переносом метода, в базовый или новый класс, но с этим проще, так как это одинаковые, либо новые семантики (соответственно). Если когда либо с этим придется столкнуться, то за много лет, это будет первый раз, что так же решится 3-5 минутами и не потребует особого функционала от редактора
Чтоб уж мой коммент не звучал слишком «тощим», отвечу на оба ваших примера:
1. Занимайтесь переименованием полей на этапе тестирования, до того, как класс будет напрямую использован в системе. Иногда приходится переименовывать поля в старых, часто используемых классах, к примеру если появляется новое поле, которое делает имя первого не уникальным, но по моему опыту скажу, что это настолько редкое явление, что какой то особой функциональности от редактора это не требуется, простого grep и 3 минут времени вполне достаточно
2. Слышал о такого рода рефакторинге, но лично никогда с ним не сталкивался. Занимался вынесением, а не переносом метода, в базовый или новый класс, но с этим проще, так как это одинаковые, либо новые семантики (соответственно). Если когда либо с этим придется столкнуться, то за много лет, это будет первый раз, что так же решится 3-5 минутами и не потребует особого функционала от редактора
Инетерсно, многие поклонники IDE, любящие холиварить на тему IDE vs Vim, часто говорят, что Vim оптимизирует редко используемый функционал редактора (кодонаписание и серфинг по файлам), а IDE добавляет часто используемый функционал (рефакторинг). Пока я вижу обратную тенденцию, а именно: Vim оптимизирует самый часто используемый функционал, а современные IDE добавляют самые редко используемые (возможно даже инновационные) возможности.
Комментрий не совсем адресован вам, но из читателей здесь осталось не так уж много людей, так что…
Комментрий не совсем адресован вам, но из читателей здесь осталось не так уж много людей, так что…
Ну, из примеров я написал ту пару, которую я точно в Vim не видел. Остальное — кому что удобнее, тот тем пусть и пользуется, лишь бы не проседала его персональная и его командная работоспособность.
Вопрос рефакторинга я в Vim даже не изучал по двум причинам:
1. Vim не умеет понимать код, а плагины работающие на регулярках это не серьезно
2. Рефакторю на ранних этапах и стараюсь минимизировать зависимости, потому если и приходится заниматься рефакторингом старых классов, то делаю это настолько редко, что потребности в автоматических механизмах не испытываю
В остальном согласен, зависит от процесса разработки и предпочтений
1. Vim не умеет понимать код, а плагины работающие на регулярках это не серьезно
2. Рефакторю на ранних этапах и стараюсь минимизировать зависимости, потому если и приходится заниматься рефакторингом старых классов, то делаю это настолько редко, что потребности в автоматических механизмах не испытываю
В остальном согласен, зависит от процесса разработки и предпочтений
Ну так и приводите примеры такого рефакторинга, для которого IDE действительно полезен.
Для чего? Для вас это за гранью опыта. Вы работаете с мелкими проектами с небольшим сроком жизни где не требуется оценка не то что в человеко-годах, но даже в человеко-часах…
Зачем вам эти ненужные знания?
Тобишь о «красная, зеленая, рефакторинг» вы не слышали?
Как это помогает при расширении интерфейса у уже живущего проекта?
Бегаете по сфейлившимся тестам, вместо того чтобы сделать это нормально в несколько кликов?
Приведите пример генерации класса для задачи с отложенным выполнением и регистрацией его в конфиге. Ну или хотя бы пример генераци простого API контроллера для операций CRUD.
Для какого из фреймворков?
Или он для вас единственный и неповторимый? :D
Пользуйтесь apigility, swagger
Vim настолько многогранен, что я учусь каждый день.
Речь шла об IDE, которыми вы не знали и не знаете как пользоваться.
Для вас это за гранью опыта
Очередные безосновательные заявления.
Как это помогает при расширении интерфейса у уже живущего проекта?
О каком интерфейсе речь? Семантика или UI? Если у вас проблема в переименовании свойств и методов, то гляньте на подход к разработке, а не ищите костыли.
Бегаете по сфейлившимся тестам
Зачем по ним бегать, там все явно и понятно.
Для какого из фреймворков?
Или он для вас единственный и неповторимый?
О каких фреймворках речь? Я говорю о любом проекте, в котором используются контроллеры или миграции. Берите любой на ваш вкус. Вы знаете что такое кодогенерация?
Речь шла об IDE, которыми вы не знали и не знаете как пользоваться
Очередные безосновательные заявления.
Очередные безосновательные заявления.
Тогда откройте нам тайну. По какой причине вы не в состоянии оценивать трудоемкость проектов в человеко-часах?
О каком интерфейсе речь?
Вот в этом все комбайнеры…
О интерфейсах классов, о которых мы ранее вели речь, и в качестве примера которых приводили метод save()
Зачем по ним бегать, там все явно и понятно.
Когда их 2 — конечно
Но в нашем сферическом примере их 50
О каких фреймворках речь? Я говорю о любом проекте, в котором используются контроллеры или миграции.
Вы еще не в курсе, что в разных фреймворках это реализуется индивидуально?
И Silex, Expressive, ZF, Laravel будут иметь отличные кодовые базы для контроллеров.
С миграциями чуть проще, но тоже будут отличия.
В конечном итоге заходите в PhpStorm -> Tools -> Save File as Template | Save Project as Template
используется
http://velocity.apache.org/engine/devel/user-guide.html#Velocity_Template_Language_VTL:_An_Introduction
Читаем, просвещаемся, используем, если очень надо.
И, да, я не даром привел в пример apigility — пользуйтесь.
Там есть много чего в экосистеме Zendframework
Очередные безосновательные заявления.
Да вы же своими вопросами основания как раз и даете — вы просто демонстрируете, что не знаете как использовать IDE
Тогда откройте нам тайну
Почитайте «Мифический человеко-месяц», там эта тайна открывается.
Когда их 2 — конечно
Но в нашем сферическом примере их 50
С чего вдруг? Даже если у вас такая необычная архитектура, то поправка первого теста может поправить и все остальные. Тесты только скажут где и что править. Повторюсь, если у вас эта задача действительно частая и вы настолько размазываете прямой доступ к свойствам класса по проекту, то либо у вас что то не то с архитектурой, либо вам действительно не обойтись без автоматического рефакторинга. К счастью, я на этом механизме не завязан.
Вы еще не в курсе, что в разных фреймворках это реализуется индивидуально?
И Silex, Expressive, ZF, Laravel будут иметь отличные кодовые базы для контроллеров.
С миграциями чуть проще, но тоже будут отличия.
Какое это имеет значение? Я знаю что тот же PHPStorm (о котором вы упомянули) этого не может, потому и прошу вас привести пример того, как с его помощью можно это реализовать. Я знаю что вы привести такой пример не сможете, и это возможно убедит вас в том, что все редакторы отличаются друг от друга функциональностью, и это нормально.
В конечном итоге заходите в PhpStorm -> Tools -> Save File as Template | Save Project as Template
используется
А при чем здесь шаблон файла? Я говорю о кодогенерации. Вы знаете что это такое? Подозреваю что не знаете. Я приведу вам пример — вам необходимо с помощью одной команды создать несколько классов с заполненным шаблоном, контроллер к ним и два экрана. Шаблоны вам тут не помогут, здесь нужно кое что сложнее.
И, да, я не даром привел в пример apigility — пользуйтесь
Зачем, когда есть Vim, который все это умеет. Как же вы живете с PHPStorm, если он даже такой элементарщины сделать не может? )
что не знаете как использовать IDE
Видимо вы читаете мои вопросы так, как вам удобно ) Я отлично знаком с возможностями IDE, особенно с PHPStorm и WebStorm, у меня есть от них лицензии и я ими активно пользовался в свое время.
Зачем, когда есть Vim, который все это умеет.
Сгенерируйте мне пачку (штук 10) моделей и мидлвейров для круда в Zend Expressive
схему БД вам дать?
И, да, судя по вашей заявке вам даже настраивать vim не придется, поскольку он это может сделать «искаропки»
В противном случае мы наблюдаем типичный пример балабола…
И остальное даже комментировать не имеет смысла.
Сгенерируйте мне пачку (штук 10) моделей и мидлвейров для круда в Zend Expressive
схему БД вам дать?
Вы сомневаетесь что консольный текстовый редактор не может создать десяток файликов с шаблонным содержимым? ))
И, да, судя по вашей заявке вам даже настраивать vim не придется, поскольку он это может сделать «искаропки»
А при чем здесь коробочность? Я считаю что редактор может все то, что способен сделать с ним пользователь. Я могу сделать перечисленное мной в Vim, а вы можете сделать это, на пример, в PHPStorm? Адепт «коробочности» это вы, не я, не надо нас путать )
В противном случае мы наблюдаем типичный пример балабола…
И остальное даже комментировать не имеет смысла.
Ахахах )) Не думал что дойдет до такого, но я приятно удивлен.
Собственно факт балабольства подтвердили.
Если не принимать во внимание создание самих шаблонов (которых кроме как руками никто не сделает), то генерация кода по шаблону проекта в PhpStorm займет ровно один клик.
Гораздо интереснее кодогенерация по существующим схемам БД или UML
И такое в IDE существует, например та же интеграция VisualParadigm в Netbeans или Idea
Если не принимать во внимание создание самих шаблонов (которых кроме как руками никто не сделает), то генерация кода по шаблону проекта в PhpStorm займет ровно один клик.
Гораздо интереснее кодогенерация по существующим схемам БД или UML
И такое в IDE существует, например та же интеграция VisualParadigm в Netbeans или Idea
Если не принимать во внимание создание самих шаблонов (которых кроме как руками никто не сделает), то генерация кода по шаблону проекта в PhpStorm займет ровно один клик.
Я вам привел конкретную задачу. Покажите мне решение ее на PHPStorm.
И такое в IDE существует, например та же интеграция VisualParadigm в Netbeans или Idea
Вы же адепт «изкоробки», о каких интеграциях вы говорите? )
В общем то на этом можно заканчивать монолог.
Да вы еще и туповаты
на эту конкретную задачу я вам дал решение
на эту конкретную задачу я вам дал решение
В конечном итоге заходите в PhpStorm -> Tools -> Save File as Template | Save Project as Template
используется
http://velocity.apache.org/engine/devel/user-guide.html#Velocity_Template_Language_VTL:_An_Introduction
Читаем, просвещаемся, используем, если очень надо.
Вообще говоря, если вам требуется кодогенерация, значит у вас очень большие проблемы с архитектурой, которая требует слишком много копипасты.
Кодогенерация это не только (и не столько) копипаста. Некоторые крупные части системы могут быть сгенерированны, вместо их повторной реализации в виде шаблонного решения. К примеру вам необходимо добавить новую сущность (автомобиль) в систему так, чтобы экраны этой сущности и контроллеры CRUD были так же доступны для администратора системы. Зачем пересоздавать класс сущности, экраны и контроллер, когда можно их сгенерировать и изменить в случае необходимости. Не всегда можно (нужно или возможно) реализовывать эту часть системы настолько гибко, чтобы избавится от кодогенерации, часто лучше использовать именно ее.
С другой стороны кодогенерация полезна при входе в проект новых разработчиков, плохо знакомых с его стандартами. Кодогенерация позволяет сформировать готовый шаблон для них.
С другой стороны кодогенерация полезна при входе в проект новых разработчиков, плохо знакомых с его стандартами. Кодогенерация позволяет сформировать готовый шаблон для них.
Если вам для создания таких сущностей потребовался кодогенератор, значит их больше 3 и значит уже есть потребность "реализовывать гибко". Собственно, кодогенерация — это простейший способ "реализовать гибко". Применять его имеет смысл, лишь когда используемый язык недостаточно мощный, чтобы вынести шаблонный код в отдельную сущность, которую можно реиспользовать.
Что это за язык вы предлагаете, позволяющий без усилий сформировать два класса, зарегистрировать их в локаторе служб и подготовить два шаблонных экрана?
D, JS, Lisp и его вариации.
Из перечисленных знаком только с JS. Можно пример реализации, позволяющей в одном классе или с помощью одной простой структуры сформировать модель, CRUD контроллер к ней и пару экранов? Экраны, я так понимаю, так же будут писаться на чистом JS?
var createModel = ({ name , props , actions }) => {
var Model = class extends BaseModel {}
Model.name = name
Model.props = props
actions.forEach( action => CRUD.registerAction( Model.makeAction( action ) )
}Видимо вы решили, что можно обойтись и без экранов?
Суть от этого не меняется.
Еще как меняется. Вы либо приводите полную реализацию, либо не приводите реализации вовсе. Экраны то вы точно не засуните в один файл с моделью и контроллером, как сделали выше )
В общем ваш ответ меня уже вполне устроил и можно не продолжать. Я вел немного к другому руслу, но получилось еще лучше, чем я планировал. Видите ли, очень часто противники Vim заявляют примерно следующее:
На деле мы видим аналогичную картину. Я вам предложил реализовать элементарную функцию, которая крайне важна, особенно в крупных проектах и при разработке корпоративных платформ (1С, CUBA Studio и т.д.), а вы предложили вместо реализации соответствующего, простейшего плагина в любимой IDE (уверен таковой уже есть для всех современных IDE) выбрать специальный ЯП (!), да еще и использовать декларотивную архитектуру. Более того, вы предложили сложить модель и контроллер в один файл, что сделает систему еще более запутанной, и все это для того, чтобы не «точить инструмент под себя». Для меня это крайне печально, но возможно читатель поймет лично мои цели во всех этих холеварах — не нужно бояться менять используемый инструмент, не важно Vim это или любой другой редактор.
В общем ваш ответ меня уже вполне устроил и можно не продолжать. Я вел немного к другому руслу, но получилось еще лучше, чем я планировал. Видите ли, очень часто противники Vim заявляют примерно следующее:
… а если в Vim нет элементарных функций, то начинают говорить, что они им просто не нужны
На деле мы видим аналогичную картину. Я вам предложил реализовать элементарную функцию, которая крайне важна, особенно в крупных проектах и при разработке корпоративных платформ (1С, CUBA Studio и т.д.), а вы предложили вместо реализации соответствующего, простейшего плагина в любимой IDE (уверен таковой уже есть для всех современных IDE) выбрать специальный ЯП (!), да еще и использовать декларотивную архитектуру. Более того, вы предложили сложить модель и контроллер в один файл, что сделает систему еще более запутанной, и все это для того, чтобы не «точить инструмент под себя». Для меня это крайне печально, но возможно читатель поймет лично мои цели во всех этих холеварах — не нужно бояться менять используемый инструмент, не важно Vim это или любой другой редактор.
Экраны то вы точно не засуните в один файл с моделью и контроллером, как сделали выше )
Вы можете засунуть в функцию всё то же самое, что засунули бы в кодогенератор.
Я вам предложил реализовать элементарную функцию, которая крайне важна
Крайне вредна. Я повидал не мало "крупных проектов", которые крупные лишь из-за использования копипасты.
Вы можете засунуть в функцию всё то же самое, что засунули бы в кодогенератор
В кодогенераторе я перечислю только целевые файлы в целевых папках и их типовые шаблоны. Можно конечно настроить работу более тонко, но не для данной задачи.
Я повидал не мало «крупных проектов», которые крупные лишь из-за использования копипасты.
Вы хотите поговорить об этом? ) А вы видали крупные платформы, которые используются сторонними разработчиками?
Вы можете засунуть в функцию всё то же самое, что засунули бы в кодогенератор.
это разное. Кодогенератор может "приготовить" статичный код, а в функции он будет "готовиться" при каждом вызове в runtime.
Не поверите, но у пользователей Vim со временем вырабатывается аналогичный участок в подкорке и переключение между режимами уходит на уровень подсознания.
- Сердце работает автономно от мозга. Наши конечности такое не умеют.
- 70% времени хороший программист работает головой, а не руками. Так что оптимизация перемещений рук — это ни о чём.
- Ну и как тут уже отметили, трекпоинт тоже позволяет не отрывать руки от клавиатуры.
Сердце работает автономно от мозга. Наши конечности такое не умеют
Вы тоже забываете как ходить? Надеюсь это не у меня одного такая проблема. А как печатать?
70% времени хороший программист работает головой, а не руками
Значит на оставшиеся 30% можно забить!
Так что оптимизация перемещений рук — это ни о чём
Это не аргумент. Давайте аргументы )
Ну и как тут уже отметили, трекпоинт тоже позволяет не отрывать руки от клавиатуры
И я думаю многие ими пользуются, что так же замечательно.
Я и как мышь держать не забываю. А ещё я пальцем в экран тыкаю, что быстрее, чем топтать клавиатуру.
Значит незначительная оптимизация редкой операции не даёт ощутимых преимуществ.
Я и как мышь держать не забываю
Ну так физиология и все такое, не? А, видимо это не имело отношения к теме.
А ещё я пальцем в экран тыкаю, что быстрее, чем топтать клавиатуру
Сильно зависит от задачи. Вы мыслите в контексте кнопок, я в контексте задач. Вы для выполнения задачи должны тыкнуть сюда-сюда-сюда, я должен нажать 'gC. Ощущаете разницу? Вот я об этом.
Значит незначительная оптимизация редкой операции не даёт ощутимых преимуществ
Ну если вы действительно редко пользуетесь мышью во время разработки, то вы, несомненно, молодец! К сожалению не все так.
И что делает пресловутый 'gC?
Ну у меня он добавляет в индекс все изменения и коммитит их.
Вы коммитите не проверяя сделанные изменения? Смело. Снимаю шляпу.
В том же вебшторме нажатие Ctrl+K открывает окно со списком изменений и возможностью их закоммитить. При этом чтобы узнать про этот хоткей — достаточно открыть меню VCS и посмотреть. И при этом у меня есть выбор — запоминать ли очередной хоткей или нет. Хоткеи для редких операци запоминать нет смысла — всё равно забудешь к моменту, когда они снова понадобятся.
Вы коммитите не проверяя сделанные изменения? Смело. Снимаю шляпу.
Ну так для проверки можно и 'gs выполнить, или 'gl если уж по истории побегать нужно.
В том же вебшторме нажатие Ctrl+K открывает окно со списком изменений и возможностью их закоммитить
Ну так если вы пользуетесь клавиатурой для таких операций, вы все делаете правильно. Мышка здесь не нужна.
Явно написано человеком, который совершенно не понимает о чем говорит. Возможность управлять всем процессом не прерываясь на мышь и клавиши позволяет сфокусироваться, быстро находить что искал, виртузно манипулировать окнами, переключаться между задачами и т.д. Сам факт того что эти редакторы уже чуть ли не полвека живут, развиваются и пользуются огромнейшим спросом говорит о многом. В большинстве своем, те кто рассуждает в русле «Vim, Emacs или Лиспы вымерли или нафиг никому не сдались» сами то никогда даже и не пытались. И да, генератор Guid-ов в Emacs таки есть.
«на мышь и клавиши со стрелками» я имел ввиду
Спасибо за переход на личности первым же сообщением, отличный аргумент. Вы, конечно, понимаете и за себя, и за меня.
Все эти редакторы не вымерли, просто они такие же артефакты из прошлого, как sed и awk. Мощно? Не вопрос. Просто? Еще как. Нужно кому-нибудь? Конечно. Сколько людей пользуется сейчас для написания нового кода? Два с половиной.
Все эти редакторы не вымерли, просто они такие же артефакты из прошлого, как sed и awk. Мощно? Не вопрос. Просто? Еще как. Нужно кому-нибудь? Конечно. Сколько людей пользуется сейчас для написания нового кода? Два с половиной.
Ну так Вы должны понимать что называя ерундой то, чем огромное количество разработчиков живет и зарабатывает себе на жизнь, в какой-то мере сам первым же сообщением на личности по сути и перешли. Насчет того что мало кто пользуется, очень даже заблуждаетесь. Очень даже пользуются. Иначе с чего бы плодились эти все Neovim-ы, Spacemacs-ы, Emacs prelude и прочие? Я живу и работаю в Сан-Франциско, у нас в нашем офисе полсотни человек разработчиков, dev-ops, data engineers и пр. Из них только двое пользуют Sublime, один Atom, один IntelliJ, один Eclipse (да и тот пытается на Emacs пересесть), остальные либо Vim, либо Emacs. Может наша компания исключение? Не думаю. Я посещал офисы Atlassian, Google, Docker, Github, Yelp и многие другие. Примерно такая же ситуация. Откройте любой мало-мальски уважаемый редактор — скорее всего к нему существует Vim-plugin.
Стараюсь называть вещи своими именами. Модальная ерунда — это модальная ерунда, будь она хоть в любимом редакторе, хоть в интерфейсе микроволновой печи, хоть где-то еще. Любые режимы увеличивают когнитивную нагрузку, точка. Если вы готовы с этим мириться ради экономии времени на перенос руки на мышь или нажатие стрелок — имеете полное право. Более того, переход «ты ругаешь утилиту, ей пользуются люди и им нравится, значит ты ругаешь и этих людей тоже» — это демагогия, которая не имеет под собой логической основы.
Я живу и работаю в Баварии, в нашем офисе около 20 разработчиков железа, специалистов по board bring-up и разработчиков драйверов — ни VIM, ни EMACS я не видел нигде. Посещал офисы Bosch, Siemens, Vector и многих других — примерно та же ситуация. Откройте любой мало-мальски уважаемый редактор — и по умолчанию там никаких режимов нет, и VIM-режим там тоже никто по умолчанию не включает.
Я живу и работаю в Баварии, в нашем офисе около 20 разработчиков железа, специалистов по board bring-up и разработчиков драйверов — ни VIM, ни EMACS я не видел нигде. Посещал офисы Bosch, Siemens, Vector и многих других — примерно та же ситуация. Откройте любой мало-мальски уважаемый редактор — и по умолчанию там никаких режимов нет, и VIM-режим там тоже никто по умолчанию не включает.
Вот! Вот в чем основное заблуждение. Дело то не в экономии времени. А в потрясающем удобстве. Да, конечно оно не дается даром, для выработки навыков и привычки нужно время. Сам незаметно для себя Вы только что подменили понятия. Чем же перенос руки на мышь или нажатие стрелок не «модальная ерунда» (или то что Вы понимаете под этим) в таком случае? Короче пора заканчивать этот спор. Я в отличии от Вас видел и по ту и по другую стороны. И vim-ом пользуюсь и Emacs-ом. И знаю что многие софтверные продукты (иногда совершенно незаметно для непосвященных) многие вещи от них переняли. Даже многие сайты — Gmail, Github, Trelo и т.д. и там (на гитхабе точно) те клавиши по умолчанию включены. Для Вас я так понял само по себе слово «модальность» неприятно. А для меня же без Vi-режимов процесс моей работы представляется как работа художника, которому нужно рисовать картину не отрывая кисть от холста.
Ваша уверенность в том, что я не пробовал VIM и EMACS и не отказался от них сознательно — ни на чем не основана. Пробовал, остановился на альтернативах. Да, режимы в интерфейсах терпеть не могу и стараюсь избавляться от них там, где это возможно.
Не хотите спорить — дело ваше, вам удобно — на здоровье.
Не хотите спорить — дело ваше, вам удобно — на здоровье.
Представьте себе какой нибудь КонтрСтрайк или подобную игрушку. Режим приседания игрока, кому удобно сделать его переключаемым, а кому удобно, отпустил клавишу — игрок встал. Так-же с переключением снайперского режима. Так вот мне представляется это как если бы Вы говорили «Все это ерунда, надо играть без всяких приседаний и снайперских режимов, ибо модальность это плохо»
В вашем примере нет модальности в интерфейсе. Кнопка приседания означает только приседание и ничего больше. А вот если у вас есть какая-то кнопка «мета», при нажатии на которую кнопка «приседание» теперь кнопка «сменить оружие на пистолет» — вот тут модальность в интерфейсе и появляется. На клавиатуре у нас такими оказываются CapsLock (на нем у меня смена раскладки), NumLock (всегда включен) и Scroll Lock (почти не пользуюсь). При этом, если раскладок становится больше двух (три, например, немецкая еще), то переключать их циклически, как предлагает ОС по умолчанию — это просто кошмар.
Чем же перенос руки на мышь или нажатие стрелок не «модальная ерунда» (или то что Вы понимаете под этим) в таком случае?
Ну поставьте себя на место людей, не любящих «модальную ерунду», они и так переключаются между мышью и клавиатурой, а вы хотите, чтоб они еще и на программном уровне между режимами прыгали. Естественно никому это не понравится. Начинать надо со слепого-десятипальцевого, затем переходить к полному отказу от мыши, только потом, возможно, начинать тыкать Vim.
По теме о «других компаниях», помню как меня коробило, когда некоторые разрабы в процессе набора уводили палец на тачпад, дабы выделить им кусок кода, брр…
"уводили палец на тачпад" — тоже не понимаю… ведь для этого есть большой палец, который достаточно просто с пробела "сбросить". Либо тем же Trackpoint выделить, что тоже "не уводит" палец с клавиатуры
Это не ко мне, я о реальном случае, когда программист бросал всю руку на свой тачпад и одним указательным пальцем правой руки водил курсор по коду. Я не знаю зачем он делал именно так, а не более удобным способом (тот что вы предложили), но меня это сильно удивило. Неужели это удобнее нажатия одной лишней клавиши на клавиатуре?
Как нажатием одной клавиши выделить текст с середины 5 строки, до середины 15?
Никак, таких задач в программировании не встречал, возможно потому, что обычно работаю с синтаксическими конструкциями и выделаю, к примеру: тело функции, блок условия, аргументы метода, свойства класса, аттрибут тега и т.д.
С одной стороны — это увеличивает продуктивность, с другой, — избавляет от заболеваний суставов кистей.
vi был модальным, потому что другой парадигмы UI тогда не было. Потому что предшествовавшие ему строковые редакторы, вроде ed, были модальными. А те, в свою очередь, не могли не быть модальными, потому что должны были работать «одинаково хорошо» как на новомодных видеотерминалах, так и на привычных телетайпах.
С появлением концепции Gypsy (40 лет прошло) пользователи должны были забыть о «режимах» как о дурном сне. Но в результате причудливой аберрации массового сознания мы кое-где ещё имеем vim.
Пользователи и забыли. А прагматичные программисты как меняли CapsLock на Ctrl (потому что так изначально и было и так удобней) так и Vim-ом и Emacs-ом будут и через 20 лет пользоваться. Потому что удобней.
А программисты разве не пользователи? Они другим местом думают или печатают?
Выше CodeRush совершенно правильно написал: модальность несёт лишнюю когнитивную нагрузку и противоречит хорошему UX. Я напоминаю, что режимы в полноэкранных редакторах возникли не как осознанное улучшение, а как наследие «тёмных веков», когда сначала терминалы не умели скроллить, а потом жалко было выделить 2000 байт ОЗУ на экранный буфер, и т. д. Поэтому существование модальных текстовых редакторов сейчас − это скорее некритично воспринимаемая традиция вроде пресловутого «бананового душа», чем чей-то осознанный выбор.
Выше CodeRush совершенно правильно написал: модальность несёт лишнюю когнитивную нагрузку и противоречит хорошему UX. Я напоминаю, что режимы в полноэкранных редакторах возникли не как осознанное улучшение, а как наследие «тёмных веков», когда сначала терминалы не умели скроллить, а потом жалко было выделить 2000 байт ОЗУ на экранный буфер, и т. д. Поэтому существование модальных текстовых редакторов сейчас − это скорее некритично воспринимаемая традиция вроде пресловутого «бананового душа», чем чей-то осознанный выбор.
Вы понимаете чем оправдан осознанный отказ от мыши в пользу манипулирования клавиатурой? Не понимаете? Тогда разговор можно заканчивать. А теперь допустим, вы поняли что лучше и быстрее и удобнее сделать что-то прямо с клавы, чем каждый раз дергаться за мышью, искать глазами курсор, попадать курсором куда надо, открывать бесчисленные меню, и т.д. Тогда все самые важные действия забиваются на комбинации клавиш. Так? А теперь попробуйте-ка запомнить все эти комбинации. К тому же набор получается ограниченный, рано или поздно идеи по установке действий на всякие `Ctrl+Shift+Alt+еще что-то` себя исчерпают. Существование модальных редакторов сейчас — это не традиция, не «дань моде» и не хипстерство. Так же как и многочисленные версии механических клавиатур. Просто так удобнее. Ну а если Вам нравится думать что они так мучаются и даже не знают… Ну, уж наверное не буду переубеждать.
OFF: для того, чтобы "не дёргаться за мышью" умные люди придумали Touchpad и TrackPoint. А ещё часть людей придумали для них дублирующие левые/правые кнопки сверху и снизу от Touchpad
Я тоже когда-то выделял куски кода, вырезал, копировал, вставлял «а-ля Winword». А потом понял что научился делать это гораздо удобней и с большей аккуратностью клавиатурой. Я могу выделить слово, предложение, функцию, в кавычках, в скобках, вместе с кавычками, нужный тэг, нужное количество строк. И делать это гораздо быстрее.
1) лично я использую гибрид — что быстрее тем и делаю
2) не всегда под рукой "любимая ОС с любимым редактором" и тогда начинается ломка от "механического незнания" альтернатив кроме горячих клавиш клавиатуры
не всегда под рукой «любимая ОС с любимым редактором» и тогда начинается ломка от «механического незнания» альтернатив кроме горячих клавиш клавиатуры
Это не повод ограничивать себя, когда под рукой таки есть «любимая ОС с любимым редактором». Или повод? )
всё зависит от того, насколько часто приходится переключаться на другое оборудование :) Если не переключаетесь вовсе или крайне редко, то да, не повод.
Ну если программисту нужно часто переключаться между оборудованием, я считаю, у программиста или всего проекта проблемы с деплоем.
дело не в деплое. У нас в команде зоопарк ноутов — маки, винда, линуха. Когда подходишь к коллеге и пробуешь что-то показать с использованием его оборудования, то вот тут и происходит ломка.
Я с подобным не сталкиваюсь в последнее время, ибо работаю из дому, но когда сталкивался, все решалось достаточно просто: либо интересующийся коллега сам подходил ко мне, и я ему показывал все что хотел на своем компьютере; либо я приходил к нему, и без особой ломки в комтях показывал все что нужно на старом, добром, безмодальном интерфейсе. Хз, если это нужно делать очень уж часто, то вам нужно поговорить с начальством, дабы они приплачивали вам за консультации )
И умные люди расположили Touchpad и TrackPoint прямо над основным рядом клавишь для слепого десятипальцевого? Круто! А хотя не, это же физически не возможно… Ну значит умные люди просто заменили один аппарат для управления курсором на другой, что совершенно не решило проблему модальности интерфейсов ввода аппаратного уровня.
вот сколько живу, но реально программистов, использующих слепой десятипальцевый метод в окружении не вижу — только на хабре про него слышу. Это не не говорит о том, что ему нет места быть, но хотелось бы увидеть этих разработчиков что называется "в живую"
Давайте увидимся, я вот в Питере живу ) Мышкой пользую только по причине кривости в реализации некоторых HTML компонентов (аудио, видео и хитрых JS) на Firefox.
Давайте устроим хакатон и на скорость закодим какую-нибудь приложуху. :-D
А гуглить с помощью клавиатуры — одно удовольствие.
Давайте устроим хакатон и на скорость закодим какую-нибудь приложуху
Уже делали, можете глянуть среди моих комментов было видео об этом.
А гуглить с помощью клавиатуры — одно удовольствие
Не только гуглить, попробуйте переходить по ссылкам с ее помощью.
Уже делали, можете глянуть среди моих комментов было видео об этом.
Если вам лень скопировать ссылку, то мне не менее лень её искать.
Не только гуглить, попробуйте переходить по ссылкам с ее помощью.
Так себе удовольствие.
Если вам лень скопировать ссылку, то мне не менее лень её искать
Крайне лень, если честно. Да и мне так же будет необходимо сначала ее найти.
Так себе удовольствие
Уже попробовали?
Вам в любом случае проще найти, зная где и что искать.
Разумеется.
Вам в любом случае проще найти, зная где и что искать.
Согласен, но мою лень это не убеждает.
Разумеется
А как на счет навигации по странице с помощью asdf?
А с чего вы взяли, что моя лень менее ленивая, чем ваша?
И что делают asdf?
А с чего вы взяли, что моя лень менее ленивая, чем ваша?
Ну вы же предложили хакатон и т.д., я вам лишь сказал, что уже делал это и предложил найти мой коммент с видео. Если вы не хотите, я вас не заставляю )
И что делают asdf?
Ну смотря что вы захотите, лично я настроил так:
Примерчик
a — предыдущая вкладка
s — следующая вкладка
d — вверх на одну строку
f — вниз на одну строку
с — вверх на страницу
v — вниз на страницу
r — обновить страницу
t — закрыть вкладку
e — перейти по ссылке
w — назад по истории просмотров
q — вперед по истории просмотров
s — следующая вкладка
d — вверх на одну строку
f — вниз на одну строку
с — вверх на страницу
v — вниз на страницу
r — обновить страницу
t — закрыть вкладку
e — перейти по ссылке
w — назад по истории просмотров
q — вперед по истории просмотров
Правая рука на мыши, левая на asdf. Мне удобно.
а просветите, в чём удобнее Ctrl для смены раскладки перед Caps? до него же мизинцем дальше двигаться
Ctrl раньше находился там, где находится сейчас CapsLock. Многие первым делом CapsLock переначивают на Ctrl. Потому как CapsLock в принципе не нужен. А вопрос я не совсем понял, Вы что Капсом с кириллицы на латынь переключаете?
у типичного Vim/Emacs пользователя пальцы большую часть времени проводят в «исходной позиции» — <JKL:> Потому и получается что удобнее как-раз тогда, когда Ctrl там, где изначально и был
Значит, людей этот вопрос интересует. Значит, надо писать статью
Не надо писать статьи только потому, что кого то интересует какой то вопрос. Важнее, чтобы вы в этом вопросе были компетентны.
Ответ: Программируемые веб фрейморки, для построения высокоэффективных IDE
Сильно зависит от задачи. Если вы пишете школьную дипломную работу, вам не нужен фреймворк для построения высокоэффективных IDE. И почему должны использоваться именно веб фреймворки?
>Программируемые веб фрейморки, для построения высокоэффективных IDE!
То есть IDE писать на Sympony (PHP)?
А в чем ее писать?
Немного рекурсия выходит :)
То есть IDE писать на Sympony (PHP)?
А в чем ее писать?
Немного рекурсия выходит :)
А как насчёт поддержки нескольких мониторов? Я для работы использую 4. IDE стабильно занимает 2-3. Причём не тупо растянута, а работает в 4-5-6 окнах. Что-то я с трудом представляю ViM в таком режиме. А что касается эффективности, то могу сравнить с домом, где всего два монитора — на работе проще и быстрее.
Xmonad.
Ну это просто оконный менеджер. Мне и стандартных средств в Windows вполне хватает :) Вопрос в том может ли ViM мне обеспечить взаимосвязанную работу в нескольких окнах?
Что есть «взаимосвязанная работа в нескольких окнах»?
Приведу простой пример — окно редактора, окно с результатами поиска, окно с деревом исходников, окно с Javadoc. В поиске все классы, в которых надо поменять документацию. Все перед глазами, меняя что-то в редакторе я вижу сгенерированный javadoc, в дереве исходников информация о общем состоянии проекта (наличие ошибок, SCM статус и т.д.), окно с поиском позволяет переключатся между необходимыми классами и оценить фронт работ. Пример несколько искусственен, но демонстрирует «взаимосвязанную работу в нескольких окнах» в рамках ОДНОГО приложения.
Сильно сомневаюсь что все это должно реализовываться на базе Vim, скорее вам нужно смотреть в сторону Emacs и других «все в одном» редакторов. Если вас интересует именно Vim, то ему все равно, какие данные хранятся на диске. Если вы при изменении документации в классе настроете автоматическую генерацию javadoc, то Vim вам ее покажет в соседнем окне (это вполне реализуемо, делал так при работе с Less).
Ну если Vim — «это мощнейший фреймворк, для построения высокоэффективного IDE», то да — должно. А пока это не так всё, что написано в статье просто слова, по крайней мере для меня. Потому, что редактирование файлов это меньше 1 процента моей работы как программиста :) За прошедшую неделю я написал не больше одного килобайта текста. Еще килобайт 5-10 сгенерировала IDE (заметьте, я не тратил время на «Если… настроите» — оно само из коробки :) и закрыл при этом 8 issues из трекера. Так, что в моём случае, эти «мощнейшие фреймворки» наверно резко уменьшат время потраченное на этот 1 процент, но к сожалению значительно усложнят оставшиеся 99%
Ну если Vim — «это мощнейший фреймворк, для построения высокоэффективного IDE», то да — должно
И кофе варить должно?
оно само из коробки :)
Вам нужно смотреть в сторону продукции от JetBrains, она много чего может «из коробки». Прелесть Vim (и не только Vim, а любого, настраиваемого редактора) в другом. Это как подход к решению задач в Windows и Linux.
Так, что в моём случае
Значит вам ни в коем случае не надо пользоваться Vim. Я поздравляю вас с тем, что вы нашли свой инструмент. Правда вас вроде никто не убеждал в обратном. Ну да ладно…
На мой взгляд полезно иметь навыки как Vim так и IDE. Мне вот приходиться иметь дело почти каждый день с Vim, SublimeText и WebStorm. И чувствую себя замечательно работая со всеми тремя.
Собственно на этом все дискуссии о выборе заканчиваются, а в подобные посты захожу ради любопытства.
Собственно на этом все дискуссии о выборе заканчиваются, а в подобные посты захожу ради любопытства.
Мне кажется, у некоторых людей, включая меня, мышление просто не очень хорошо приспособлено к запоминанию последовательностей из символов, которые нужно нажать для выполнения операций. Vim я пользуюсь довольно часто, но, либо что бы что-то поправить на сервере, либо что бы написать скрипт, состоящий из одного файла и не имеющий достаточно сложных зависимостей. Для написания кода раньше пользовался sublime (сейчас все еще пользуюсь им для просмотра кода, очень уж удобно там с древовидными структурами проектов работать), сейчас использую VS Code (которая тот же Atom), только из за чуть более удобной работы с git. По поводу скорости набора — может у меня все на столько плохо с памятью, но я, не смотря на то, что пользуюсь 10 пальцевым методом для русского языка и неплохо ориентируюсь в латинице уже лет 10, иногда на несколько секунд задумываюсь, например о местоположении символа "'" (одиночная кавычка), просто из-за того, что не могу в памяти присвоить ей какой-то звук который ассоциируется с необходимым движением пальца. А вообще все эти споры, по моему мнению, возникают только из-за того, что кто-то привык к одному инструменту, кто-то к другому, и для себя максимально быстро выполняет операции именно с помощью этого инструмента (я вот так и не смог научиться комфортно пользоваться vimdiff, meld для меня все же приятнее). По этой же причине, скорее всего, те, кто привык к одному инструменту, когда у них спрашивают, как с помощью их любимого инструмента сделать какую-то нестандартную операцию (которая для спрашивающего может быть вполне стандартной), чаще всего пытаются свести разговор к тому, что на самом деле эта операция вообще не нужна (что для них вполне может быть верным, в отличие от спрашивающего).
p.s: возможно написал довольно сумбурно, но надеюсь смысл того, что я хотел сказать будет понятен, и я вообще считаю что лучше всего идеально знать инструмент которым удобнее пользоваться, и после этого стараться изучить как можно большее количество альтернативных способов, никто не знает что может пригодиться в каждом конкретном случае.
p.p.s: на основании всего что я написал, на вопрос автора в конце статьи я бы ответил: «нет лучшего IDE или редактора, лучше пользоваться тем, чем умеешь пользоваться лучше всего»
p.s: возможно написал довольно сумбурно, но надеюсь смысл того, что я хотел сказать будет понятен, и я вообще считаю что лучше всего идеально знать инструмент которым удобнее пользоваться, и после этого стараться изучить как можно большее количество альтернативных способов, никто не знает что может пригодиться в каждом конкретном случае.
p.p.s: на основании всего что я написал, на вопрос автора в конце статьи я бы ответил: «нет лучшего IDE или редактора, лучше пользоваться тем, чем умеешь пользоваться лучше всего»
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Текстовые редакторы vs IDE