Какой конкретный прирост производительности Vim / Emacs обеспечивает по сравнению с текстовыми редакторами с графическим интерфейсом?

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

Мне кажется, что мой текстовый редактор с графическим интерфейсом может делать все, что мне нужно для работы. Он имеет приличный поиск / замену с автозаполнением истории для обоих. В нем есть подсветка синтаксиса, нумерация строк, интерфейс с вкладками, простое копирование и вставка и т. Д. Единственное, чего не хватает моему текущему редактору, - это сопоставление регулярных выражений, но есть множество текстовых редакторов GUI, которые будут выполнять поиск / замену регулярных выражений.

Учитывая то, что я только что сказал, какие преимущества в производительности имеет Vim (или даже Emacs) по сравнению с текстовым редактором с графическим интерфейсом пользователя, помимо того факта, что он установлен на каждом компьютере. Мне нужны конкретные задачи, которые лучше / быстрее выполняются в Vim / Emacs или которые просто невозможны с существующими текстовыми редакторами графического интерфейса.

Для Vim:

• Vim лучше интегрируется с другими инструментами (командами оболочки, скриптами, компиляторами, системами контроля версий, ctags и т. Д.), Чем большинство редакторов. Даже такая простая вещь :.!, как передача вывода команды в буфер, - это то, чего вы не найдете в большинстве редакторов графического интерфейса.

• Интерфейс с вкладками не так хорош, как "оконный" интерфейс, который вам дает 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 в действии:

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). Существенной особенностью является то, что последующие команды восстановления извлекают более старый уничтоженный текст. Таким образом, вы можете убить несколько частей текста подряд, а затем извлечь их по порядку. Вы также можете перемещаться по списку уничтожений с помощью Alt-y после рывка, удаляя извлеченный текст и вставляя следующую запись в кольце.

Emacs имел эти функции в 1978 году. Единственная другая важная система, в которой они были приняты в какой-либо степени, - это NeXTStep (и теперь унаследованная Cocoa). Другие инструменты предоставляют больше возможностей для конкретных задач, могут быть расширены на языки, более простые в использовании, чем Emacs Lisp, и имеют более приятный визуальный интерфейс ... но Emacs остается лучше при редактировании текста. Вот почему, когда вы знаете, как им пользоваться, так трудно бросить.

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

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

Для меня важнее всего производительность

• Я могу делать практически все с клавиатуры.
• Мощные макросы.
• За 20 лет работы с 9 ОС основные привязки клавиатуры не изменились. Я могу использовать практически любую систему и уже знаком с редактором.
• Практически любая функция, которая вам может понадобиться в текстовом редакторе, уже добавлена.

Одна вещь, которая мне действительно нравится в vim, - это команда "Repeater". По сути, нажатие .в командном режиме повторяет ваше последнее действие. Это лишь один из примеров действительно интересных функций, которые есть у «программистских текстовых редакторов», которых часто нет в графическом интерфейсе пользователя.

По моему опыту, основные приросты производительности, которые обеспечивают 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 для окон, так что технически это текстовый редактор с графическим интерфейсом, но это vim ..

Для повышения производительности я нахожу:

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

Знаете, я думаю, что для vi все сводится к наличию режима вставки и команд. Хотя это может показаться возвратом к временам, когда вы не могли полагаться на курсор или специальные клавиши, на самом деле это означает, что многие мощные команды перемещения и обработки текста представляют собой минимальное количество нажатий клавиш. Продуктивное кодирование - это не объемный ввод текста (по умолчанию в «современных» редакторах), а всплеск объемного текста, за которым следуют значительные небольшие изменения и даже более длительные периоды просмотра.

Лично для меня это стало актуальным при использовании vi в кампусной сети с высокой задержкой. Вы можете легко получить 10 или 15 символов перед ответом. С vi я мог с комфортом предсказать, где меня оставят эти команды, и смогу работать с почти нормальной скоростью. Этот извращенный опыт является постоянным преимуществом в нормальных условиях - меньшая визуальная мощность мозга, необходимая для постоянной графической обратной связи.

Обычные ускорители поиска * и # word отлично подходят для пролистывания кода. И% для соответствия круглой скобке чрезвычайно полезен. Конечно, это вряд ли кажется большим по сравнению с ctl-], но половина нажатий клавиш складывается.

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

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

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

• Слабая обработка 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 можно настраивать всевозможные вещи.

Не уверен, что вы сможете сделать это так же легко в редакторах типов графического интерфейса.

Запись и воспроизведение в VIM - это невероятно круто, чего вы вряд ли найдете в инструментах на основе графического интерфейса.

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

Я много лет был бессистемным пользователем Emacs. Но по-настоящему в это не входил. Затем я начал изучать Clojure (мой первый Лисп) и открыл для себя ParEdit.

И это поразило меня.

(См. Здесь несколько примеров: https://www.youtube.com/watch?v=D6h5dFyyUX0 )

Lisp + ParEdit - это самый потрясающий опыт редактирования, который у меня когда-либо был. Больше ничего не может быть и близко. Lisp больше не является неудобным для написания языком, заставляя меня беспокоиться о балансировании множества раздражающих глупых скобок. С ParEdit единообразная структура Лиспа становится огромным бонусом для работы, поскольку одни и те же преобразования дерева - прихлебывание, прерывание, разделение и объединение - работают везде, как в структурах управления, так и в структурах данных. А ParEdit предохраняет меня от глупых ошибок. Делать синтаксические ошибки становится практически невозможно.

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

(В общем, Emacs работает настолько быстро, насколько это необходимо. В отличие от Eclipse, который похож на набор текста с помощью клея.)

Следующее, что я обнаружил, был Ясниппет ( http://emacswiki.org/emacs/Yasnippet ). Опять же, раньше я ничего подобного не использовал. Не просто макрос для добавления шаблона, а динамическая форма с возможностью навигации.

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

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

Долговечность - Vim / Emacs - это FOSS и существуют уже несколько десятилетий. Их использование не будет снижаться, а их функции не будут сильно ломаться / исчезать / сильно изменяться, поэтому вы можете рассчитывать на построение всего своего карьерного инструментария на владении только одним редактором.

Удаленный / повсеместный доступ в терминалах. Хотя в обоих есть прекрасные системы для редактирования удаленных файлов, вы также можете установить их в любой системе, в которую вы когда-либо входили.

Разработка на основе REPL - оба имеют режимы «SLIME» в различных формах, которые объединяют любой тип REPL, с которым вы работаете. Например, я никогда не встречал такой мощной итеративной разработки, как та, которая предоставляется CIDER .

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

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

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

Навигация - теги, paredit-like, метки, окна, вкладки, прыжки vim-rails и многие другие встроенные функции.

Менеджеры пакетов / репозитории - у Emacs есть несколько (elpa, melpa, marmalade), и Vim тоже хороши (vundle, pathogen и т . Д. ). Я не знаю сообществ вокруг IDE, которые предлагают что-либо подобное. Я вижу более 5000 пакетов с расширением package-list-packages.

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

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

Бесконечно настраиваемый - Elisp - очень мощный язык для расширения / изменения Emacs. VimL - это эквивалент Vim. Об обоих написаны книги. Настраивайте цветовые темы и поведение к своему удовольствию!

Одним из преимуществ консольных редакторов перед редакторами графического интерфейса является то, что их можно запускать в терминальном мультиплексоре, таком как screen или tmux . Почему это хорошо?

• Быстрее переключиться с одной консоли мультиплексора терминала на другую, чем переключаться с одной консоли графического интерфейса пользователя на другую с помощью мыши или даже с помощью alt-tab. Это связано с тем, что консолям можно давать имена и переключаться между ними путем ввода нескольких символов имени.
• Если ваши сеансы редактора находятся в консолях терминального мультиплексора, вы можете получить к ним доступ с любого компьютера. Если мне нужно поработать из дома, я могу использовать ssh в своем ящике, подключить уже запущенный терминальный мультиплексор к моему сеансу ssh и быть там, где я остановился, когда ушел с работы.

Поскольку vim / emacs часто используются программистами и как пользователь C # с 2003 года, из-за этого предубеждения справедливо сделать это, иначе нечестное сравнение (другим может быть VS C ++ с Visual Assist X против 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. Есть много мелких функций, но со временем они перестают работать. Последний раз я проверял, что функция прыжка не работает, но это было пару лет назад. VS представила новую функцию графического перехода, которую я использовал вместо этого. Требуется мышь или прикосновение.

3. Вот где побеждает emacs / vi. Если вам нужно много прыгать в коде, функции VS для этого либо не существуют, либо недостаточно протестированы.

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

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

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

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

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

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