Emacs та "самозростаюча продуктивність"

Коротше кажучи, моє запитання для ваших користувачів хардкор Emacs таке: чи досягли ви цього "самозміцнюючого результату", про який говорить Стів Єгге ?

Emacs - це власний хостинг: написання речей в ньому робить саме середовище більш потужним. Це цикл зворотного зв’язку: рекурсивний, підсилюючий себе, мультипликативний ефект, який відбувається тому, що ви покращуєте середовище, яке використовуєте для створення удосконалень.

Чи справді ви відчуваєте, що підвищення вашої Emacs зрештою зробило вас в 10 разів ефективнішими , а ваша продуктивність продовжує зростати в експоненціальному відношенні тощо, тощо?
Чи є у вас кілька прикладів / досвіду для спільного використання?

Щодо мене, я використовував і Emacs, і Vim для розробки (в даний час дотримуюся Vim), мої .emacsі .vimrcобидва налаштовані так, щоб відповідати моїм потребам, і я ціную владу обох цих редакторів. Але я не відчував цього "самозміцнювального циклу" Emacs, не зустрічав когось, хто це зробив (звичайно, це могло бути, тому що я не справді хардкор Emacser, і ще не зустрічався з багатьма Emacsers).

Наприклад, у Facebook, хлопець поруч зі мною використовував Vim, а хлопець поруч із ним використовував Emacs. Обидва вони були швидкими та продуктивними, як пекло, і я пов'язую це не з редактором, яким вони користувалися, а з їх власним інтелектом та ставленням.

Але як би там не було, я би радий побачити приголомшливі приклади прихильників Emacs, які повернуть мене до Церкви Емаків.

10 X більш продуктивні ? Не схоже. Я схильний вважати, що мультиплікативні фактори більше схожі на 1,1, який через деякий час сумиться.

Те, про що говорить Стів Єгге, насправді є роздумом про те, щоб бути експертом у Emacs, і це дуже рідко. Люди, які досягають цього мультиплікативного ефекту, активно налаштовують свій досвід Emacs, пишучи elisp, щоб адаптувати Emacs відповідно до своїх конкретних потреб. Наприклад, Єгге писав еяки . Тлумачення цитати Yegge суворо означає, що ви налаштовуєте Emacs, щоб полегшити налаштування / розширення Emacs.

Ось як я розбила різні рівні знань, коли вони застосовуються до Emacs:

• Новачок знає , як запустити Emacs, переміщати курсор, внести деякі зміни, вийти з Emacs.
• Початківець просунутий знає , як поставити деякі базові настройки в їх .emacsабо повністю скопійовані шматки чужих .emacsв них. Вони знають, як зробити глобальні прив’язки ключів, requireвбудовані пакети, включити незначні режими.
• Компетентні користувачі Emacs мають великі .emacsфайли, можливо, розділені на кілька файлів. Вони завантажують і використовують нестандартні пакети, знають, як знайти документацію для команд, режимів, переглядати існуючі прив'язки клавіш, зручні з відмінностями між мінорними та основними режимами. Компетентні користувачі, як правило, зберігають один екземпляр Emacs, який працює протягом днів / тижнів, пишучи, збираючи, запускаючи та налагоджуючи програми зі своїх Emacs.
• Кваліфікованим користувачам зручно писати emacs lisp, створюючи власні інтерактивні команди та зручно писати незначні режими. Досвідчені користувачі переглядають код Emacs lisp, щоб краще зрозуміти режими, якими вони користуються, використовують налагоджувач elisp і зазвичай використовують неповноцінні процеси (оболонки, процеси Lisp, ...).
• Користувачі експертів Emacs пишуть нові основні режими з нуля, переглядають та змінюють код C для Emacs, знають, що таке рекурсивне редагування та використовують його, використовують міжпроцесорне спілкування для інтеграції Emacs із зовнішніми інструментами. Вони також читають список розсилки emacs-devel .

А оскільки ви просите особистого досвіду, ось приклади того, що я особисто робив, це дає відчуття, що я більш продуктивний. Примітка. Я, мабуть, працюю в компанії, де ми ніде не знаходяться поблизу кровотоку меж середовищ розробки, наприклад, ми все ще використовуємо CVS.

• Я інтегрував Emacs з інструментом відстеження помилок: коли я здійснюю фіксацію, він записує ім'я файлу та версію в поля для помилки, а з Emacs я можу переглянути свої помилки, призначити їх, вирішити їх тощо.
• Я написав міст, що з'єднує мій продукт (денна робота) та Emacs, фактично роблячи свій продукт неповноцінним - дозволяючи мені змінювати вихідний код на ходу.
• Я розширив обробку TAGS за допомогою find-file-in-tags, який надає ряд ярликів, що відповідають моєму середовищу розробки.
• Я написав режим, який бере результати регресії і дозволяє мені переходити до збоїв, перевіряти файли журналів, повторно запускати один або кілька тестів або вводити пробіг налагодження з мінімальними натисканнями клавіш.
• Мій тижневий звіт про стан (так, я використовую Emacs для електронної пошти) створюється автоматично, використовуючи зобов’язання, які я робив протягом тижня.

Це зміни, які я внесла, щоб спеціально адаптувати Emacs до свого середовища та мого робочого процесу.

Я в 10 разів більш продуктивний, ніж інші навколо мене? Ні.

Однак для моєї щоденної роботи є багато завдань, які я можу виконати за допомогою декількох натискань клавіш, які інші витрачають набагато довше, роблячи їх у не налаштованому середовищі, і що, як правило, вимагає переключення між редактором та веб-браузером або оболонкою .

Вони є приголомшливими прикладами? Ні. Я впевнений, що багато з того, що я зробив, уже доступно у Visual Studio . Чи поверне вас моя стаття до Церкви Емаків? Напевно, ні.

Однак, якщо ви бачите схему поведінки у вашому середовищі розвитку, і у вас є такий свербіж, який говорить вам, "я дійсно не повинен робити X / Y / Z знову і знову, якби я міг тільки ...", то Я рекомендую спробувати використовувати Emacs, щоб подряпати свербіж. Ця подряпина могла б стати першим кроком вниз по тому, що «посилює» шлях, про який говорить Стів Йегге.

Незначна примітка: Я не знаю, що багато (будь-які?) Справді досвідчені користувачі Emacs активно використовують сайти переповнення стека, або, принаймні, вони не відповідають на питання, пов'язані з Emacs. Я кажу, що виходячи з топ-користувачів для тегів emacs та elisp на переповнення стека.

Цей доказ, звичайно, є анекдотичним, але ваше запитання прямо вимагає анекдотичних доказів.

Я студент, який займається дослідженнями в академічній лабораторії, яка включає наукові обчислення, а також писати. У такому середовищі (подумайте: python, SQL, академічні утиліти командного рядка спеціального призначення, текстові файли, LaTeX / BibTeX) навчання emacs зробило приблизно різницю між ручним кельмою та екскаватором. Через рік emacs (в якому я би оцінив себе суцільним Компетентним, що пальцем ступає в Proficient), Мені здається, що я хочу вирішити проблеми, які бояться мої лаборанти. Не тому, що вони ліниві, і я старанний, а тому, що весело зривати гори за допомогою екскаватора і обтяжувати подряпини в гори за допомогою кельми. Принаймні два рази моя команда почала сперечатися про те, щоб внести деякі складні зміни у формат звіту, лише щоб знайти, що це завдання вже було виконано, перш ніж вони навіть закінчили сперечатися про те, хто повинен це робити. Regexp замінити + вбудований elisp.

Так що в першому порядку, так, Emacs зробив мене набагато продуктивнішим.

Здається, ви запитуєте про підвищення продуктивності в сенсі другого порядку: чи мої прибутки від сумішей emacs? Хоча я б не оцінював себе цілком професіоналом , не кажучи вже про Йегге , я думаю, що я починаю бачити підніжжя кривої експоненції, і те, що моє використання emacs робить подальше емансинг ще більш продуктивним. Деякі короткі, анекдотичні статистичні дані з репо, щоб оцінити це:

• У команді 7 осіб я відповідав за більше половини зобов’язань. Регулюючи стаж, я все ще берусь майже вдвічі частіше. Не тому, що я майже вдвічі приголомшливіший, а тому, що Emacs все, крім мене, керує контролем версій. Оскільки я можу виконувати, оновлювати та об’єднувати безболісно, ​​я зареєструюсь із меншими дискретними фрагментами, як ми всі повинні робити. Але це означає, що я вільніше брати на себе «більші ризики» (я повинен зазначити, що ми пишемо експериментальний код для наукових досліджень, а не для виробництва), а це означає, що я дізнаюся більше про програмування та мою тему.

• В останньому написаному нами звіті svn blama говорить мені, що я відповідав за більше рядків, ніж три рази, ніж інші два автори разом . (Це не тільки тому, що я мав останнє зобов’язання. Мені було цікаво про це деякий час, тому я почав відстежувати це, і результати були досить стабільними протягом усієї історії версій.) Тому що я в 6 разів швидший автор? Ні: адже emacs - це бензопила для тексту. Це означає, що я можу робити види операцій на LaTeX, які я ніколи не заважав би намагатися раніше. Що означає, що я в кінцевому підсумку розумію більше про LaTeX, що робить мене ще більш продуктивним у майбутньому.

• 100% документації (як для коду, так і для внутрішніх досліджень) є моєю. Тому що мої лаборатори не переймаються документацією? Ну, я не дуже переймався цим, до того, як знайшов org-mode. Хоча я, як правило, убер-тип B щодо цих речей, орг-режим перетворився на легку залежність. Миттєвий експорт Org-режиму до приємного вигляду html та LaTeX усунув усі бар'єри для відповідальної документації та перетворив його на своєрідну гру. Тому зараз я це роблю. Якби цього не сталося, я б не став, або, принаймні, злякався б і відклав його і дав би випити ментальну енергію.

Інші коментатори припускають, що причинно-наслідковий зв’язок може бути саме назад: можливо, emacs винагороджує високопродуктивний, що позбавить впевненості у гіпотезі про те, що медіанський користувач, ймовірно, отримає будь-які вигоди. Я також можу запропонувати такий собі самореалізуючий ефект плацебо: чи ні emacs зробив мене більш продуктивним (і, звичайно, ми ніколи не дізнаємось, оскільки у мене немає однакового близнюка, який би не навчався emacs), у мене є безумовно, пережило проголошення в моєму відношенні до структурованого тексту. Мені дуже подобається використовувати emacs, це означає, що я більше його використовую, а це означає, що я дізнаюсь більше про нього, більше хвилююся & c. Коли я виявив режим BibTeX, я пам'ятаю, як ніби я щойно запитав дівчину на першому побаченні.

Якщо ви пропустили це: emacs змусив мене запаморочитись при думці редагувати бібліографічні бази даних. Я вважаю, що в моїй роботі щось варте.

Наприклад, у Facebook, хлопець поруч зі мною використовував Vim, а хлопець поруч із ним використовував Emacs. Обидва вони були швидкими та продуктивними, як пекло, і я пов'язую це не з редактором, яким вони користувалися, а з їхньою інтелігентністю та ставленням.

Це зауваження звучить дуже правдиво і є дещо застосовно до всіх видів порад щодо продуктивності.

Люди, які зацікавлені в збільшенні / оптимізації своєї продуктивності, як правило, більш продуктивні через їх спрямованість або поведінку в житті, незалежно від ефективності самого підбору продуктивності.

Це може бути підсумовано так: "Ви не кращий розробник, оскільки використовуєте Emacs або Vim, але такі люди, які присвячені достатньою майстерності для використання цих інструментів, як правило, є хорошим розробником" [1].

1. Це жахливе узагальнення, тому воно не є абсолютною істиною і все одно не означає багато (що таке хороший / поганий розробник? Тощо)

Я користувач Emacs вже близько 20 років, і я повинен сказати, що ні, я не досяг цього.

Щоб дістатися до "emacsvana", про який він говорить, вам справді потрібно зробити себе експертом у галузі еліса . Я трохи зробив, але насправді мої навички в основному закінчуються на рівні можливості налаштувати новий режим, який написав хтось інший. Спроба налагодити (чи не дай Бог виправити) чужий еліпс трохи поза мене, і писати власне з нуля навіть не думка.

Це від того, хто раніше використовував lisp і має 20+ років професійного досвіду розробки програмного забезпечення.

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

З цим насправді немає нічого поганого. Я знаю, як зробити макроси, що лише робить мене завантаженням більш продуктивним з Emacs, ніж я можу бути з будь-яким іншим текстовим редактором. Іноді, набагато більше, ніж в 10 разів, як продуктивно. Однак це не робить мене кращим, ніж той, хто знає vi однаково добре (оскільки він також може робити макроси).

Ні, я ні, і ніколи не чув нікого, хто має. Я не думаю, що це станеться. Я думаю, що Стів Йегґе робить те, що роблять популярні блогери: він робить суперечливу, найвищу заяву, щоб зрозуміти свою думку і бути більш помітним. Я не думаю, що він це означає як такий. Що він, мабуть, має намір повідомити, так це: "Emacs дійсно ефективний для початку, і якщо ви багато чого налаштовуєте, ви навчитеся бути ще ефективнішим з ним, що чудово, ммм-кай?"

Якби він щойно сказав це, ти не розгубишся, і у нього не було б половини більшості читачів.

Подивіться на це так: Emacs та Vim досконалі в текстовій хірургії та автоматизації повторюваних натискань клавіш, не кажучи вже про навігацію великими фрагментами тексту. Про це говорить Єгге, хоча більш проповідно.

Якщо у вас є файл 10000 рядків, де потрібно додати номер рядка до початку кожного рядка, ви також можете витратити півдня, роблячи це вручну в Блокноті.

Або запустити макрос або використати вбудовану функцію Emacs для подібних речей. Тоді ви економите половину робочої доби і ви більше 10 разів продуктивні.

Йдеться про виявлення повторення та усунення його. Для цього потрібен інтелект, досвід, практика та навички, тому не всі, хто використовує Emacs, не побачать переваг продуктивності.

Я не знаю про "N рази швидше", але ретельне додавання корисних функцій може зробити Emacs досить непоганим у заповненні шаблонів. Поєднайте це, трохи розуміючи мову цільової мови, і ви можете робити такі речі, як "скажіть emacs, що ви хочете створити функцію, скажіть їй вхідні аргументи (типи, якщо для мови потрібна інформація про тип) та повернути значення, щоб emacs створив скелет для подальшого використання заповнення ".