Pull to refresh

Comments 444

Вы на верном пути! Осталось только изучить ed! :)

Чему научил меня vi во фряхе - ставить первым пакетом mc...

И вредный совет - если вас бесит отсутствие возможности работать под рутом в современных линухах - sudo mc в помощь.

Всегда так делаю =) особенно, sudo mc

UFO just landed and posted this here

За неимением Фара в Линуксе и mc сойдет. Но придется привыкать ко всяким странностям и мелким глюкам.

а кто работал с фар под линукс?

какие впечатления? есть смысл вместо mc использовать?

КМК есть. Нет странных заморочек с консолью как в mc

Впечатления: наконец-то скорость работы в Linux приблизилась к скорости работы в Windows. И оказывается, что консоль в Linux может быть супер-отзывчивой, а не как в mc.

Я mc запускаю не всегда, в основном для навигации по файловой системе, потом его закрываю и все делаю в командной строке.

К vi привык, как редактор абсолютно устраивает, но с linux работаю почти исключительно в терминалке без графики.

Безусловно соглашусь с постулатом, что при большом количестве действий, особенно однотипных, надо избавляться от мышечного способа работы и стараться работать только клавиатурой - и быстрее, и рука и шея меньше устают!

Согласен, если нужно вдумчиво отредактировать три файла конфигурации, то почти нет разницы, какой инструмент использовать. А если нужно активно перемещаться по дереву ФС, применять групповые действия к файлам, просматривать и редактировать текст, то у Far один из наиболее быстрых и отзывчивых UI. Как впрочем и у многих его предшественников (DN, VC, NC) и конкурентов, но не у MC.

Я уже несколько раз задумывался записать скринкаст типичной интенсивной работы в Far, чтобы можно было сравнивать тайминги с другими способами работы с файлами.

при большом количестве действий, особенно однотипных

Надо автоматизировать.

Полностью согласен! При моей лени только автоматизация и спасает!

Ну хз, для быстрой навигации удобнее использовать fasd / autojump или аналоги. Просто пишешь j название директории, и сразу в неё попадаешь.

Весьма точное замечание.

Для меня появление far2l стало решением многих проблем в Linux.

В том числе и редактирования текстовых файлов.

DoubleCommander + NotepadQQ (аналог Notepad++) редактором + Meld (аналог WinMerge) для сравнения файлов к нему прикручены. Без проблем.

NotepadQQ (аналог Notepad++)

geany же

Теперь автору осталось убрать все эти фреймворки и сторонние библиотеки из самого кода, чтобы понять "как много вы упускаете за слоем абстракций".
После этого можно будет точно написать "Теперь это мое детище." :)

Натыкался на мнения что это приемлемый способ «вкатиться в vim» - использовать готовые сборки, например Lazy/Astro/Cosmic/SpaceVim - так можно сразу увидеть возможности глубоко закастомизированного vim, без того чтобы потратить год (а скорее всего забросив спустя непродолжительное время) на попытки сделать все самому

Что всегда бесило в линух подобном софте - ты не можешь его сразу использовать, даже эти сборки, почему нельзя сделать как notepad++ - скачал, распаковал, запустил и работаешь? Даже Ардуино 1.х версий так работает и с минимальным вмешательством становится полностью портабл.

Надеюсь что код - машинный. А то слишком много упускается за слоем абстракций от компиляторов. И кстати операционой системы тоже быть не должно - слишком много упускается за ее слоем абстракций. Вот после этого он станет настоящим "веб-разработчиком", а пока это полумеры какие-то.

Каждый раз от прочтения подобных статей про "как я перешёл на vim и теперь всем его советую", возникает столько вопросов, но ни когда на них нет ответа. А тут прям целая гора спорных утверждений которые я не мог не прокомментировать.

Ради чего все эти приседания с настройкой и запоминание сотен хоткеев текстового редактора который вообще не для этих задач был создан?

Почему vim, а не emacs?

Как использование какого то текстового редактора делает разработчика компетентнее и в чем?

При чем тут вообще фундаментальные знания и как примитивный текстовый редактор даст знание о том как работают кэши процессора, дисковая подсистема, сетевые интерфейсы, криптография, компиляторы и прочие реальные фундаментальные знания?

Какие ещё "абстракции" текстовый редактор скрывает? я мб чего то не знаю из-за того что пользуюсь VS и большую часть времени пишу на C/C++.

Ради чего все эти приседания с настройкой и запоминание сотен хоткеев текстового редактора который вообще не для этих задач был создан?

С этим-то как раз понятно - есть масса людей, которым нравится тратить кучу времени, настраивая свою рабочую среду "под себя". Это примерно как делать перестановку мебели в квартире. Кому-то хочется новенького, кто-то удивляется, зачем ломать то, что хорошо работало.

Ради чего все эти приседания с настройкой и запоминание сотен хоткеев текстового редактора который вообще не для этих задач был создан?

В первых это красиво.

Во вторых это кайфово.

Создан был как раз для управления компьютеров и редактирования текстов - что и есть программирование.

Как использование какого то текстового редактора делает разработчика компетентнее и в чем?

Кайфующий от своей работы всегда будет компетентнее того, кто не кайфует.

Стремящийся к минимализму и эффективности разработчик компетентнее не стремящегося.

Ищущий и пробующий новые инструменты будет компетентнее не ищущего.

Создан был как раз для управления компьютеров и редактирования текстов

Ага, для управления терминалом 1970х годов с коннектом в 300 бод и клавиатурой без стрелок. У модального режима, который адепты вима считают образцом эргономики, ноги растут именно оттуда.

Цитата Bill Joy, автора оригинального vi:

It was really hard to do because you've got to remember that I was trying to make it usable over a 300 baud modem. That's also the reason you have all these funny commands. It just barely worked to use a screen editor over a modem. It was just barely fast enough. A 1200 baud modem was an upgrade. 1200 baud now is pretty slow.

Так или иначе вы хотите передавать компьютеру информацию о том, каким хотите видеть текст. Чем короче частоиспользуемые команды, тем лучше (а точнее чем меньше сумма произведений частоты использования команды n на её частотность), но тем выше порог входа.

И вот тут лимит в 300 бод в момент разработки был очень кстати.

Чем короче частоиспользуемые команды, тем лучше

Это для машины так. Для человека есть куча дополнительных факторов: время генерации последовательности команд, вероятность ошибки, физическая сложность выполнения команд, и прочее.

Например, мне надо переместиться на 3 строки вниз и 6 символов вправо и что-то там набрать. Теоретически что-то типа "3 j 6 l" - самый короткий способ, 4 нажатия. Практически - высчитать строки и символы дольше, чем просто передвинуть курсор. Для 2 строк и 2 символов вим так и вовсе в проигрыше в любом случае, потому что надо еще "esc" и "i". К слову о режимах - было бы интересно посчитать потери времени на ошибки "не тот режим". В общем, много моментов.

Было бы неплохо поставить эксперимент, но нормально его спроектировать может только очень опытный пользователь вима, это не я..

было бы интересно посчитать потери времени на ошибки "не тот режим"

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

Пример с раскладкой не вполне корректен, по причине того, что после ввода текста, вы не возвращаете раскладку в исходное положение. То есть нет главной раскладки, они равнозначны, и переключаются по требованию.

А у вима как раз есть самый главный режим - коммандный. Как только вы закончили вводить буковы, вы должны нажать esc. Вся навигация, все действия - именно в нём. Вставка буквально только для того чтобы вставить буквы, и вернуться к основному режиму. Не нравится формулировка "главный режим" - окей. Тогда "режим по-умолчанию". Суть одна.

Так что, если вы перепутали режим, то это, так называемое, "skill issue". Ну, либо вас отвлекли слишком внезапно. В этом случае, просто на всякий случай, когда возвращаетесь к работе, контрольный esc в консоль, даст возможность начать работу с режима по-умолчанию.

Кстати, именно поэтому я настраиваю отдельную раскладку для каждого окна и чтобы для новых окон всегда была латиница. Конечно, всё равно в каком-нибудь долго открытом браузере периодически будешь забывать какая раскладка стоит, но массу других случаев заметно облегчает.

Постоянно чертыхаюсь, когда вместо | на клавиатуре располагается левый край бэкспейса, увеличенного до 2U, а вместо энтера оказывается бэкслэш.

Я не использую сам vim, но радуюсь vim эмулятору в IDE(в основном продукты jet brains). И я никогда не промахиваюсь по разным режимам/раскладкам. У этого есть цена - лишнее нажатие. Хотя в PyCharm по внешнему виду курсора можно понять в каком режиме vim.
1. Раскладка. У меня левый shift всегда английский, правый всегда русский. По этому, если я отвлекался, то я просто всегда перед набором нажимаю на автопилоте нужный shift.

2. С vim такая же история. Если отвлекался, то всегда сначала Esc, а потом нужная комбинаций.


В целом, я не то, чтобы очень много комбинаций использую, но они явно делают мою жизнь проще. Стрелочки отстой по сравнению с hjkl :)

Там еще и хоткеи забиты исходя из весьма специфической клавиатуры, ага. А что происходит с эргономикой при смене раскладки на какой-нибудь dvorak...

Да в общем-то решается все той же настройкой и фактически не привязано к конкретному редактору - как хоткеи VS Code чуствуют себя на Двораке, например?

JB'шные нормально - но я за "анатомическую эффективность" и не топлю ) - а вот когда hjkl у тебя по всей клаве разбегаются да еще по всем трем рядам под две руки - тут бИда.

JB'шные нормально - но я за "анатомическую эффективность" и не топлю

Я не очень шарю за клавиатуры и не очень понимаю что этом могло бы значить.

Тут скорее вопрос за софтварные лейауты/маппинги. Кнопки-то всё равно по идее qwerty прилетают. CTRL+C/CTRL+V по тому же принципу должны работать на Двораке, если это конечно не какаие-то особенные клавы.

Кайфующий от своей работы всегда будет компетентнее того, кто не кайфует.
Стремящийся к минимализму и эффективности разработчик компетентнее не стремящегося.

У вас неправильно поставленная априори. То есть по вашему кайфует только тот, кто использует vim и никак иначе.
Смею предположить, что компетентнее не тот, кто стремиться к минимализму, а кто стремиться к результативной эффективности. Этак можно было бы сказать, что пользователь ведра возле колодца компетентнее владельца насоса.

кайфует только тот, кто использует vim и никак иначе.

Нет, кайфует тот, кому интересно пробовать разные инструменты и их комбинации, а не зацикливается на vscode/idea.

Этак можно было бы сказать, что пользователь ведра возле колодца компетентнее владельца насоса.

Нельзя так сказать. Минимализм не подразумевает луддитство. В примере с ведром и насосом в первом случае набор инструментов и действий (ведро, веревка/цепь, коромысло) больше, чем во втором (насос и шланг), как и количество необходимых действий.

За сайт спасибо, полезный. И за анекдот тоже, хороший, мудрый.

Как ни крути, что бы свою ноту найти, нужно пройтись по всем октавам и полутонам.

Ищущий и пробующий новые инструменты будет компетентнее не ищущего.

Я бы не стал называть vim новым инструментом, не фанаты ли vim цепляются за прошлое и пытаются своим карго-культом компенсировать реальные скилы? Против vim ничего не имею, иногда надо, инструмент полезный. Но делать его единственным инструментом? нет, спасибо

фанаты ли vim цепляются за прошлое и пытаются своим карго-культом компенсировать реальные скилы

Большинство пользователей vim умеют пользоваться современными ide, только если это не редко кодящие ссадины (как нынче модно называть - devops).

Мало кто из пользователей современных ide сможет эффективно программировать в vim. Однако накидываются на мнение о редакторе, выраженное в виде статьи именно последние.

Так кто выходит фанат, за что-то цепляющийся и пытающийся компенсировать отсутствие определенных скилов? :)

В vim очень хорошо с автоматизацией. Поэтому для конфигов это очень хороший инструмент. А для программирования - можно, конечно, если обмазать как следует плугинами. Подсветка синтаксиса и скобок - вот и все что он умеет из коробки. И стартует быстро ;)

Вот кмк как раз для конфигов оно оч не оч в плане автоматизации. В смысле, если ты кодишь на js - тебе ничего кроме синтаксиса этого самого js и не надо, а вот конфиг апача, nginx'а, netplan'а (мм-ммм, пробельчики!), кондовый ini, новомодный toml, а рядом аппликушники нажысонили автоматизировать - 2Ъ

если ты кодишь на js - тебе ничего кроме синтаксиса этого самого js и не надо

Сильное заявление. Подсветка ошибок, навигация, автодополнение, рефакторинг и дебагер - весьма полезные вещи, на мой взгляд.

Об этом ниже уже говорил - есть IDE, есть "редактор кода", есть "текстовый редактор" - где-то они пересекаются, где-то одно можно приблизить к другому - но в общем-то это разные вещи. Тут я именно о функциональности "редактора (кода)" говорил

ещё помню, в конце 90-начале 2000х, напрямую, без м4 редактировать sendmail, в лоб, все эти ; и весьма через дупу описываемые транспорты.

интересно, как там синтаксис подсветить - там всё очень неоднозначно.

Мало кто из пользователей современных ide сможет эффективно программировать в vim

Ну так даже пользователи vim не смогут это делать эффективно, потому что ide это несколько больше чем текстовый редактор, а программирование это не только набор текста. И скорость его набора это вообще последнее от чего зависит эффективность.

пользователи vim не смогут это делать эффективно

Весьма опрометчивое заявление.

скорость его набора это вообще последнее от чего зависит эффективность

Скорость набора возможно, скорость редактирования и отладки далеко не последнее.

Чего такого умеет современная ide, чего нельзя сделать из vim?

скорость редактирования и отладки далеко не последнее

Ну так в любой большой IDE средства для этого куда мощнее

Показать всю иерархию классов для текущего класса одной кнопкой.

Показать SQL запрос при отладки SQLAlchemy.

Локальная история изменения файла.

Извините, но локальная история изменений в виме отличная. Вот плагин для визуализации дерева undo/redo: https://github.com/simnalamburt/vim-mundo.

Про остальное не знаю, не требовалось. Иерархия классов скорее всего решается с помощью языкового сервера.

Вот так нынче выглядит отличная история изменений.

Просто тыкаешь стрелочку и тебе актуальный файл правит.

А еще там прокрутка есть. Удобная.

Видите как там удобно слайдеры ползут справа?

Зачем мне глаза об дифф файлы ломать?

+ К тому я бегло глянул и не увидел "External Change" как в продуктах Jetbrains

У нас с вами разные задачи, возможно. Мне от истории локальных изменений нужно, в основном, именно дерево, чтобы видеть случаи, когда я что-то писал, потом отменил и написал новое, а очень хочется увидеть состояние до первой отмены. И в дереве это достаточно несложно ищется. Плюс когда я пользуюсь этой фичей, то мне нужно посмотреть на маленькие изменения (буквально пара строк), а не на несколько экранов, так что дифф вообще не напрягает.

Насколько я понимаю механику работы этих плагинов вима, они просто визуализируют то, как вим отслеживает историю изменений файла. Вим из коробки учитывает изменения снаружи (echo >> foo.sh), так что плагины это тоже отображают.

А вот количество слайдеров на скриншоте немножко пугает :)

Посмотрел, как выглядит локальная история в вскоде. Там есть одна классная штука, которую было бы круто интегрировать в undo tree: туда подтягивается история из гита, поэтому некоторые версии имеют описание, а не только номер и время. Но при этом "время и номер" куда лучше, чем простыня из "Fine saved" :)
Вот пост на реддите, где есть скриншот или немного обсуждения.

Ох. Что умеет делать мерседес, чего нельзя сделать в жигулях? "Но есть нюанс"

vim не умеет примитивнейшей вещи: найти и заменить в файле

строку с произвольным содержимым, заранее на нее не смотря и не анализируя, на другую!

Нужно экранировать всякое попадающееся внутри cтроки.

Если скажете, что я не прав - покажите, как именно в vim это делать. Условие - произвольная строка из печатных символов ASCII.

не, ну такие банальные вещи офк он умеет и относительно просто там обычный sed синтаксис, на сколько это удобно и интутивно вопрос конечно спорный.

но вот делать реально полезные вещи которые должна уметь ide такие как поменять сигнатуру функции, переименовать хедер в плюсовом проекте, отобразить все имплементации или найти специализации шаблонов. Я даже представить себе не могу какими плагинами нужно обмазаться что б иметь хотя бы пародию на это. Это не говоря уж про стек трейсы, профилирование и прочее.

coc.nvim + language server вполне справляются с переименованием метода/функции, нахождением мест, где этот метод/функция используется. Плюсом идёт автодополнение и возможность посмотреть справку на функцию или метод или только её сигнатуру. Но я хз, со всеми ли языками это нормально работает, я только с хаскелем и сями пробовал.

Можете пожалуйста, отрисовать стурутуру бд со связями

Посмотреть как сгенерируется uml код в картинку

А потом отправить все это в кубернетис, подключиться к поду и посмотреть логи?

Более того, во время набора ведь еще думать приходится, а не с листа готовое набирать.

Создан был как раз для управления компьютеров и редактирования текстов - что и есть программирование.

А я думал там думать надо, а редактирование текста- это побочный эффект А тут вот как..

Это, пардону прошу - "заклинания" какие-то. "Кайфующий от работы" неофит априори компетентней специалиста, которого давно-и-все-задолбало, ага. Неофитам понравится.

Удовольствие от работы очень условно коррелирует со способностью качественно её выполнять, увы.

Вера не требует доказательсттв и объяснение, This is the Way ))

Ради чего все эти приседания с настройкой и запоминание сотен хоткеев...

Вот тут вы про какой редактор? VS Code? 8))

В Vim если "выучить" пару комбинаций, легко догадаться как использовать все остальные и их не нужно учить, потому что они изначально придуманы очевидными и эргономичными.

Для примера:
1) как удалить строку: dd (в VS емнип: Crtl+Shift+K)
2) как удалить слово: dw
3) как удалить часть строки от курсора и до конца строки: d$
4) как удалить часть строки от курсора и до начала строки: d^
5) как удалить несколько строк: а вот не скажу, сами догадайтесь 8))
... для несведующего человека это конечно похоже на магию, но постичь ее достаточно легко.

Почему vim, а не emacs?

Почему бы и нет? 8)

  1. как удалить слово: dw

Не слово, а символы от курсора и до ближайшего разделителя. Если хочется удалить несколько слов.. лучше не пытаться, не угадаете ;)

легко догадаться как использовать все остальные

Не так легко как кажется ;)

dp - что удаляет, как вы думаете?

Не слово, а символы от курсора и до ближайшего разделителя

Тут да, маху дал... 8)
PS кстати очевидное 3dw вполне себе работает

dp - что удаляет, как вы думаете?

Погуглил, а оно точно к Vim относится, а не к Vimdiff? ;o)

В целом я имел ввиду частоупотребимые операции, они достаточно очевиды.

Погуглил, а оно точно к Vim относится, а не к Vimdiff? ;o)

realpath $(which vimdiff) 
/usr/bin/vim.gtk3

Выглядит как утка, и крякает внутри себя тоже как утка ;)

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

Например, жмёт Ctrl+U, рассчитывая проскроллить текст, а вместо этого теряет целый абзац набранного, причём без возможности откатить это командой Undo. Или жмёт zz, а vim просто берёт и молча закрывается.

И на такие грабли здесь наступают регулярно, потому что эффект большинства хоткеев здесь зависит от контекста, метарежима и кучи других факторов.

Как объяснить слепому, что его размышления о цвете не верны?

Очень часто сталкиваюсь с идиотскими аргументами, поясняющими как мне трудно и неудобно работать с Vim, с консолью, с linux.

Мы как то с другом поспорили, кто быстрее примонтирует образ dvd с рабочего стола. Я с помощью mount, консоли и всего остального или он с помощью Demon Tools. Он справился секунд за 10, перетащив файл на ярлык программы. А потом долго ругался и спорил. Так как я по его мнению должен был открыть терминал, напечатать там cd и полный путь до рабочего стола. Буквами напечатать, а не протапать. Затем напечатать mount и т.д. Но ни как не два раза жмякнуть по файлу.

Так к чему я это. Вот небольшое FAQ глупых аргументов:

Набирать cd чтобы попасть в необходимую папку долго.

Во первых нет, не долго.

Во вторых я сразу открываю терминал в необходимом каталоге.

В linux очень длинные команды в терминале

Да такая проблема есть. Например чтобы набрать

scanimage --device-name xerox_mfp:libusb:003:002 --format=png -o сведетельство.png

мне пришлось нажать 18 клавиш, угадайте куда я потратил 13 из них.

Перемещаться по тексту в Vim используя hjkl не удобно постоянно путаешься, стрелки лучше

Я тоже путаюсь, поэтому пользуюсь стрелками

Невозможно скопировать текст с Vim подключенного по ssh мышкой. Вместо этого vim переходит в режим выделения

Я не включаю выделения мышью в vim на сервере.

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

Режим написан в левом нижнем углу программы и выделен цветом. За редким исключением vim всегда находится в командном режиме. После того как отвлекли ESC прожимается автоматом.

Например, жмёт Ctrl+U, рассчитывая проскроллить текст, а вместо этого теряет целый абзац набранного, причём без возможности откатить это командой Undo. Или жмёт zz, а vim просто берёт и молча закрывается.

Эээээ а зачем этот замечательный человек нажимает эти странные клавиши? И почему у него закрывается vim по zz?

Нет, я про нормальную IDE

Мне не нужно рассказывать про базовые команды vim, я им больше 10 лет пользуюсь. Но за кой ляд из буханки хлеба делать троллейбус мне совершенно не понятно.

"Очевидны и эргономичны"

dd почему не ds?

И когда это удаление строк вообще было проблемой хоть в каком то редакторе? Нафига мне знать эти команды? Я сейчас пишу комментарий и удаляю часть текста, мне для этого нужно считать сколько слов мне нужно удалить? Что если мне нужно удалить не символы и "слова", а функцию, if или цикл, мне считать разницу между началом и концом? а если оно не влазит в 1 экран задолбливать клавишу `d`? И ещё не забыть переключится в правильный режим.

Ни чего более убогого и отвратительного чем удаление текста в vim я вообще не встречал нужно быть отбитым на всю тыковку чтоб защищать это уродство.

Почему ни один другой редактор текста ни кому в голову не придёт защищать словами: "а у нас тут очень удобные и эргономичные команды для удаления строк"? это же абсурд полнейший, в абсолютно любом редакторе я их просто беру и удаляю не задумываясь ни о количестве символов ни о количестве строк которые мне нужно удалить, ни тем более о командах для того чтоб это сделать.

| Почему бы и нет? 8)

Если это все аргументы за, то получается это очередная хипстерская дурь которая не лучше и не удобнее, а все приседания только для того чтоб "выделится" и прокричать о своей "нетаковости", вместо того чтоб просто делать качественно свою работу

И когда это удаление строк вообще было проблемой хоть в каком то редакторе?

Может в далеких 80-х это было проблемой ;) Вместе с тупым терминалом и 300 бод каналом ;)

Ни чего более убогого и отвратительного чем удаление текста в vim я
вообще не встречал нужно быть отбитым на всю тыковку чтоб защищать это
уродство.

Зря, там много способов удаления.

Что если мне нужно удалить не символы и "слова", а функцию

В начало функции
на открывающуюся скобку
V (или v, смотря как хочется выделить) - начать выделение
% - найти парную скобку
d

:)

сложно как-то. Не надо ничего выделять

d% --- удалить от текущей скобки до парной (т.е. можно и на закрывающейся скобке стоять и на открывающейся)

Прыгнуть в начало функции - [m и удалить текст до начала следующей функции - d]m.

Прикольно. И очевидно ;) Дай думаю загуглю, vim [ command. Агащаз. Это как таблица неправильных глаголов. Только выучить.

Я думаю, если посмотреть, какие сочетания клавиш используются в других распространенных редакторах/IDE/программах, и отбросить самые "очевидные" типа CTRL-C/CTRL-V - то там мы тоже найдем много не самого очевидного или даже совсем не очевидного. Более того, полагаю, мы встретимся с тем, что 1) не найдем никакой системы в подборе клавиатурных комбинаций; 2) не обнаружим возможности сочетать команды для выполнения действий с командами перемещения, как это позволяет делать vim. И, наконец, мы обнаружим, что для одних и тех же действий в разных программах сочетания клавиш могут быть совершенно различными.

Во всех программах хоткеи продублированы в менюшках. Даже в nano. Можно не учить специально, а просто находить в меню. С vim так нельзя.Только выучить.

Давайте все же уточним, что находить в менюшках можно команды, которые требуется выполнить, и заодно уж посмотреть какие горячие клавиши с ними сопоставлены. Если Вы захотите пользоваться этими горячими клавишами, все равно придется их выучить. В этом смысле разницы мало между такими программами и vim - только в том, каким путем Вы отыскиваете сочетания клавиш для запоминания. Если же Вы хотите пользоваться программой ничего не запоминая, а пользуясь средствами GUI и мышью, тогда зачем вообще обсуждать vim в этом ключе? Ясно, что он не для этого задумывался.

Если же Вы хотите пользоваться программой ничего не запоминая

Ну, например, некоторыми функциями я пользуюсь часто (скопировать-вырезать-вставить) - я их запомнил, некоторыми редко (рефакторинг) - нахожу в меню и пользуюсь.

Если это vim - то, чего не помню - воспользоваться не смогу. Нет, конечно можно погуглить, можно полистать vimtutor и таки найти, но в любой IDE это делается в 3 щелчка мыши.

Я в целом с Вами согласен, что, имея GUI, проще найти команду, если не знаешь нужного сочетания клавиш. Но этот вопрос не лежит в плоскости обсуждения "очевидности-неочевидности" сочетаний в vim или в других программах.

Кстати, если уж говорить о поиске команд, то мне по сравнению с классическими GUI-решениями, основанными на кнопках, панелях и менюшках, больше нравится подход с использованием палитры команд и нечеткого поиска. Искать команды путем набор фрагментов ключевых слов, как по мне, гораздо проще, чем искать их в лабиринтах вложенных меню или пытаясь найти и попасть в нужную кнопку на панели инструментов.

Нечеткий поиск может применяться в том числе и в vim (плагин fzf.vim). Я, в свою очередь, использую VS Code в сочетании с расширением VSCodeVim. Кроме того, с удовольствием отмечаю, что концепция палитры команд проникает в традиционные GUI приложения. В частности, в приложения KDE (Dolphin, Konsole и др.).

VScode приветствует вас нечетким поиском команд!

As for me - основной вопрос - что именно в процессе "индустриального программирования" занимает больше всего времени? Точно не "набор текста" - с современным intelli sence у JB'шников почти 2\3 букАвок автодополнением получены. И, скорее всего - даже не навигация по тексту - с учетом современных требований к разбивке кода, размеру функций и т.п. стайл гайдам.

У меня - скорее навигация _по проекту_ с укладыванием разновсяческих взаимосвязей в голове, плюс пожалуй отладка - но это скорее я "кривой" и в нормальную "кодопись" не умею - и вот тут vi(m) предполагаю, поможет "никак" - ну и вот нахрена оно?

ну и вот нахрена оно?

Дебаг на проде

даже для этого есть gdb-server и без необходимости втаскивать отладочные символы и исходники на прод

Эм. Кода? Вот ни разу не было. Конфигов надевопёсил в свое время преизрядно - особенно, когда всякий энсибль или еще какой ЦыДы пайплайн нафиговертил - тут да, тут VIM норм так выручал - особенно если ничего окромя него и нету ). А вот именно при работе с кодом... Не, ни разу.

Ну вообще да... Кроме подсветки синтаксиса, когда с большим количеством исходников работаешь еще полезно поиск по всем файлам в папке. Причем, чтобы сразу тут же и все совпадения в список и чтобы ткнул и сразу перешел в нужное место.

Еще чтобы outline был и много чего еще...

1) как удалить строку...

Выделить тачем (на маках, просто, восхитительный тач) и удалить!

Можно еще shift->стрелочкавправо-стрелочкавправо-стрелочкавправо-стрелочкавправо...стрелочкавправо-delete, но зачем?

Как бы "восхитителен" ни был тач на маке (ну такое себе - огрызок клавиатуры все-равно никуда не годится, а значит тащим внешнюю с нормальными кнопками, без тача), ничего эффективнее мыши все-равно не придумали.

Сферический макбук в ваккуме, кстати, тоже своего рода vim. Например, там нет кнопки home, а значит способа одной кнопкой попасть в конец строки просто не существует. Почему-то маковод должен страдать и использовать 2-3 кнопочные комбинации там, где виндоуз-юзер использует однокнопочные - никогда этого не понимал, но наверное это так же элитарно как писать esc-3dd вместо shift-down-down-down-del.

Home - Shift+down - BS по мне удобнее мыши. Та вечно пытается что-то не то зацепить. Если только пол документа грохнуть надо.

Хозяйке за заметку: чтобы выделить одну строчку в IDE, нужно просто нажать слева от текста, на "поле" (том месте, где пишется номер строки, если зачем-то включен). Home-shift-down тоже годный способ, конечно, выбирается по удобству в конкретный момент. (Там есть еще нюанс, что home нужно жать два раза, чтобы попасть именно в начало строки).

А еще двойной, тройной клик!
По началу тоже страдал без этих кнопок, но с макбуковским тачем, когда руки не переносишь с клавы на мышь, даже стрелки не нужны =) собствено ими и не пользуюсь почти.

как удалить строку: dd (в VS емнип: Crtl+Shift+K)

А разве не Ctrl+Y?

Весь этот кошмар реально на клавиатуре набирать приходится?

Если опираться на мой опыт, то самое главное преимущество вима (или емакса) - его универсальность. Он легковесный и есть практически везде, либо его можно поставить относительно малой кровью. Он работает в терминале, а значит его можно использовать не только через SSH, но и на встраиваемых системах, к которым ты подключаешься через UART. Он кушает настолько мало ресурсов, что если мне понадобится что-то поредактировать на каких-нибудь странных раритетных железках - он будет там работать.

Я сейчас восстанавливаю Tadpole SPARCbook - это один из самых редких ноутов в мире, как следует из названия - работающий на спарке. Частота процессора 120MHz, объем памяти - 32Mb. Я запустил на нем современную NetBSD, смог прямо на нем же исправить драйвер иксов с помощью вима, и собрать. Надо ли говорить, что VS Code не запустился бы там примерно никогда?

Любой обычный текстовый редактор занимает немного места и легко ставится.

Разговор-то был за VS Code.

Разница в том, что если ты привык к vim/emacs, то у тебя для всего один инструмент - и для конфигов, и для кода. Не надо вырабатывать разные привычки для разных редакторов. Унификация.

Ставите любой редактор со стандартными клавиатурными сокращениями (т.е. любой кроме vim/emacs) и правите конфиги комфортным образом.

есть практически везде

В этом и проблема. Он есть везде, но везде разный. Если какой-нибудь :q! поддерживается без вопросов, то более экзотические комбинации то есть, то нет. Потому что где то есть только vi, где-то полноценный vim, где-то vim который из busybox, где-то одна из говносборок, и все они имеют различия.

Поэтому на чужих машинах только nano - он искаропки всегда один и тот же, разве что цвета подкручивают в фирменные.

Базовый вим (если именно вим) везде одинаковый. Все основные команды для работы с текстом одинаковые. А там, где обычно есть только vi, нано уже нет.

Только если пытаться запустить Vim на удаленном терминале, то сразу лишаешься всей своей привычной обвязки в виде плагинов с кастомизацией и прочими свистоперделками. VS Code запускать на удаленной машине не нужно вообще. Достаточно из VS Code удаленно открыть через ssh любой файл с удаленной машины, и получишь его в своей родной среде разработки со всеми родными настройками.

вим точно так же может работать.

Локально открывать удаленный файл? Коробочный Vim? Покажите.

Ну, ок, можно обвешаться дополнительными командами и заставить Vim открывать на удаленном сервере один конкретный файл, указав к нему полный путь. Захочешь найти и отредактировать другой файл по заранее неизвестному пути - нужно отдельно идти на сервер, искать там этот файл и передавать полный путь в новый вызов Vim. А из VS Code можно просто открыть подключение с полноценной навигацией к удаленной машине и перемещаться по дереву каталогов с файлами , как на локальной системе. Можно, например, просто открыть директорию с проектом и открывать оттуда любые файлы простым переключением одним кликом, не вводя никакие пути.

если вы думаете, что sshfs вне vscode и в vscode имеет какие-то значительные различия, то позвольте усомниться

ps: только что проверил, указание директории в виме тоже прекрасно работает.

И без пунктов 1 и 2 тоже работает ;)

А из VS Code можно просто открыть подключение и

…закрыть потому что нет прав на запись ~/.vscode-server или недостаточно места на диске

Не к тому что vscode не работает, а к тому, что за удобство платим ограничениями, которые лично у меня уже не один раз стреляли

Или если дистрибутив без glib (как то так). Типа alpine.

Я для себя решил эту проблему крайне просто: использую только функции изкоробочного вима + конфиг. Закинуть конфиг дело одной минуты, да и то не всегда нужно. А вот VS Code перед UARTом спасует, как мне кажется. Поправьте, если не прав.

По большей части, конечно, справедливо, но можно много всяких примеров привести этих самых "абстракций", которые скрывают современные IDE, взять хотя бы взаимодействие с LSP, конфиги для разных языков, линтеры и форматирование кода. Все это работает почти из коробки в vscode, при этом "как оно работает" большинству непонятно. Тут можно возразить, мол, кому вообще нужны это знать? Ну, мне вот, например, интересно.

И как же vim в этом изучении "абстракций" помогает и уж тем более как впринципе это помогает в работе? В чем его принципиальное отличие от любых других текстовых редакторов? Ни кто из этих свидетелей vim не идёт писать очередной клиент lsp и парсер конфигов под "себя", ровно так же как во всех других редакторах берут и ставят готовые плагины только с большим гемороем. А то и просто берут готовые сборки.

Для того чтоб узнать как ползать не обязательно стрелять себе в ноги.

У меня в neovim настроена работа с lsp, однако я всё равно не в курсе, как это всё работает. Для настройки этого знать не нужно от слова совсем. Отличие от ide в том, что нужно десяток строк на lua написать, чтобы оно заработало.

Хорошо понимаю людей, у которых vim/emacs был первым редактором, привычка и память рук - страшная штука, поэтому например у меня стоит Dos Navigator (естественно, не тот самый, что под Дос, а "современный" порт 2002 года). Мне тупо удобно и привычно, я делаю всякие удобные вещи не приходя в создание (Как тебе такое, Илон Маск, я могу "удалить" файл(ы) из панели, нажав ctrl-del, при этом он просто пропадет из панели, а не удалится на самом деле. И еще 100 подобных трюков, чтобы быстро и эффективно работать с файлами в панели)

"Нет пути", чтобы кому-то было удобнее пользоваться Vim, если он освоил его не первым. Зато вкус элитарности, понты-дороже-денег и вот это все - бесценно.

Ради чего 

Ради просмотров. Одна из хайповых тем, вим против всех, линух против всех, все против всех. Каменты постятся, просмотры крутятся, бабосы мутятся. Такова реальность, или корпораты, или переводы, или капитаны очевидность.

2010: маленький интернет? Серьезно? Да в нем было мало видосиков, но в этом была его прелесть.

Личное мнение: я считаю macOS также дистрибутивом Linux

Ну и дурак Вы не правы, сударь! Впрочем, спорить не буду.

По теме статьи - познакомьтесь с qutebrowser (или chromium с аналогами) и с i3wm/sway (ну или возьмите другой тайлинговый WM с vim-binding из коробки). zsh тоже умеет в vim-mode, но я уверен, что вы и так это знали.

и то верно, очепятался.

Тоже люблю NewVim и иногда пользуюсь им для фана.

Однако основная мощь раскрывается после освоения метода слепой печати.

Осталось, по классике, добавить: жизнь наладилась, коллеги стали уважать, здоровье улучшилось, женщины стали обращать на меня внимание :)

Хоть убейте, не нахожу никакой связи между двухлетним задрачиванием хоткеев редактора и "тонкой настройкой под себя", с компетенциями в области разработки. Скорее, я бы сказал, что два года было потрачено не туда. А если редактор надо учить годы, это тотальный фейл для любого инструмента.

В хорошем IDE полезно знать совсем немножко хоткеев, а остальное должно очень быстро находиться, да и лучше если IDE сама будет делать всю рутину, подсказывать, подсвечивать, хинты всякие. Если человек начинает обслуживать инструмент, это маразм, однозначно свернули не туда.

Ничего против Vim не имею, но религиозности не понимаю. Думал, эти времена уже прошли. При чём давно.

если редактор надо учить годы, это тотальный фейл для любого инструмента.

Ну, я Visual Studio (не Code) изучал годами, и всё было на пользу.

А так да, я вимом тоже пользовался, и плагины ставил, и продвинутые хоткеи изучал. Но я не верю, что вим в принципе может обеспечить всю функциональность VS или Rider, которую я реально использую в работе.

От IDE в первую очередь ждёшь максимальной помощи в разработке ПО, а не способности не трогая мышку генерировать 100500 строк кода в секунду. Пусть их генерирует IDE, кодогенерация, и помогает поддерживать в консистентном состоянии. Нужно, чтобы не только выполнялись куча проверок и задалбывало программиста исправлять ошибки -- пусть IDE сам их исправляет.

И при этом IDE не должна требовать от программиста изучения тонны талмудов и заучивания огромного количества возможностей и хоткеев. Это всё очень плохо, так как программист должен думать о результате, о программе, никакой промежуточный инструмент не должен засирать программисту голову, отнимать драгоценное время и силы.

И такие IDE есть. Я использую JetBrains, он это всё делает, и никто не сможет меня склонить ни к какому емаксу или виму, потому что мне совершенно не нужен редактор. Мне нужен инструмент для разработки. Кто хочет быть code monkey? Я не хочу.

Ничего против Vim не имею, но религиозности не понимаю. Думал, эти времена уже прошли. При чём давно.

Вы видимо давно на опеннете не были :)

а там до сих пор perl-овщики линчуют всех подряд? лет 15 там не был ;)

Первым делом на новых серверах делаю:

apt update && apt install nano -y

И хер с ним, что это не true way, зато удобно.

Проходили. :-) А потом случайная запятая, точка, не тот символ впопыхах, CTRL-x - y, systemctl restart ... и что-то оно упало.. Ищем до утра)) Вместо режимов редактирования и view в vi, vim, neovim. Особенно в продакшене. Был очень больной опыт не только у меня)

В vim нельзя случайно ошибиться и сделать не то что хотелось?

Можно, конечно, но там проще контролировать процесс внедрения изменения.

Ну да.. нажимаешь SHIFT INS не переключившись в правильный режим, и происходит магия ;)

Esc и u и всё на месте опять))

Можно подумать, в других редакторах нет undo.

Так отуда хрен выйдешь! а пока не выйдешь не страшно =)

Вероятность нафакапить правда несколько меньше ибо по дефолту открывается в режиме чтения. С nano я на эти грабли налетал

использую cat чтоб не нафакапить в nano =)

Ну да. Есть. Но вы уверены, что сейчас редактор и просмотрщик все еще должны быть разными инструментами? Вроде как "посмотрели - при необходимости поправили" вполне понятный workflow для инструмента.

Человек cat использует. О каком редактировании речь? Из less можно вызвать редактор по нажатию v.

Нивапрос. Вы готовы сказать, что это удобней? Вымучили кошку - посмотрели - о! Ошибко. Открыли редактор, поправили. Или о! Нет ошибко. Пошли смотреть следующий файл.

Вместо того, чтобы "открыли файл - ошибко - поправили, нет ошибко - в том же редакторе открыли другой файл".

Первый вопрос - а что и зачем вы делаете "на новых серверах"? Ну вот буквально?

А что делаете, если этот новый сервер чуть-чуть, самую капельку, малость - вот не ваш? Особенно весело, если проделывать это надо в процессе устранения факапа...

Вы на правильном пути. Пройдёт ещё лет 5 и вы, уже просвятлённый и познавший Vi, а возможно также и Emacs, и тогда вы вернётесь в VS Code, осознав что он просто удобнее.

Сделает ли меня более компетентным разработчиком использование Vim?
— Да, я могу это гарантировать

Каким образом? За счет того, что Вы потратили месяцы и годы на вылизывание текстового редактора, вместо того чтобы изучать и совершенствоваться в своей предметной области?

На многих коммутаторах, маршрутизаторах операторского класса и прочих сопутствующих железяках вендоры не разрешают устанавливать сторонние утилиты. Такой коммутатор способен без перезагрузок непрерывно работать 10 лет, всякая самодеятельность может нарушить эту стабильную работу. Тем более к интернету они не подключены, даже если бы и надо было что-то туда установить, то это не одна команда в терминале. Операционная система на них - реального времени, не обязательно Linux, где-то это VXWorks, где-то какой-то другой сертифицированный Unix. В любом случае работа в терминале не отличается от Linux, команды (утилиты) те же самые, но набор их ограничен. Если где-то есть nano - шикарно. Но где-то нет даже cat, приходится просматривать файлы командой more. Из редакторов только Vi или Vim есть везде без исключений, так что иногда проще поправить конфиг, запустив Vi или Vim. У меня был блокнотик, в котором основные команды Vi были записаны, в голове я их никогда не держал и сейчас помню только что hjkl это курсор. FTP есть на всех железках, можно скачать файл себе, поправить и залить обратно, но бывало быстрее и проще зайти по telnet или ssh и открыть vi или vim.

На многих коммутаторах, маршрутизаторах операторского класса и прочих сопутствующих железяках вендоры не разрешают устанавливать сторонние утилиты.

Ну потому что там обычно все есть что надо. Да и в каком месте там вим?

Увы, увы - раньше можно было говорить что "vi есть везде!" - сейчас это уже не так. ЕМНИП, в дефолтных минималках на debian\ubuntu уже только nano. Впрочем, может и путаю - но уже натыкался на то, что nano - есть, vi(m) нет. Эпоха таки меняется :(

В последнем debian bookworm в минимальной конфигурации есть vi. Про убунту не знаю. А вот недавно пробовал новую версию nixos, в ней по дефолту vi нету, а nano есть. При этом в конфигурационном файле vim есть, но закоментирован, как пример того, что надо написать написать в конфиге, чтобы пакет появился в системе. (Nixos так работает, там не вызывается команда apt-get install, а редактируется конфигурационный файл, после чего система сама все устанавливает)

даже в одном из лидеров 90-х, среде разработки watcom, был редактор в формате vim.

уже и забыл про этого динозавра!

я недавно ставил openwatcom 2 версии, чтобы досовую прикладуху простенькую собрать. всё никак не соберусь написать про различные эксперименты над 286-ой и бук vist fma86t (166mmx, 16mb, скорее всего clevo)

Если вы не в курсе, VS Code спокойно умеет работать через ssh. Никуда ничего на удаленную машину ставить не нужно.

Да, потому что он сам чо-то там ставит, пропихивая куда-то в ~/.чегототам/... . И если у него не получается (например удалённая машина это какой-нить древний центос и в ней нет нужных тулов или они работают не так как хочется вскоду), то доставайте бубен.

Ну да. И смартфон с тачскрином - фигня, ибо не позволяет человеку вслепую, в темноте, с завязанными руками, отрезанными ушами и вырванным языком отвечать на sms...

Когда я попытался в среде, где нет выхода в инет, зайти из VSC по ssh на линукс-машину, то внезапно оказалось, что он не может соединиться. Расследование показало, что он пытается ставить на хост собственный ssh, штатный его почему-то не устраивал. А скачать без интернета не может. Пришлось подсовывать вручную.

Да. Ей нужна прослойка code-server. Но можно было бы обойтись через плагин для ssh (не помню как называется). Но про удалённый дебаг можно забыть (ну или как то извратиться).

А ведь за два года можно было столько реально полезных знаний приобрести, чтобы стать компетентным инженером, а не компетентным в инженером vim.

Был у меня знакомый на прошлой работе, он увлекался сборкой линукса, писал "как настоящий программист" в vim, всех остальных считал быдлокодерами...но почему-то он занимался на работе фронтендом. В общем через какое-то время ему пришлось уйти из компании, потому что свои непосредственные задачи он делал медленно, да и по софтам был тяжёлый человек.

И ведь эти персонажи убеждены что вим это лучший редактор кода и с ним они работают супер эффективно не то что все эти "быдло кодеры" со своими "тормозными" ide. А то что у "нормального" разработчика уходит пару минут на то что б баг пофиксить просто открыв дамп и посмотрев где произошёл дедлок условный, эти будут устанавливать очередной плагин пол века, потом настраивать его чтоб по итогу удалить одну строку которые они в своём "навороченном" редкторе пол дня искали, попутно рассказывая всем как "удобно и быстро" они это сделали нажав dd. А благодаря подобным статьям их же ещё и фиг переубедишь в этой глупости.

Обожаю vim это просто какое то волшебство, когда текст словно по мановению мысли трансформируется а каретка просто летает по строчкам. Но к сожалению мой инструментарий кроме редактора кода состоит из гугла, stackoferflow, хабра итп. Работая с веб, периодически хочется запустить и посмотреть в браузере результат своего труда. Все это заставляет постоянно хвататься за мышку и вся магия рассеивается. cry

когда текст словно по мановению мысли трансформируется а каретка просто летает по строчкам

Смотрел скринкасты пользователей vim'а, что-то никакой особой магии не видно. Всякие jjjjjjjjjjjjjjj и kkkkkkkkkkk сплошь и рядом. Постоянные EscEscEsc, наверно чтобы не запоминать режим. А курсор летает в основном между терминалом, хелпом и текстом программы.

каретка просто летает по строчкам

Там это, мониторы изобрели. Отложите уже телетайп.

А почему бы просто не поставить аддоны к vscode/idea/etc на имитацию Vim и не мучаться?

По своему опыту: эти плагины глючные и не отзывчивые, так как пытаются смапить команды вима в команды своего редактора и это не всегда хорошо удаётся. При этом я для себя не нашёл ни в vscode, ни в CLion каких-то крутых фич, которых мне в виме не хватает.

Точно смотрел на него. Скорее всего тоже что-то не понравилось либо проблемы с настройкой возникли.

В оригинальном Neovim вообще ничего нет, даже дерева файлов слева, для всего нужен плагин и прописанные настройки в конфиге.

Так и VSCode без плагинов невозможно пользоваться. Если бы к (Neo)vim не было хорошей экосистемы плагинов, то я бы конечно не рассматривал его как замену IDE.

Прежде всего IDE | Текстовый редактор - это больше про удобство работы, кому-то нравится nano, SublimeText, Atom, VS Code, продукты Jetbrains, vim like редакторы, emacs like редакторы.
С овтетами на вопросы в статье я не согласен, что значит "быть более компетентным", компетентность в чём? Если в работе в редкторе Vim, то тогда и плавец плавая становится более компетентным в плавании.


Статья слишком сильно манипулирует выводами на основе субъективных ощущений автора, знание (когда комфортно себя чувствуешь при работе с ним, а не только знание :q :w :e комманд и режимов) Vim не сделает из вас супер инженера, как и знание VSCode, это всего лишь условные адаптеры для написания текста с дополнительными инструментарием.

Я лично работаю в emacs, использую vscode для удобного исследования кодовой базы в работе (c lsp там нет роблем), helix editor (vim like) для работы с текстом через консоль и стаким зоопарком я привык работать, мне удобно так, от этого я получаю удовольствие.

не-не-не. Прежде всего, IDE, "редактор кода" и "текстовый редактор" разные инструменты, сфокусированные на разных вещах. Местами они пересекаются (Везде можно писать текст, ага), местами одно можно достаточно близко притянуть к другому - но в целом непонимание этой разницы в подобного рода спорах достаточно сильно удручает.

Статья слишком сильно манипулирует выводами на основе субъективных ощущений автора

Она и начинается с дисклеймера о субъективности написанного. Но при этом в самой статье встречаются радикальные заявления о понятии "инженер", что немножко противоречит дисклеймеру.

Рискну схлопотать минусов, но по моему личному времени все автобиографии фанатов VIM, которые используют его как IDE надо начинать с сфразы: "Когда-то меня задушила жаба заплатить денег Jetbrains".

Я решил перейти на Vim. Не потому, что он лучше подходит для моего конкретного рабочего процесса, а потому, что хотел покончить с зависимостью от VS Code.

Напоминает историю использования героина в 20-е годы прошлого века, который применялся в качестве заместительной терапии для больных, страдающих морфиновой и кокаиновой зависимостями.

Если с VS Code перейти на любой другой редактор или IDE особого труда не составит (потому что они все плюс минус похожи), то соскочить с Vim будет гораздо сложнее

У вас первый мем наоборот. Чел на каблуках и желтым хохолком(можно ему электросамокат добавить) должен быть слева и вопить - "как мне выйти из вима". Ну а норм чел справа должен задаваться вопросом, а зачем ему выходить из вима.

На самом деле, единственное, что меня побудило использовать вим это удалёнка, когда я в силу разных причин мог подключиться к компьютеру для разработки только через ssh, а работать-то надо.

Тогда мне и пришлось по-полной начать использовать vim, tmux и прочие консольные ухищрения. Через какое-то время я начал вполне свободно пользоваться страшным Вимом.

В итоге, он не лучше vs-code, или полноценной IDE и без необходимости пользоваться им нет смысла, но и расстраиваться, когда есть только он, тоже не стоит.

мог подключиться к компьютеру для разработки только через ssh

ssh -Y и используй gedit (но должен быть установлен на хосте). Либо sshfs, и редактируй в чём хочешь прямо у себя на компе.

Корпоративный хромбук, где всё это запрещено. Из доступного был только встроенный в хром терминал

Так можно докатиться и до программироввания через `ed`, но зачем об этом людям то рассказывать.

Может быть это не любовь, а стокгольмский синдром?)

Только ed, только хардкор!

Пользуюсь vi с момента выхода 2.2.1-RELEASE и не понимаю, зачем нужны все эти украшательства, которыми насытили vim и neovim. Прелесть vi прежде всего в в том, что для его работы достаточно самого тупого терминала и знание десятка комбинаций. vi + screen - вот выбор джедаев, а не этот ваш vim!

для его работы достаточно самого тупого терминала

Найти тупой терминал - отдельное достижение.

Это не проблема, а данность если вы занимаетесь разработкой "встраиваемой" электроники, где на устройствах памяти не гигабайты и в процессорах не гигагерцы.

Эм. Я эмбеддовкой не занимался - но кто заставляет "разрабатывать" на конечной железке? Remote developement в любой IDE есть - работаешь на локальной машине, запускаешь - хучь в эмуляторе, хучь в ремотной железке, не?

Хучь в ремотной железке за 1000 км даже!

Не пали контору! Командировка - маленький отпуск!

Сейчас как раз куда не ткни пальцем - гигабайты и гигагерцы. Ну, наверное, бывает и такое. Но где найти на рабочей машине тупой терминал, все равно непонятно.

Проблема с разными украшательствами в vim и его прозводных состоит в том, что они требуют специфических настроек терминала для нормальной работы. Когда Вам быстро нужно кодключиться, исправить код, пересобрать и протестировать с неизвестной Вам машины это создает массу проблем с отображением, так как в разных ОС поразному настроены терминалы. Вместо того, что бы быстро решить поставленную задачу Вы начинаете долго и упорно бороться с системой, судорожно гуглить настройки и всячески терять время попусту растрачивая свои нервные клетки.

Если Вы умеете пользоваться редактором vi, компилировать из командной строки с помощью команды make и отлаживать в gdb, то Вы никак не привязаны к конкреной машине и её настройкам. Вы можете разрабатывать и дебажить из любого места и из любой позиции, в любое время дня и ночи - все что вам требуется это терминал с минимальным функционалом. Именно так построена моя работа. Я могу дебажить сложную систему из нескольких устройств находясь в любом месте планеты, был бы ssh.

Если Вы умеете пользоваться редактором vi, компилировать из командной строки с помощью команды make и отлаживать в gdb

То вместо решения поставленной задачи вы начинаете настраивать окружение, с которым вы умеете работать ;)

Оно настроено и поддерживается на сервере разработки централизовано. Т.ю. на одной машине, а не на десятке рабочих мест. Это кстати решает очень серьезную проблему - снимает необходимость администрировать рабочие места разработчиков. Поддерживать на нескольких рабочих машинах десяток кросс-компиляторов с массой библиотек и зависимостей это весьма утомительная задача и она создает массу припонов в самой разработке - отличие в какой нибудь системной библиотеке у двух разрабов может приводить к фиеричным глюкам и потере массы времени на поиск неисправности там где её нет.

Оно настроено и поддерживается на сервере разработки централизовано.

Централизованно можно поддерживать любую конфигурацию. Просто админу лень, и он сказал что будет только vim ;)

На сервере есть много всего, в том числе и emacs. Но я уже описал выше, что когда Вы подключаетесь к серверу с какой нибудь машины в цехе у заказчика, то vim с украшательствами превращается в зло! Приходится делать vim -u NONE

At first I was like:

мне [...] совершенно начхать на постоянные поп-апы Sublime с просьбой купить его

but then:

он «провалился»

На самом деле, сложно сказать, о каком провале идёт речь. Поддержка сообщества фантастическая, разработка плагинов одно удовольствие. Я 99% всех своих повседневных задач делаю в Sublime Text, VS Code запускаю только для работы с Jupyter Notebook (и то DataSpell его почти заменил, если бы не был ещё более тормозным).

А лицензию мне работа купила (вместе с Sublime Merge). Жить нельзя без этих инструментов, стоят своих денег абсолютно.

VSCode обладает уникальной киллер-фичей, которой нет, не было и не будет в vim и его производных: нормальным скроллингом длинных строк!

В VSCode, когда включен перенос длинных строк (например, вы работаете с Markdown-документацией) можно проскроллить экран ровно на одну экранную строчку. Вверх или вниз. И можно быстро проскроллить на целую страницу. При этом скроллится ровно так, как должно - полностью предсказуемо, без прыжка на хрен-знает-сколько линий как в vim, без прыжков курсора в произвольное место...

Любой вимер, когда он видит, как работают в VSCode, долго сидит с отвисшей челюстью - а что, так можно было?! Скроллинг и вправду может быть удобным, чтобы при каждом нажатии "вниз на строку" не надо было заново взглядом отыскивать курсор по всему экрану?!

А точно ли проблема в редакторе, если у вас в кодовой базе одна строчка всю площадь экрана занимает?

Абсолютли!

md, xml-и-его-идейные-наследники, да даже json-ку просмотреть...

Всё перечисленное гораздо удобнее редактировать в отформатированном виде, независимо от редактора.

Боюсь поломать ваш мир неполноценного Vim и крутого VSCode, но попробуйте комбинацию g+jk (можно забиндить куда вам удобно). Ну вот - теперь вы сможете поучать вимером и наслаждаться еще более отвисшей челюстью :)

А в чём поломка-то? Ну да, по самому экрану теперь курсор движется чуть более предсказуемо, по 1 строчке. Но вот мы доходим до последней отображаемой строки - и при нажатии gj у нас опять всплывает случайное число строчек, и надо искать взглядом, куда оно скакнуло.

Прокрутить точно на одну экранную страницу без рандомных скачков курсора оно также не позволяет.

Никогда не требуйте от людей достигать поставленных целей сугубо с помощью вашего любимого инструмента.

Все разработчики обязаны пользоваться Linux. Никаких исключений.

Так как?

Пользоваться Linux? Что за глупости. Как им можно пользоваться? Ведь Linux это просто API, которую использует emacs для взаимодействия с hardware ))

обычно vim используют когда
А) нет ничего другого
Б) это сервер
проще поставить какой нибудь awesome и установить vscode

  1. Существует масса ситуаций, когда надо делать серьёзную разработку, а доступна только текстовая консоль. Когда без дебаггера обойтись очень трудно. И что делать? Nano не поможет, в нем дебаггера нет. Вариантов два: vim и emacs. Преимуществ emacs перед vim мне не известно ни одного, а поскольку vi официально часть POSIX, то уж лучше сразу учить vi/vim.

  2. Действительно, для некоторых vim это религия. Тут, как мне кажется, срабатывает такой фактор: когда человек слишком много времени тратит на какую-то штуку, ему потом не хочется признать себе, что это время можно было бы потратить с большей пользой. И тогда он начинает пользу от этой штуки в своих глазах и в глазах других раздувать. В этом, в частности, на мой взгляд заключается секрет феноменального успеха С/С++ в своё время.

Существует масса ситуаций, когда надо делать серьёзную разработку, а доступна только текстовая консоль.

Можно пример такой ситуации? remote debug даже микроконтроллеры умеют.

Виртуальная машина на AWS или GСР, к которой доступ только через окошко консоли в браузере и ничего больше. Даже SSH сделать нельзя. А мне надо писать довольно сложный код на Питоне.

Ну и как такое дебаггировать?

В реальности я делал одно из двух: либо, в нарушение корпоративной этики и цинично пользуясь лопоухостью DevOps, временно открывал себе SSH, либо сваливал задачу на девочку - любительницу VIM.

"Требуется секретарша, способная писать на perl'е", ага )

Если девочка - так сразу секретарша?

Бывают девочки не только красивые, но и умные.

Я думаю, что это не массовая ситуация, а скорее наоборот. Дебаг на проде?

в нарушение корпоративной этики

Ну, где ssh и где корпоративная этика? Почему они вдруг противоречат друг другу? ;)

Но кмк серьезная разработка в таких условиях не делается.

Ну нельзя мне было никакие порты открывать.

Это был не прод, но РОС (демонстрация работы на среде потенциального покупателя).

А еще бывает - что мышка сломалась и контрол на клаве залип и вообще рука-в-гипсе - как тут без vim? Никак!

Тачскрин - дерьмо, ибо не позволяет человеку вслепую, в темноте, с завязанными руками, отрезанными ушами и вырванным языком отвечать на sms... (c)

Существует масса ситуаций, когда надо делать серьёзную разработку, а доступна только текстовая консоль.

Возможно, что то не так с вашим процессом разработки и искать проблему нужно в другом месте? Например изучением CICD вместо того чтобы идти в продовскую консольку и что то там менять.

В принципе, так оно и было. Там был страшный бардак, делали то одно, то другое, и на CI/CD никто не заморачивался, потому что никак не могли решить, что же собственно они хотят довести до конца. В результате сейчас фирма в процессе закрытия.

Преимуществ emacs перед vim мне не известно

Ну например навигация и в emacs такая же, как в командной строке linux. Навигация, а также хоткеи для редактирования текста. Освоившись с хоткеями емакса можно быстро набирать и редактировать команды в конслои, не выводя руки из основной позиции, не перенося их на стрелочки и доп клавиши типа delete.

zsh предлагает на выбор редактирование в стиле emacs либо vim.

Все разработчики обязаны пользоваться Linux. Никаких исключений.

Дальше можно не читать.

Попробуйте сидя под линуксом писать что-то под винду. Желательно серьезное, что требует обширного использования WinAPI.

И вообще разработка может быть достаточно специфической. Не все пишут на джаве. Бывает и другое, где Линукс вообще не уперся.

Вы описали единственный случай, когда лучше использовать винду. в общем объёме программирования это экзотическое меньшинство: программы только под винду с нативным использованием WinAPI.

Под всё остальное лучше использовать Linux: бэкенды все на линуксе, под андроид лучше писать на линуксе - эмулятор шустрее, а отладка на железе реже глючит. Под контроллеры лучше писать на линуксе - меньше проблем при заливании кода. Причём тут и WSL особо не выручает. Хотя бывают, конечно, контроллеры с проприетарным протоколом и софтом под винду. Но бывает и лысый чёрт с одним рогом.

Далеко не единственный, уж поверьте...

У меня один комп под виндой, второй под линуксом. А пишу я вообще под AS/400.

Так вот, основная работа под виндой таки. Не все что нужно для работы, есть в линуксе.

Например, мне для работы нужен клиент для CheckPointVPN с авторизацией через IndeedKey. Для линукса такого нет в природе. Для RSA токенов есть, для Indeed нет. А без него ни Jira, ни Confluence, ни Bitbucket, ни Artifactory недоступны. И нет доступа к тестовому AS/400 серверу... Кто вынужден под линкусом сидеть, извращаются как могут - винда в виртуалбоксе, в ней VPN клиент с пробросом в линукс сетевых интерфейсов... Троллейбус из буханки.

Не уверен что есть все нужные коммуникации под линукс - Cisco Jabber, RocketChat, Контур Talk (не смотрел просто, может есть что-то, но на глаза не попадалось).

LibreOffice проигрывает при работе с объемными MS документами (а вся документация по задачам в ворде). Особенно, структурированными, с навигацией, таблицами и т.п.

Так что когда нужно много всякого инструментария помимо IDE - чего-то да не найдешь. Или найдешь, но не такое удобное.

Я бы и не против под линукс перейти, но... Пока нет. Так что второй комп исключительно как выделенный VDI терминал работает (благо для VDI есть нативный клиент).

В этот момент маководам стало как-то даже и обидно :)

В том-то и дело, что существует не только вэб-программирование. Можно связать жизнь с чем-то другим и с линуксом вообще никогда не сталкиваться. Если уж на то пошло, то для клиентских приложений лучше подходит Макось, потому что на чем-то другом разрабатывать под Айос нельзя, а клиентские программы очень хотят существовать и там тоже. Нельзя именно из-за хитрой лицензии Эппл, запрещающей разработку на чем-то другом.

Я работаю на Windows и без каких-либо ограничений пишу программы и утилиты, работающие под Linux. Сможете наоборот? нет. Выбор очевиден %) На самом деле, если выбор ОС ни на что не влияет кроме личного удобства, то спорить тут не о чем. Я предпочту старый раздолбаный Acer на Windows или Linux, самому последнему маку, ибо для меня мак -- просто неудобно.

Я бы даже сказал - противоестественно.

Автор просто не повзрослевший студентик, у которого есть один true way, а все остальные "ламеры"

Ну а я вот, перепробовав всё из списка, решил остановиться на универсальных, проверенных временем, кроссплатформенных(!) решениях - Sublime и TotalCommander.

Sublime действительно очень похож на VSCode (вплоть до того, что можно шаманить файлами настроек между ними). Но у Саблайма и дизайн поприятнее, и "юзабилити" попродуманнее. И стартует он ощутимо быстрее...

TotalCommander кроссплатформенный!? Я что то пропустил?

Может имелся ввиду Double Commander? Total-то точно исключительно под винду.

Ну под Android точно есть. Но тут да, разговор именно о целом семействе "нормальных" двухпанельных файловых менеджеров как противопоставление часто поминаемому "вырвиглазному" FAR-у.

Я не ретроград, но и обновляться только ради того, чтобы обновиться, не бегу.

Он только под винду и андроид и есть.

Но много клонов. Я перепробовал несколько (тоталь под винду таки платный немножко), остановился на DoubleCommander. Бесплатный, есть по винду и линукс, достаточно гибок в настройках и удобен в использовании.

Он ещё совместим по плагинам к TC, что резко расширяет функционал.

Я как 8 летний пользователь Емакса очень хорошо понимаю автора. Для меня Емакс уже незаменим, вскод пробовал сотню раз и постоянно плевался. Хотя Емакс в этом плане ещё хуже вима, тут на каждый чих можно функцию на лиспе написать, неовим пользователи только начинают пробовать это с Луа. Преимущество в использовании этих редакторов можно оценить только при слепом наборе и желании избавиться от мыши. Тогда они незаменимы и действительно ускоряют и разработку и просмотр кода.

как, вот как ускоряет разработку слепая печать и отказ от мышки? я мб какой то неправильный программист но у меня печать на клавиатуре из всего рабочего процесса занимает процентов 20 от силы и то половина зачастую это документация в жире и общение в рабочих чатах которые сюрприз все гуишные как жира и все прочие системы управления проектами. А остальное время это созвоны с командой, изучение бизнес задачи, продумывание архитектуры разбор очередных дампов, гугление и ожидание очередного ребилда. Да потраченное время на обучение этой слепой печати и настройка всех этих свистоперделок для печатанья двумя руками ни когда в жизни не отобьют потраченное на это время. Ноль разговоров если человек работает "машинисткой" и его работа напрямую связана со скоростью набора текста но у разработчиков мерить эффективность скоростью набора и редактирования файликов это что за гранью разумного...

Я вас все одно не смогу переубедить, вы не поверите, пока сами не попробуете. Созвоны и ожидание компиляции никуда не уберешь, с этим полностью согласен. Никто не говорит, что цель стать "машинисткой". Цель повысить эфективность там, где это возможно. Я гуглю прям в Емаксе, пишу тикеты в жире, даже с чатомГПТ там же общаюсь. Можно писать имейлы, читать rss, даже телегу можно прикрутить. В браузере использую tridactyl и вообще не скучаю по мышке. Каждая мелкая интеграция улучшает мою продуктивность в целом

Но если это всё прикрутить к емаксу, то чем переключение между жирой и чатгпт внутри емакса станет отличаться от переключения между емаксом и браузером, как это поможет эргономике?

Ну хотя бы тем, что браузер ты никак не настроишь так гибко под себя, как Емакс

Не, ну лет 20 назад работа с SQL-запросами например вполне себе "упиралась" в скорость печати - язык достаточно "многословный", с автодополнением в те времена дело не то, чтобы замечательно обстояло - да и сейчас, по чесноку, подтормаживает ;).

Документирование работы, переписка в чатах и почте + 0,5% повышения эффективности работы с текстом... кмк неплохая инвестиция в свое время была, вполне себе окупилась Эн раз к настоящему моменту. Так даже и не скажу, что было бы эффективней учить вместо - так чтоб потратил месяц времени и _всю жизнь_ пользуешься.

Большинство используемых мной технологий за 20+ лет конкретно так поубавили в значимости - разве что bash какой-нибудь... ну так слава б-гу вопрос "или - или" тут не стоял.

Большинство используемых мной технологий за 20+ лет конкретно так поубавили в значимости

Кстати, это очень хороший аргумент, слепая печать останеться с тобой, даже когда твоя иде канет в Лету)

Большинство используемых мной технологий за 20+ лет конкретно так поубавили в значимости - разве что bash какой-нибудь... ну так слава б-гу вопрос "или - или" тут не стоял.

Может я конечно не понял, но вопросы «или - или» стоят, как и холивары вида bash vs zsh vs ash vs fish

О, кстати, а потом приходишь на собес, а там "у тебя 15 минут, за которые надо прочесть сторик, обдумать архитектуру решения, написать реализацию, оттестировать, задеплоить в прод, расписать документацию, получить фидбек от PO/PM". Каждая почти первая техничка по software engineer такая. Прям так и вижу, как собеседующие, рассказав, какой у них скрам эджайл, бегут после собеседования на планирование спринта и закрывают бэклог во время этой самой планерки.

Вопрос не в количестве напечатанного, а в скорости печати. Она должна быть быстрее мышления и не задействовать сознательного мышления, так как там в этот момент рабочая задача. Иначе мысль начинает запинаться о паузы на набор.
В итоге получается что ты отвлекаешь сам себя (на запись мысли). А то, что одно отвлечение равно 15 минутам работы мы все помним.

Мы тут вроде речь про полноценные "идешки" ведём. С нормально настроенным автокомплитом. Действительно, что там слепая печать может ускорять?.. Даже имена переменных есть нужда полностью набирать всего один раз. Ну и мышкой я в редакторах редко пользуюсь - клавиш навигации вполне хватает.

У меня в Емаксе тот же самый полноценный автокомплит, с поиском имплементаций и джампом к декларации. Все тоже самое, что и в вскод. Вот только это все настроено с таким удобством, что ни одна "полноценная" иде не позволяет настроить. У меня целый список функций, которые делают какие-то маленкие действия, специфические для меня, моего окружения. Например есть мод на парсинг systemd логов. Или мод для управления kubernetes, для чтения rss и тд. Все в привычном окружении. Не зря говорят, что Емакс операционная система. Для самого редактирования я использую как раз вим биндинги)

Так оно ж примерно везде есть - причем "из коробки". И что проще - привыкнуть к тому, что сделано и не иметь проблем при переходе с компа на комп или сделать самому - для меня лично большой вопрос. И да, vimrc с конфигой тайлового VM я за собой потаскал - и повторять сий экспириенс не планирую.

Единственный неприятный момент - риск, что "чужое" владелец решит радикально УЛУЧШИТЬ и вот тут тоби звИзда... Но если честно - привыкнуть к какому-нибудь "new UI" оказалось не то, чтобы трудно.

не иметь проблем при переходе с компа на комп

Я совершенно не понимаю этого аргумента. Ещё ни разу в жизни я не работал за чужим компом. Если же вы про покупку нового компа/ноута, так с этим отлично справляются дотфайл менеджеры. Лично я использую chezmoi и тут снова преимущество в Вим/Емакс, потому что все сохраняется в текстовом файле, не надо настраивать все мышкой заново. Я недавно купил ноут и полноценно работал за ним уже через полчаса, после установки арч линукса

Эмм... ну, повезло. А у меня были прецеденты со сменой ОС при смене работы - на вот тебе macbook и не жужжи. А у нас корпоративный стандарт - windows 10, вот типовой АРМ - и куды хочешь, туды свой тайловый VM и присовывай :).

И закрытые окружения у клиентов - тоже в количестве. И работа на оборудовании заказчика... да много чего было.

Правда я не кодер - именно программисты могут с подобным и не столкнуться, да.

Да точно также сталкиваются. Тоже пришел - у нас все под виндой. Все схемы рисуем в Visio. Все ориентировано на винду. Виртуальное рабочее место - винда.

Вот поэтому перед каждым собеседованием я постоянно уточняю, можно ли мне линуксом пользоваться. И конечно же это подходит не для всех

Ну, наверное "да" - но у меня за всю жизнь было очень немного задач, решать которые из linux-only окружения принципиально эффективней чем из windows\гибридного. Вот наоборот - дофига, да.

Можно ограничить область деятельности linux4linux напилингом - и даже получать за это хорошие деньги - но зачем?

у меня за всю жизнь было очень немного задач, решать которые из linux-only окружения принципиально эффективней чем из windows\гибридного

Ну у меня строго наоборот, нету ни одного сценария, где от виндовс есть хоть какая польза а не геморой. Вообще кроме десктоп прог на виндовс мне сложно представить где винда лучше. Разве что в проприетарном мире, но я слава богу от него далек. Вот и выяснили причину недоумения большинства коментаторов. Мы просто работаем в разных вселенных, которые пересекаются разве что в браузере.

Ну это религия уже. Я "администрированием ActiveDirectory" с linux в свое время переболел - Хвала Аллаху, в легкой форме ).

IRL - доля linux ну процента 2, может 3. А то, что есть - такой себе "linux" - пачки контейнеров, легковесные виртуалки, которые примерно все равно октуда кувыркать. Т.е. и в 2% есть жизнь - никто не спорит - но как бы отрицать оставшиеся 98% странно.

Вы сейчас о чём? 98% у винды и на десктопе сейчас нету. Весь веб, модные нынче ИИ на линуксе работают

Вы этот "linux" видели? Ну раскатан каким-нибудь terraform'ом на 100500 нод talos у которого даже SSH нет - а унутре у него - и вовсе distroless контейнеры с софтом. И?

Я на нём работаю каждый день, конечно я его видел. Более того, эти контейнеры не серебрянная пуля и не всем подходят. Я вот предпочитаю локально бэк запускать, зачем мне лишняя абстракция для этого?

Ну, т.е. современную контейнеризованную архитектуру - "нет", так? "Предпочитать"-то можно все что угодно, а вот работать... windows - нет, macos - нет, современный околооблачный "linux" судя по всему - тоже "нет" - кто остался на трубе?

Зато с emacs'ом, да.

С чего вы это взяли? У меня 300 клиентов на всех континентах, 5 кластеров кубика, у каждого клиента свой деплоймент в своем неймспейсе. Более того всем этим я с Емакса и управляю.

Ну вот я и спрашиваю - "зачем"? "Чтобы что?!"

В каком-нибудь 2007 году понятно - вот на десктопе у тебя centos 6, вот на сервере RHEL, на десктопе ты какую скриптоту напилил - 1-в-1 на сервер перенес, ой, поломалось? Там же на сервере тем же vim'ом и поправил, profit! Навыки десктопного "linux'a" практически идеально маппятся на навыки управления сервером, все логично - тут и там одна и та же ОС.

А сейчас? Что общего у talos'а и твоей убунты-федоры-дебояна-генты? Ядро? И то условно. А между "distroless-контейнером"? И того нет. Как умение башпортянить и системдить помогает скейлить serverless аппликуху в firecracker'е AWS? Ну вот "никак". И даже доступа к апи куба у тебя нет - "програмировай давай!" а деплоем специально обученные люди занимаются.

Никуда ты со своим "любовно вылизанным" emacs'ом окромя своего десктопа не вылезешь по большому счету и нигде больше он не нужен. Ну и вот зачем?

У меня встречный вопрос: а что получит условный юзверь из мира айти, имеющий опыт установки и конфигурации линукс десктопа, переходя прямо сейчас на винду?

Отвечу как человек имеющий дуалбут на ноуте: ничего, кроме горячей сковородки и шума от кулера. Ладно... раз в два месяца бывает перезагружусь в винду за автокадом (на то и дуалбут стоит), но ощущение такое, что машина не твоя, тебе просто дали попользоваться. И что парадоксально - хваленой "стабильности" винды в сравнении с арчлинуксом на ноуте, да при таком режиме, тоже не ощущаю. Второй встал как радной, работает как хорошие часы.

В целом согласен с @vtb_k, мой собственный опыт пересекается примерно на 90%, включая emacs.

Эм... Ну, доступ к оставшимся примерно 98% софта, бесшовную интеграцию в рабочее окружение организации, стандартную техническую поддержку с определенным SLA, complience-policy в масштабах конторы - это прям навскидку.

доступ к оставшимся примерно 98% софта

Может вы приведёте какие-то пруфы на такие голословные утверждения?

Эмммм... вам ПРАВДА нужно доказывать, что количество написанного под win\macos софта порядково больше написанного под *nix\условно-кроссплатформенного?

А как это можно доказать?

Да мне тоже вот интересно. Особенно если в стиле "вот видите - не 98% а 97,5%! - и это вы еще ХХХ.репо с хелловротами Васи не посчитали!".

Конечно надо, ведь софт бывает разный. Десктопный софт под винду - это далеко не 100% всего софта в мире. И не всегда только он необходим

А, ну да, ну да. Есть еще серверный под неё же - и его, предполагаю, тоже кратно больше.

Но в этой олимпиаде я, простите, участвовать не буду - есть более продуктивные занятия, чем доказывать очевидные вещи сторонникам теории плоской земли, извините.

Если вам так будет удобней - считайте, что я расписался в своей неправоте ))))

Вне олимпиады...

Дескопного софта с GUI для винды объективно больше, да и выбрать что-то под конкретную задачу есть из чего. Но...

- На практике очень редко не находится альтернатива ("на вкус и цвет", естественно),

- Если нужно что-то, где GUI совсем не обязательно (ssh клиент, компилятор языка X, и тд), внезапно оказывается, что найти и установить то же самое в линуксе намного легче (чаще всего уже установлено), чем в винде.

- В экосистеме условного прогера или сисадмина большинство программ из себя представляет именно ту "мелочь", которая зачастую как-раз не имее GUI и требует периодических обновлений (что, как по мне, намного удобнее делать пакетным менеджером).

В моей нескучной практике, начиная с кофигурации удаленного сервера и закачивая созданием шрифтов, единственный случай, где винда незаменима - это Revit и AutoCAD.

Это вы еще телефоны не прошивали ;)

По факту, кстати. Я помню мне с мака надо было срочно прошить телефон, оказалось, что это только на винде можно сделать. Пришлось ставить VB с 7 виндой и через виртуалку прошивать.

вот только для винды есть простое решение этих "недостающих" вещей в виде wsl, vbox и т.д. + нормальные драйвера для видеокарт и прочего нового железа, а вот со стороны linux это зачастую не так. Поэтому win + wsl/vbox может объеденить плюсы из обоих ос, а с linux этого достичь сильно геморойнее.

Wine позволял запускать большинство вин прог задолго до vsl, не говоря уже про vbox. Иногда лучше промолчать

ой не надо мне про wine, я отлично помню как он "прекрасно" запускал hmm3 в 2000х, в нынешнее время это стало чуть получше но wpf и по ныне запускать он не способен (не его вина). А уже про vbox действительно стоило бы промолчать раз нет проводили тестирование производительности, он в разы бысрее wsl что первого что второго особенно в части работы с ntfs дисками. Если интерестно попробуй на досуге собрать какой нибудь qt сорцы которого находятся на ntfs в этих трех системах виртуализации.