Vim проти інтегрованого середовища розробки, Mechanics of software
Programming is thinking, no typing
You are here
Vim проти інтегрованого середовища розробки
Подискутував із Сергієм Бобровським (СБ) на тему, без холівара. Текст нижче.
СТ У vim немає контекстного автодоповнення по Ctrl + Space. А це мінус багато годин на рік. Набагато більше ніж 64.
СБ Ось якраз автодоповнення - це інтуїтивне шаблонне зло, яке заважає думати своїми мізками:) Як і багато фічі рефакторингу, решейперів усіляких і тп. Тільки чистий код, лише хардкор.
СТ Автодоповнення - це єдина можливість не забивати мізки непотрібними дітями коду, залишивши більше часу на розуміння структури. Я в своєму АПІ не пам'ятаю сигнатури, а коли поруч колеги курчат сотні тисяч рядків коду, то vim перетворюється на інструмент масового пошуку та заміни тексту по файлах. Але в цій якості мені більше подобається програміст нотепад.
СБ Йдеться швидше про розумний баланс - багато кодерів вважають, що це фіча мастхев, навіть навчаються програмувати з нею, і коли починають кодити без неї, а це нерідко буває необхідно, починається різке гальмо. Це добре, коли використовуєш його усвідомлено, а не "конструюєш" код із кубиків автокомпліту, намагаючись тупо вгадати потрібне, і періодично промахуючись. Для vim є в принципі купа плагінів для автозаповнення, під будь-яку мову фактично. Та й під свій API якщо і робити заповнення, то vim якраз зручно.
СТ Сучасні фреймворки типу дотнета - це десятки тисяч класів та сотні тисяч властивостей та функцій. Так що в цьому плані - мастхев, якщо не хочеш зубрити це напам'ять і перетворюватися на кодера. А ось тонкі операції з кодом - це нотепад та його просунуті нащадки, включаючи vim. Але це трохи більше 10% часу.
СБ Я якраз у неті практично не користуюся комплітом, тому що пам'ятаю все, що мені буває потрібно. Не знаю, що мається на увазі під тонкими операціями з кодом:) але на мій свіжий досвід, працювати в vim виходить набагато ефективніше, ніж у чомусь іншому, хоча основні операції приблизно ті ж самі.
СТ Приклади "тонкого". Поміняти щось у модулі, не чіпаючи DFM і навпаки. Відремонтувати WinForm, коли студія не може її відобразити, видаючи помилку. Масовий пошук та заміна.
СБ Ну це так, але це багато в чому наслідок - первинне зло сама студія з віндою))) Тільки лінукс та термінали! До речі, vim є заміна через регулярні вирази :) Наприклад, видалити в xml тег незалежно від його вмісту. Заміна у фіксованому діапазоні рядків, та інші ласощі. Ну і відповідні плагіни звичайно ж є https://github.com/skwp/greplace.vim
СТ Не подобається студія - є чудове середовище Monodevelop.
СБ Мені подобається студія, з чого ти взяв. Вона найкраще середовище під ні і вінду, особливо з решейпером. Вона просто має таке саме відношення до моїх лінукс-проектів, як і eclipse - тобто ніякого.
СТ А я якраз пересів на Monodevelop у зв'язку з лінуксовими проектами. Вся перерахована трійка - Lazarus, Monodevelop і CodeBlocks - відмінні середовища, що дозволяють працювати у двох ОС з мінімальними відмінностями. Під Маком теж має працювати, але сам не пробував. Vim для сотень та тисяч класів (тільки своїх) - несерйозно.
СБ Ну якщо код під дотне переносиш, це зрозуміло. З мінімальними відмінностями та unity з монодевелопом класно допомагає, під мобілки та три осі, я їм там із задоволенням користуюсь для налагодження :) Але як завжди, дивлячись що за завдання. А які проблеми з vim хоч із мільйоном класів? Саме йогоавтентичність і робить роботу ефективнішою в рази, ніж у ide з мишею, стрілками та автокомплітом, стимулюючи глибше занурюватися у свій проект (goto початок треду).
СТ Go to definition/implementation, список методів поточного контексту екрана з переходом по 2-3 букв, автодоповнення по контексту. Будь-яка з перерахованих IDE може все, що vim плюс набагато більше специфіки. А шорткати - це хто як звик. Інтегрована налагодження та трасування - окрема тема, для серверних додатків не так критична.
СБ Ну адже я спочатку трохи про інше: автентична робота з vim аж ніяк не як з універсальним едитором. Адже не про те, хто що може, а як це реалізовано. Для vim море вільних плагінів, і якщо його заточувати під конкретний проект з урахуванням місцевого контексту, кожна ide йому свідомо програє - з нього можна швидко зробити швидкісну індивідуальну ide безпосередньо під мої потреби. Можливо, це моя специфіка, а в інших навіть у схожих завданнях ефект буде протилежний.