Які конкретні підвищення продуктивності забезпечують Vim / Emacs над текстовими редакторами GUI?

Це не мається на увазі як троль чи вогник чи щось подібне. Я використовую Vim як мій консольний редактор вибору вже кілька місяців (для редагування файлів конфігурації, перебуваючи в моєму терміналі), але я не думаю, що я міг би вистояти за свою нормальну щоденну роботу над написанням веб-додатків , що я роблю з текстовим редактором GUI (який не важливий).

Я відчуваю, що мій текстовий редактор GUI може зробити все, що потрібно для моєї роботи. Він має гідний пошук / заміну з автоматичним заповненням історії для обох. У ньому є підсвічування синтаксису, нумерація рядків, інтерфейс із вкладками, просте копіювання та вставлення тощо. Єдине, чого не вистачає моєму поточному редактору, - це відповідність регулярних виразів, але є багато редакторів тексту графічного інтерфейсу, які зроблять пошук / заміну регулярних виразів.

З огляду на те, що я щойно сказав, які переваги продуктивності має Vim (або навіть Emacs) над текстовим редактором GUI, окрім того, що він встановлений на кожному комп’ютері. Мені б хотілося, щоб конкретні завдання, які краще / швидше на Vim / Emacs, або які просто неможливі в існуючих текстових редакторах GUI.

Для Vim:

• Vim має кращу інтеграцію з іншими інструментами (командними оболонками, скриптами, компіляторами, системами управління версіями, ctags тощо), ніж більшість редакторів. Навіть щось таке, як :.!, наприклад , передача виводу команди в буфер - це те, що ви не знайдете в більшості редакторів GUI.

• Інтерфейс із вкладками не такий приємний, як інтерфейс "віконця", який дає вам Vim / Emacs. Ви можете бачити два або більше файлів одночасно. Чим більше ви можете бачити на екрані, тим більше ви звільнюєтесь думати про свою проблему, а не робити розумовий облік змінних імен та підписів функцій.

• Не варто недооцінювати силу регулярних виразів Vim. Існує велика кількість розширень для Vim, які відповідають конкретному стовпцю, позначці, позиції курсору, певним класам символів (ключові слова, ідентифікатори) тощо.

• Інтегрована diffта grep(платформа незалежна, тому вам не потрібно завантажувати та вивчати новий інструмент щоразу, коли змінюєте комп'ютери).

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

• Кілька копій / вставлення регістрів. Якщо у вас є лише один, ви переживаєте дивні викривлення, щоб уникнути розкрадання буфера обміну. Вам не слід було.

• Система скасування / повторення Vim неперевершена. Введіть щось, скасуйте, введіть щось інше, і ви все одно можете повернути перше, що ви ввели, тому що Vim використовує скасування дерева, а не стек. Майже в будь-якій іншій програмі історія першого, що ви набрали, втрачається в цій обставині.

• Пересування, копіювання, вставлення та видалення тексту у Vim шалено швидко. Команди є простими, однократними натисканнями клавіш і композиційними. Додайте всі часи, коли ви робите ретельне, кропітке виділення миші та Ctrl-X, а потім замініть їх усіма da((видаліть набір відповідних паронів та все, що в них). Це економить більше часу, ніж ви могли подумати

• Невеликі речі, як *пошук слова під курсором, або .повторення команди, або %підстрибування між відкриттям і закриттям батьків. Занадто багато їх у списку.

• Вбудована мова сценаріїв та потужне зіставлення ключів та макроздатність, щоб редактор можна було розширити будь-якими способами. Тони сценаріїв уже написані та завантажувані.

Якщо ви придивитесь уважно, ви побачите, що навіть функції, які мають інші редактори, Vim часто робить краще. Усі редактори мають підсвічування синтаксису, але Vim має синтаксичний файл майже для кожного формату файлу під сонцем, часто з великою кількістю параметрів конфігурації, і писати свій власний бруд просто. Багато редакторів обробляють різні кодування файлів ОК, але Vim дає вам дуже специфічні та бездоганні способи встановлення кодування файлів та перетворення між ними. Перше, що мене вразило про Vim - це те, наскільки ідеально він обробляє параметри відступу вкладки / простору та розриви рядків Unix / DOS порівняно з іншими редакторами, з якими у мене були проблеми в той час.

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

(vim - моя отрута; я впевнений, що Emacs пропонує подібні вигоди)

Найбільший виграш: не потрібно торкатися миші.

Для мене найзручніше - стрибнути вперед (або трохи раніше) до певної літери або комбінації букв або відскочити назад, пару натискань клавіш. Стрибки вперед за однією і тією ж умовою двічі або десять разів - це просто питання префіксації її цифрою.

Якщо вам потрібно повторити редагування, ви переходите до цього місця (2-3 натискання клавіш) і натискаєте "". щоб повторити останню редагування. Стрибки вперед (або назад) простіше - одним натисканням клавіші - якщо це однакова умова пошуку.

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

Через декілька днів ви виявитесь бурхливими щоразу, коли вам доводиться дотягуватися до миші (або натискати <Down>15 разів), перебуваючи в редакторі графічного інтерфейсу.

Мені завжди було цікаво, чому мало людей гагають над Вімом. Дивіться відео дії користувача Vim power:

https://www.youtube.com/watch?v=FcpQ7koECgk

Якщо ваш поточний редактор може робити те, що він робить, не потрібно перемикатися! :)

Також прочитайте цей http://www.viemu.com/a-why-vi-vim.html

Переглянувши відео та прочитавши цю статтю, у мене не було іншого вибору, як почати вивчати VIM. Минув майже рік, як я перейшов на VIM, і я не можу уявити, щоб використовувати щось інше.

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

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

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

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

Різниця полягає в тому, що Emacs відслідковує останні кілька місць, на яких була встановлена ​​позначка в кільці, і ви можете повернутися до них натисканням клавіші (або двома, залежно від конфігурації). Я вважаю це надзвичайно корисним, тим більше, що багато команд Emacs, які змінюють ваше розташування в буфері, встановлюють позначку у вашому старому місці. Наприклад, коли я редагую модуль Python і мені потрібно додати заяву про імпорт у верхню частину файлу. Клавіша натискання на верхню частину буфера (Alt- <) встановлює позначку. Додаю заяву про імпорт. Я натискаю Ctrl-u Ctrl-Space і повертаюся з того місця, де я почав. Я можу продовжувати робити це, щоб повернутися до попередніх позицій. (Можливо, мені потрібно було вибрати якийсь текст, додаючи цю заяву про імпорт.)

Інша (і більш відома) різниця Emacs - це кільце вбивства. Більшість натискань клавіш для видалення тексту з буфера зберігають текст до кільця вбивства, яке потім може бути відкликане командою "yank" (Ctrl-y). Основна особливість полягає в тому, що наступні команди yank отримують старіший вбитий текст. Таким чином, ви можете вбити кілька розділів тексту підряд, а потім відновити їх у порядку. Ви також можете прокрутити кільце для вбивства з Alt-y після викрутки, видаливши отриманий текст і вставивши наступний запис у кільце.

Emacs отримав ці особливості у 1978 р. Єдиною іншою основною системою, яка їх прийняла в будь-якій мірі, є NeXTStep (і тепер успадкований Какао). Інші інструменти надають більше можливостей для конкретних завдань, можуть бути розширені мовами простішим у використанні, ніж Emacs Lisp, і мають більш приємні візуальні інтерфейси ... але Emacs залишається кращим у редагуванні тексту. Ось чому, як тільки ви знаєте, як ним користуватися, так важко кинути.

Це не зовсім конкретне завдання, але для людей, які навіть можуть страждати від RSI, той факт, що ваші руки ніколи не залишають клавіатуру в vim, майже безцінний. Насправді я працював лівою мишкою на роботі, тому що це дозволило мені рухати рукою менше, щоб дотягнутися до миші (у мене на клавіатурі вдома немає клавіатури, тому я можу тримати її праворуч).

Ще однією невеликою перевагою було те, що, IIRC, оригінальний vi був розроблений для прискорення редагування файлів через надзвичайно повільний віддалений зв’язок. Зрозуміло, що сьогодні це не так вже й багато, але якщо у вас є повільний зв’язок, удачі запустити редактор тексту gui і дозволити йому реагувати.

Для мене речі великої продуктивності

• Я можу зробити майже все з клавіатури.
• Потужні макроси
• У моєму 20-річному карері з використанням 9 ОС основні прив’язки клавіатури не змінилися. Я можу скористатися майже будь-якою системою і вже знаю свій шлях навколо редактора.
• В текстовому редакторі вже додано майже будь-яку функцію, яку ви могли б хотіти.

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

З мого досвіду, основні досягнення продуктивності, які забезпечують vim та emacs (я сам людина vim, але emacs, безумовно, подібний):

• Ви можете мати ті функції, які надають сучасні IDE (наприклад, цикли редагування, збірки, запуску, вбудована документація та завершення вкладки та ін.), Але цього не потрібно . Підвищення продуктивності? Ви бачите лише стільки, скільки хочете бачити. На мій досвід, IDE не робили людей більш продуктивними, тому що вони показували занадто багато інформації (всілякі браузери). Цей «додатковий біт енергії, коли він вам потрібен - але не швидше» - це цілком підвищення продуктивності IMHO.

• Редактори користуються великою популярністю серед програмістів, а це означає, що доступні величезні сховища сценаріїв, книг та груп користувачів.

• На моєму досвіді (тут я можу говорити лише за vim) середній користувач vim - це досить хороший інженер-програміст. Я не знаю, чому це (або, можливо, мені просто пощастило), але, можливо, люди, які перешкодили звикнути до такого "старого" інструменту, як emacs або vim, мають правильну відданість (і контактувати з іншими людьми, як це ). Можливо, це непрямий вплив цих редакторів, але спілкування з іншими людьми vim (або emacs) на напр. IRC виявилося досить цікавим, оскільки ті самі люди були також дуже зацікавлені у всіх видах програмної інженерії (або інформатики). . Ці редактори, здається, приваблюють певний вид особистості. :-)

"Підвищення продуктивності", яке я отримую за використання легкого клону emacs для крихітних програм, полягає в тому, що він запускається як змащений блискавка. Зазвичай я можу вирвати швидку програму тестування на C # до того, як Visual Studio завершить завантаження рішення "пісочниці".

Звичайно, я міг просто залишити Visual Studio відкритим (або іншим VS відкритим, якщо я працюю в ньому на той час), але тоді він буде замінений, якщо я залишу його на деякий час у режимі очікування тощо.

Для будь-якого значного розміру - або якщо я не знаю API, який я дуже добре використовую - IDE - це шлях вперед, IMO.

Я використовую gvim для Windows, тому технічно це редактор тексту GUI, але це vim ..

Для підвищення продуктивності я знаходжу:

1. Мені ніколи не доводиться користуватися мишкою, тому я швидший.
2. пошук, заміна, копіювання / вставлення тощо - все швидше за допомогою прив'язки клавіш vim до руху миші (як тільки крива навчання була перероблена)
3. Як було сказано в попередніх коментарях, показники RSI значно скорочуються. Зап'ястя подякували мені з моменту переходу на vim.
4. він легкий і швидкий

Ви знаєте, для vi я думаю, що це зводиться до встановлення режиму вставки та команд. Хоча це може здатися віддачею до того часу, коли ви не могли залежати від курсору чи спеціальних клавіш, це насправді означає, що багато потужних команд руху та тексту маніпуляції - це мінімальна кількість натискань клавіш. Продуктивне кодування полягає не в масовому введенні тексту (за замовчуванням у "сучасних" редакторах), а у спалах об'ємного тексту з подальшими значними невеликими перетвореннями та ще більшими періодами перегляду.

Це вийшло на перший план для мене особисто, використовуючи vi через мережу кампусу з високою затримкою. Ви можете легко отримати на 10 або 15 символів попереду відповіді. За допомогою vi я міг із задоволенням передбачити, де ці команди залишать мене і зможуть працювати з майже нормальною швидкістю. Цей кручений досвід є постійною перевагою в нормальних умовах - менше візуальних мозкових сил, присвячених постійній графічній передачі даних.

Загальноприйняті прискорювачі пошуку * та # слова чудово підходять для прогортання коду. І% для узгодження дужок надзвичайно корисно. Звичайно, навряд чи здається, що це багато в порівнянні з ctl-], але половина натискань клавіш додається.

Особисто я використовую winvi, що додає кілька великих речей, які, напевне, має і vim. Швидкий стрибок у шестигранний режим тріскає багато проблем із текстом "що, до біса". І повністю гнучка робота з закінченнями рядків - це знахідка, яка стала очікуваною особливістю для текстового редактора. Нарешті, він може відкрити будь-який файл незалежно від вмісту. Це означає елітну хакерську майстерність першого порядку.

У Unix ви можете швидко зафіксувати вихід програми або навіть фільтрувати розділи вашого файлу через зовнішні команди. Надзвичайно потужна, але я думаю, недостатньо використана функція.

Я використовую Vim досить часто. Він не замінює UltraEdit для мене. Оскільки перераховано багато позитивів, я думаю, я піду проти зерна та перелічу деякі неприємності з Вімом.

• Слабка обробка FTP. Я "сортую" багато сайтів, і неможливість легко переглядати та редагувати файли на віддаленому сервері FTP - це великий недолік для мене. NWRead недостатньо хороший.
• Дивнощі консолі успадковані від загальних проблем із терміналами, які, здається, чують Linux. Зазвичай я використовую PuTTY для підключення до свого вікна Linux (під керуванням Ubuntu), і чомусь стрілочні клавіші відображають A / B / C / D у режимі вставки (і всі проблеми з підтримкою кольорів). У gVim, ctrl-tab можна легко відобразити на "bn", але не в консольному режимі, таких проблем багато.
• Параметри пошуку / заміни дуже слабкі, потрібні інтерфейс. Доводиться набирати всю річ в одну лінію, просто недостатньо. Я вважаю, що набагато більш досконалий діалог у скажімо, UltraEdit дає мені набагато більше сил, врешті-решт, навіть якщо фактична підтримка регулярного вираження може бути набагато слабшою.
• Занадто сильна залежність від розкладки клавіатури США. Дуже багато клавіш, які використовуються для основних функцій, таких як `, не друкуються на моїй датській розкладці клавіатури (і розташовуються впоперек, те саме з $ та багатьма іншими). Використовувати деякі функції дуже незручно.

Віддалений робочий стіл швидко показує лише рідну програму Windows. Ми намагалися використовувати Eclipse для розробки в unix. А ви знаєте що? Це навіть було неможливо.

Друга причина полягає в тому, що ми могли б розширити наші Vims та Emacs для виконання всіх завдань, що стосуються конкретного проекту, від перегляду БД спеціальним чином, щоб виділити та автоматично завершити власність власної мета мови.

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

Те саме з підсвічуванням синтаксису, поведінкою з певними файлами тощо. Усі види речей можна налаштувати під vim.

Не дуже впевнений, чи можна це зробити так просто в редакторах типу GUI.

Запис і повтор у VIM - це неперевершено приголомшливий вигляд, який ви навряд чи зможете знайти в інструментах на основі GUI.

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

Я багато років був зневіреним користувачем Emacs. Але ніколи насправді не вдавався в це. Потім я почав вивчати Clojure (мій перший Lisp) і відкрив ParEdit.

І це підірвало мій розум.

(Дивіться тут кілька прикладів: https://www.youtube.com/watch?v=D6h5dFyyUX0 )

Lisp + ParEdit - це найдивовижніший досвід редагування, який я коли-небудь мав. Більше нічого не наближається. Лісп - це вже не незручна мова для написання, змушує мене турбуватися про врівноваження безлічі дратівливих дурних дужок. З ParEdit, послідовна структура Lisp стає величезним бонусом для роботи, оскільки ті ж трансформації дерев - рожевіння, розшарування, розщеплення та приєднання - працюють скрізь, як у контрольних структурах, так і в структурах даних. І ParEdit заважає мені робити дурні помилки. Зробити помилки в синтаксисі стає майже неможливо.

І на відміну від Eclipse, це не якась копітка перевірка в реальному часі, яка завжди працює у фоновому режимі, спалюючи мій процесор. Нічого не коштує ... ParEdit просто робить правильну структурну зміну, коли я про це прошу.

(Взагалі Emacs настільки ж швидкий, як і потрібно. На відміну від Eclipse, який схожий на введення в клей.)

Наступне, що я виявив - Yasnippet ( http://emacswiki.org/emacs/Yasnippet ). Ще раз я нічого подібного раніше не використовував. Не просто макрос для додавання котла, а динамічна, навігаційна форма.

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

(Мій досвід - кілька років з Visual Studio та іншими IDE, потім 15 років Vim, а останні 6 місяців з Emacs.)

Довговічність - Vim / Emacs - FOSS , і існує вже десятиліття. Їх використання не знизиться, а також їхні функції не будуть сильно ламатися / зникати / змінюватися, тож ви можете розраховувати на побудову всього ядра інструментарію для кар’єри навколо майстерності лише одного редактора.

Віддалений / всюдисущий доступ у терміналах - Хоча в обох є прекрасні системи для редагування віддалених файлів, ви також можете встановити їх у будь-якій системі, у яку ви коли-небудь входите.

Розробка на основі REPL - в обох є режими "SLIME" в різних формах, які інтегрують будь-який тип REPL, з яким ви працюєте. Наприклад, я ніколи не стикався з ітераційним розвитком настільки потужним, як той, який надає CIDER .

Лінінг - якою б мовою ви не користувалися, мабуть, є деякі засоби зв’язування , вбудовані в компілятор чи зовнішній інструмент. Вони безперебійно інтегруються з Emacs / Vim, показуючи ваші кодові проскаки майже в режимі реального часу.

Граматика мнемонічних команд. Хоча обом потрібен певний час для вивчення, у цих редакторах є чудово розумні системи доступу та навіть запам'ятовування - тисячі команд з кількома натисканнями клавіш та комбінаціями клавіш. Вони можуть повністю усунути будь-яку потребу у використанні миші, якщо ви так схильні.

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

Навігація - теги, паритетне подобається, позначки, вікна, вкладки, стрибки vim-rails та багато інших вбудованих модулів.

Менеджери пакунків / сховища - Emacs має декілька (elpa, melpa, marmelade), а Vim також непогано (vundle, збудник тощо ). Я не знаю жодної спільноти навколо ВПО, яка б пропонувала щось подібне до цього. Я бачу понад 5000 пакетів с package-list-packages.

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

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

Безмежно настроюється - Elisp - це дуже потужна мова для розширення / модифікації Emacs. VimL - еквівалент Vim. На обох написані книги. Налаштуйте кольорові теми та поведінку на свій захват!

Однією з переваг, які мають всі консольні редактори над редакторами GUI, є те, що вони можуть бути запущені в термінальному мультиплексорі, наприклад на екрані або tmux . Чому це добре?

• Швидше перейти з однієї термінальної мультиплексорної консолі на іншу, ніж перейти з однієї консолі GUI на іншу за допомогою миші або навіть за допомогою вкладки alt. Це пов’язано з тим, що консолі можна назвати та перемикати на них, набравши кілька символів імені.
• Якщо сеанси вашого редактора знаходяться на консолях термінального мультиплексора, ви можете отримати доступ до них з будь-якої машини. Якщо мені потрібно виконати якусь роботу з дому, я можу запустити свій скриньку в коробку, приєднати вже запущений термінальний мультиплексор до мого сеансу ssh та бути там, де я зупинився, коли залишив роботу.

Оскільки vim / emacs часто використовуються програмістами і як користувачем C # з 2003 року, з цього упередження pov справедливо робити це інакше несправедливим порівнянням (Ще одним може бути VS C ++ з Visual Assist X vs C ++ у vim / emacs):

Для C # та Visual Studio:

1. Я щойно підрахував кількість натискань на клавіші для цього рядка:

       public List<string> Names = new List<string>();
   //  3      3    3      1111111111111            211   =3+3+3+8+5+2+1+1 = 26 keys strokes + 3 uses of Shift while typing the line above in VS C# 2013 vs 47 key strokes for non-IntelliSense IDE's
   //                              (IntelliSense offers the List<string> because that's what you're likely after here but you can type something else if you want)
   // https://channel9.msdn.com/Blogs/Seth-Juarez/Anders-Hejlsberg-on-Modern-Compiler-Construction explains on how this is impl. for C#. In C++ I've heard of 3rd party VS plugin that improves or replaces the VS C++ auto-complete

2. Я читав про функцію emacs для стрибків у код. Я не думаю, що вона має саме таку особливість. Але він має схожу особливість. Ось мінус В.С. Функцій є дуже мало, але з часом вони перестають працювати. Востаннє я перевірив, що функція стрибка не спрацювала, але це було пару років тому. VS представив нову функцію графічного стрибка, яку я використовував замість цього. Для цього потрібна миша чи дотик.

3. Ось де виграють emacs / vi. Якщо вам доведеться багато стрибати в коді, функції VS для цього або не існують, або недостатньо перевірені.

Проблема з навігаційним інтерфейсом на основі миші полягає в тому, що

а) так само, як сидіти в дуже статичному положенні, можливо, погано, якщо так, миші, як правило, також роблять ваші пальці в статичному положенні. Біль у зап'ясті змінилася на трекбол. Я спершу спробував вертикальну мишу, але це нічого не вирішило.

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

Зрештою, якщо ви хочете перестрибувати між декількома конкретними місцями, зрозуміло, що "кільце для знаків" є більш ефективним. У VS є щось у цьому напрямку ... востаннє я це використав, він просто не працював надійно ...

в) і, ймовірно, є тонна дрібних функцій, які порушуються з кожним випуском, тому це є недоліком VS.

Вирішення цієї проблеми із «закритим джерелом»: Запишіть всю VS в C #, а потім дозвольте модерувати / редагувати складений код (під час виконання, зберігаючи зміни як патч, який додатково завантажується при наступному запуску), не звільняючи джерело. Це можна зробити, якщо декомпілятор виведе код таким, яким він був під час заїзду. 180 градусів від того, як працюють місцеві компілятори. Потім двійковий код стає вихідним кодом та виконуваним файлом замість цього безладу .cs-файлів та .exe-файлів тощо. Існують сторонні інструменти, які вже майже можуть це зробити, тому "моделювання" C # exe досить тривіально, але я пропоную взяти це логічний висновок: включіть навіть коментарі до .exe та .dll. Файли все ще залишаться крихітними порівняно з компільованими програмами C / C ++. Оптимізація? Ви також можете включити попередньо оптимізований код. Коли моддер модифікує exe під час роботи програми, підключається немодний "AST" та супровідний оптимізований двійковий файл. Така ж ідея, як у компіляторі C #, але взята далі. Наступний крок: Запишіть всю ОС цією мовою, щоб навіть при закритому джерелі Windows його можна тривіально модифікувати, оскільки вихідний код поставляється з кожним двійковим кодом. Немає налаштування середовищ, компілювання, зв’язування. Просто змініть ОС під час роботи. Близька аналогія: Якщо ви писали веб-браузер у Common Lisp, ви можете редагувати веб-браузер, не зупиняючи його, і створювати веб-сторінки тією ж мовою, що й браузер. він може бути тривіально модифікований, оскільки вихідний код постачається з кожним двійковим кодом. Немає налаштування середовищ, компілювання, зв’язування. Просто змініть ОС під час роботи. Близька аналогія: Якщо ви писали веб-браузер у Common Lisp, ви можете редагувати веб-браузер, не зупиняючи його, і створювати веб-сторінки тією ж мовою, що й браузер. він може бути тривіально модифікований, оскільки вихідний код постачається з кожним двійковим кодом. Немає налаштування середовищ, компілювання, зв’язування. Просто змініть ОС під час роботи. Близька аналогія: Якщо ви писали веб-браузер у Common Lisp, ви можете редагувати веб-браузер, не зупиняючи його, і створювати веб-сторінки тією ж мовою, що й браузер.