Vim / EmacsはGUIテキストエディタに比べてどのような生産性向上を提供しますか？

これは、トロールやフレームベイトなどを意味するものではありません。私はVimをコンソールエディターとして数か月間使用しています（ターミナルで構成ファイルを編集するため）が、Webアプリケーションを作成する通常の日常の作業には耐えられないと思います。 、これはGUIテキストエディターで行います（重要ではありません）。

私のGUIテキストエディターは私の仕事に必要なすべてを行うことができるように感じます。それは両方のためのオートコンプリート履歴でまともな検索/置換を持っています。構文の強調表示、行番号、タブ付きインターフェイス、簡単なコピーと貼り付けなどがあります。現在のエディターに欠けているのは正規表現のマッチングだけですが、正規表現の検索/置換を行うGUIテキストエディターはたくさんあります。

今言ったことを考えると、Vim（またはEmacs）は、すべてのコンピューターにインストールされているという事実を除けば、GUIテキストエディターよりも生産性に優れています。Vim / Emacsでより優れた/より速い特定のタスク、または既存のGUIテキストエディターでは不可能である特定のタスクが欲しいです。

Vimの場合：

• Vimは、ほとんどのエディターよりも他のツール（シェルコマンド、スクリプト、コンパイラー、バージョン管理システム、ctagsなど）との統合が優れています。:.!コマンドの出力をバッファにパイプするなど、のような単純なものでも、ほとんどのGUIエディタにはありません。

• タブ付きインターフェースは、Vim / Emacsが提供する「ウィンドウ付き」インターフェースほど良くありません。2つ以上のファイルを同時に並べて表示できます。画面上で見ることができるほど、変数名や関数シグネチャのメンタルブックキーピングを行うのではなく、問題について考えることができるようになります。

• Vimの正規表現の力を過小評価しないでください。特定の列、マーク、カーソル位置、特定のクラスの文字（キーワード、識別子）などに一致するVim固有の拡張機能がたくさんあります。

• 統合されdiff、grepプラットフォームに依存しないため、コンピュータを変更するたびに新しいツールをダウンロードして学習する必要はありません。

• （列を編集するための）ビジュアルブロックモードは、多くのエディターに欠けているものですが、これがないと生きていけません。私はこれだけを使用して仕事で人々に衝撃を与え、畏敬の念を起こさせました。

• 複数のコピー/貼り付けレジスタ。クリップボードが1つしかない場合は、クリップボードを壊さないようにするために、奇妙なゆがみが発生します。あなたがする必要はありません。

• Vimの元に戻す/やり直しシステムは無敵です。Vimはスタックではなく取り消しツリーを使用するため、何かを入力して、元に戻したり、何かを入力したりしても、最初に入力したものを元に戻すことができます。他のほとんどすべてのプログラムでは、最初に入力したものの履歴はこの状況では失われます。

• Vimでは、テキストの移動、コピー、貼り付け、削除が非常に高速です。コマンドはシンプルで、1回のキー操作で構成できます。注意深く面倒なマウスの強調表示とCtrl-Xを実行するすべての時間を合計し、それらすべてをaに置き換えますda(（一致する括弧のセットとその中のすべてを削除します）。思ったより時間を節約できます

• 以下のようなささいなこと、*カーソルの下の単語を検索する、または.コマンドを繰り返す、または%開閉括弧の間にバウンスします。リストするにはこれらの数が多すぎます。

• 組み込みのスクリプト言語と強力なキーマッピングおよびマクロ機能により、必要に応じてエディターを拡張できます。多数のスクリプトが既に作成され、ダウンロード可能です。

よく見ると、他のエディターにも備わっている機能でさえ、Vimの方が優れていることがよくあります。すべてのエディターには構文の強調表示がありますが、Vimにはほとんどすべてのファイル形式用の構文ファイルがあり、多くの構成オプションが含まれていることが多く、独自の構文を作成するのは簡単です。多くのエディターはさまざまなファイルエンコーディングを処理できますが、Vimはファイルエンコーディングを設定し、それらの間で変換する非常に具体的で簡単な方法を提供します。Vimについて私が感動した最初のことは、当時問題があった他のエディターと比較して、タブ/スペースのインデントオプションとUnix / DOSの改行をどれだけ完全に処理するかです。

これらのポイントの多くは、Emacsにも同様に適用されます（異なるが通常は強力な方法で）。

（vimは私の毒です。emacsでも同様の効果が得られると思います）

最大の利点は、マウスに触れる必要がないことです。

私にとって、最も便利なのは、特定の文字または文字の組み合わせに（または直前に）ジャンプするか、2回のキーストロークでジャンプすることです。同じ条件で2回、または10回前にジャンプすることは、単に数値の前に付けることです。

編集を繰り返す必要がある場合は、その場所（2〜3回のキーストローク）にジャンプしてから、「」を押します。最後の編集を繰り返す。同じ検索条件であれば、前方（または後方）へのジャンプが1回のキーストロークで簡単です。

基本的に、短いリードタイムで、10〜20のキーボードショートカットを学習できます。つまり、マウスをつかむために手をシフトし続ける必要はありません。これにより、マウスをつかむ必要があった場合に比べて、3倍または4倍の編集動作/コマンドが得られます。

数日後、<Down>GUIエディターでマウスに手を伸ばす（または15回押す）必要があるたびに不機嫌になります。

なぜVimに夢中になる人が少ないのかといつも思っていました。実際のVimパワーユーザーのビデオをご覧ください。

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

現在の編集者が彼がしていることを実行できる場合、切り替える必要はありません！:)

また、こちらをご覧くださいhttp://www.viemu.com/a-why-vi-vim.html

ビデオを見てその記事を読んだ後、私はVIMを学び始めるしかありませんでした。私がVIMに切り替えてからほぼ1年になりますが、他に何も使用することは想像できません。

専用のテキストエディターの本当の力の1つは、マクロ編集です。繰り返しは多くのプログラマにとって苦痛であり、適切なマクロを書くことは境界線を面白くすることができます。キーボードですべてを実行していない場合、マクロを作成するには、すでに使用しているコマンドを利用するのではなく、追加のコマンドセットが必要になります。

私はviのキーバインドにある程度長けていますが、全体的にEmacsを好みます。これらのエディターに熱心な支持者がいる理由は、彼らが提供する編集モデルが新しいシステムよりも強力であるためです。そのため、拡張機能を使用していなくても、「viキーバインディング」または「emacsキーバインディング」を提供するだけでは不十分です。またはemacsまたはviのカスタマイズ。

Emacsのモデルについては、よく理解しているので、ここでのみ説明します。今日のテキスト編集の一般的なモデルには、テキストのバッファーが含まれます。このバッファーでは、テキストを挿入、削除、選択し、システムのクリップボードに切り取り/コピー/貼り付けできます。

もちろん、Emacsバッファーはこれらの操作をサポートできます。表示されている各ウィンドウのカーソル位置を追跡するだけでなく、ウィンドウ内で作成された「マーク」も追跡します。「ポイント」（カーソル位置）と「マーク」の間のテキストは「リージョン」と呼ばれ、主流のエディターでの選択にほぼ対応しています。

違いは、Emacsはマークリングでマークが設定された最後のいくつかの位置を追跡し、キーストローク（または構成によっては2つ）でそれらに戻ることができることです。特に、バッファー内の場所を変更する多くのEmacsコマンドが古い場所にマークを設定するため、これは非常に便利です。例は、Pythonモジュールを編集していて、ファイルの先頭にimportステートメントを追加する必要がある場合です。バッファーの先頭に移動するためのキーストローク（Alt- <）がマークを設定します。importステートメントを追加します。Ctrl-u Ctrl-Spaceを押すと、元の場所に戻ります。これを繰り返して前のポジションに戻ることもできます。（多分私はそのインポートステートメントを追加するときにいくつかのテキストを選択する必要がありました。）

Emacsのもう1つの（そしてよりよく知られている）違いは、killリングです。バッファからテキストを削除するためのほとんどのキーストロークは、テキストをキルリングに保存します。キルリングは、「yank」コマンド（Ctrl-y）で呼び出すことができます。重要な機能は、後続のyankコマンドが古いkilledテキストを取得することです。したがって、テキストの複数のセクションを続けて削除してから、それらを順番に取得できます。ヤンクの後にAlt-yを使用してキルリングを循環させ、取得したテキストを削除してリングに次のエントリを挿入することもできます。

Emacsには1978年にこれらの機能がありました。それらをある程度まで採用した他の唯一の主要なシステムはNeXTStepです（現在はCocoaに継承されています）。他のツールは、特定のタスクにより多くの機能を提供し、Emacs Lispよりも使いやすい言語で拡張でき、優れたビジュアルインターフェイスを備えていますが、Emacsはテキスト編集に優れています。ですから、使い方がわかれば、やめるのは大変です。

これは特定の作業ではありませんが、RSIに苦しんでいる可能性のある人々にとって、手がキーボードをvimから離さないという事実はほとんど価値がありません。実際には、マウスが届くまで手を動かさなくなったため、仕事中にマウスを左に動かしてしまいました（自宅のキーボードにはテンキーがないので、右に置いておけます）。

もう1つの小さな利点は、IIRC、元のviが、非常に遅いリモート接続を介してファイルの編集を高速化するように設計されていたことです。今日はほとんど起こりませんが、接続が遅い場合は、GUIテキストエディターを実行して応答性を高めてください。

私にとって大きな生産性は

• 私はキーボードからほとんどすべてを行うことができます。
• 強力なマクロ。
• 9つのOSを使用している20年間のキャリアでは、基本的なキーボードバインディングは変更されていません。私はほとんどすべてのシステムに期待でき、すでにエディタの使い方を知っています。
• テキストエディタに必要な機能のほとんどがすでに追加されています。

vim で私が本当に気に入っているのは、「repeater」コマンドです。基本的に、.コマンドモードでを押すと、最後のアクションが繰り返されます。これは、「プログラマーのテキストエディター」が持つ、GUIにはない機能のほんの一例です。

私の経験では、vimとemacs（私自身もvimですが、emacsは確かに似ています）が提供する主な生産性の向上は次のとおりです。

• あなたは、することができます（1-キープレス編集ビルドの実行サイクルとインラインドキュメントやタブ補完やその他もろもろのような）現代のIDEが提供するこれらの機能を持っていますが、しないでくださいする必要が。生産性向上？見たいだけ見る。私の経験では、IDEはあまりにも多くの情報（すべての種類のブラウザー）を表示したため、人々の生産性を向上させませんでした。この「余分な力、必要なときに-すぐに」は、生産性を大幅に向上させます。

• エディターはプログラマーの間で非常に人気があります。つまり、スクリプト、書籍、ユーザーグループの巨大なリポジトリが利用可能です。

• 私の経験では（ここではvimについてのみ話せます）、平均的なvimユーザーはかなり優れたソフトウェアエンジニアです。それがなぜなのかはわかりません（あるいは私が幸運なだけかもしれません）が、emacsやvimのような「古い」ツールに慣れ親しんだ人は、適切な献身をしているでしょう（そして、そのような他の人に連絡をとっています） ）。多分それはこれらのエディターの間接的な影響かもしれませんが、例えばIRC上の他のvim（またはemacs）の人々との付き合いは、同じ人々があらゆる種類のソフトウェアエンジニアリング（またはコンピューターサイエンス）の問題にかなり興味を持っていたため、非常に興味深いことが判明しました。これらの編集者は、ある種の個性を引き付けているようです。:-)

小さなプログラムに軽量のemacsクローンを使用することで得られる「生産性の向上」は、油を塗った稲妻のように起動することです。通常、Visual Studioが「サンドボックス」ソリューションの読み込みを完了する前に、C＃で簡単なテストプログラムを実行できます。

もちろん、Visual Studioを開いたまま（または、そのときに作業している場合は別の VSを開いたまま）にすることもできますが、しばらくアイドル状態にしておくとスワップアウトされます。

重要なサイズのものがあれば、または私がかなりよく使用しているAPIがわからない場合は、IDEが前進です、IMO。

私はWindowsでgvimを使用しているので、技術的にはGUIテキストエディターですが、vimです。

生産性の向上のために、私は次のことを見つけました。

1. マウスを使う必要がないので、速度が向上します。
2. 検索、置換、コピー/貼り付けなどはすべて、vimキーバインドとマウスの動きよりも高速です（学習曲線を超えた後）。
3. 前のコメントで述べたように、RSIは大幅に削減されます。vimに引っ越してから、手首に感謝しています。
4. 軽量で高速です

ご存知のように、viについては、挿入モードとコマンドモードがあると思います。カーソルや特殊キーに頼ることができなかった時代への逆戻りのように見えるかもしれませんが、それが実際に意味することは、多くの強力なモーションおよびテキスト操作コマンドが最小限のキーストロークであることです。生産的なコーディングは、大量のテキスト入力（「モダン」エディターのデフォルト）ではなく、大量のテキストのバーストに続いて、かなりの微調整とさらに長いブラウジング期間が続きます。

これは、高レイテンシのキャンパスネットワークで個人的にviを使用しているときに私にとって最も重要なことでした。応答の前に10文字または15文字を簡単に取得できます。viを使用すると、これらのコマンドがどこを離れるかを快適に予測でき、ほぼ通常の速度で作業できます。このねじれた専門知識は、通常の条件下での継続的なメリットです。一定のグラフィックフィードバックに費やされる視覚的な能力が低下します。

ありふれた*および＃ワード検索アクセラレーターは、コードをめくるのに最適です。また、括弧を一致させるための％は非常に便利です。確かに、ctl-]に比べてほとんどのようには見えませんが、キーストロークの半分が追加されます。

個人的には、私はwinviを使用しています。16進モードにすばやくジャンプすると、多くの「地獄が何をしているのか」というテキストの問題が解決されます。そして、行末の完全に柔軟な処理は、テキストエディタに期待される機能となっている天の恵みです。最後に、内容に関係なく任意のファイルを開くことができます。これは、最初の注文のエリートハッキングスキルに相当します。

Unixでは、プログラムの出力をすばやくキャプチャしたり、外部コマンドを使用してファイルのセクションをフィルタリングしたりすることもできます。非常に強力ですが、十分に活用されていない機能だと思います。

私はVimをよく使用しています。私にとってUltraEditの代わりにはなりません。多くのポジティブがリストされているので、私は穀物に反対し、Vimのいくつかの不快な点をリストするでしょう。

• 弱いFTP処理。私は多くのサイトを「ソート」し、リモートFTPサーバー上のファイルを簡単に参照および編集できないことは、私にとって大きな欠点です。NWReadは十分ではありません。
• Linuxを悩ませているように見える一般的な端末の問題から受け継がれたコンソールの奇妙さ。私は通常、PuTTYを使用してLinuxボックス（Ubuntuを実行）に接続します。何らかの理由で、矢印キーは挿入モードでA / B / C / Dにマップします（およびカラーサポート全体の問題）。gVimでは、ctrl-tabを「bn」に簡単にマッピングできますが、コンソールモードではマッピングできないため、このような問題は山積しています。
• 検索/置換オプションは非常に弱く、インターフェースに関しては優れています。すべてを1行に入力するだけでは十分ではありません。実際の正規表現のサポートがはるかに弱い場合でも、UltraEditを使用すると、最終的にはるかに強力になると思います。
• 米国のキーボードレイアウトへの依存が強すぎる。`などの主要な機能に使用される多くのキーは、デンマーク語のキーボードレイアウトでは印刷されません（そして、アークワードのように、$と同じように配置されています）。一部の関数を使用するのがかなり面倒になります。

リモートデスクトップでは、ネイティブのWindowsアプリケーションのみがすばやく表示されます。Eclipseを使用してUNIXでの開発を試みました。そして、あなたは何を知っていますか？それさえ不可能でした。

2つ目の理由は、VimsとEmacsを拡張して、DBブラウジングからすべてのプロジェクト固有のタスクを特別な方法で実行し、独自のメタ言語を強調表示して自動完成させることができるためです。

大きな利点の1つは、vimエディターの拡張性です。CVSで何かを動作させたい場合は、CVSMenuプラグインを使用してエディターに追加し、その機能を取得できます。

構文の強調表示、特定のファイルでの動作なども同様です。vimではあらゆる種類のものが調整できます。

GUIタイプエディターでこれほど簡単にできるかどうかはわかりません。

VIMでの記録と再生は、GUIベースのツールで見つけることはほとんどありません。

また、自動インクリメント/デクリメントにより、プログラムを作成せずにデータ生成機能を利用できます。

私は何年にもわたってEmacsを絶望的に使っていました。しかし、実際にはそれに入りませんでした。それから私はClojure（私の最初のLisp）を学び始め、ParEditを発見しました。

そして、それは私の心を吹き飛ばしました。

（いくつかの例についてはこちらをご覧ください：https : //www.youtube.com/watch?v=D6h5dFyyUX0）

Lisp + ParEditは、私が今まで体験した中で最も素晴らしい編集体験です。他には何も近づきません。Lispは、書くのにぎこちない言語ではなくなったので、私は多くの刺激的な愚かな括弧のバランスを取ることを心配しなければなりません。ParEditを使用すると、同じツリー変換（丸呑み、バーフィング、分割、結合）がどこでも、制御構造とデータ構造の両方で機能するので、一貫したLisp構造を操作することで大きなボーナスになります。そして、ParEditは私が愚かな間違いをするのを防ぎます。構文エラーを起こすことはほとんど不可能になります。

そして、Eclipseとは異なり、これは、常にバックグラウンドで実行されてプロセッサーを焼き尽くす面倒なリアルタイムチェックではありません。費用はかかりません... ParEditは、私が求めたときに、正しい構造変更を行うだけです。

（一般に、Emacsは必要なだけ高速です。接着剤を入力するようなEclipseとは異なります。）

次に発見したのは、Yasnippet（http://emacswiki.org/emacs/Yasnippet）でした。もう一度、私は以前にこのようなものを使用していません。ボイラープレートを追加するための単なるマクロではなく、動的でナビゲート可能なフォーム。

最後の喜びは、これを自分で拡張したい場合は、これらの高レベルの生産性向上ツールをもっと手に入れるために、Lisp自体を操作する力があるということです。

（私の経歴は、Visual Studioやその他のIDEで数年、次にVimで15年、そしてEmacsで直近の6か月です。）

長寿 — Vim / Emacsは FOSSであり、何十年も前から存在しています。それらの使用法が衰退することはなく、機能が大幅に中断/消失/変更されることもないため、1人のエディターの習得を中心としたキャリアツールボックスコア全体の構築に依存できます。

端末でのリモート/ユビキタスアクセス —どちらにもリモートファイルを編集するための優れたシステムがありますが、ログインした任意のシステムにインストールすることもできます。

REPL駆動の開発 —どちらの場合も、さまざまな形式の「SLIME」モードがあり、使用しているREPLのタイプを統合します。例えば、私はCIDERが提供するほど強力な反復開発に遭遇したことがありません。

リンティング -あなたはおそらく使用しているどのような言語は、いくつか持っている 毛羽立ちコンパイラや外部ツールに組み込まれているかどうか、ツールを。これらはEmacs / Vimとシームレスに統合され、ほぼリアルタイムでコーディングの誤りを示します。

ニーモニックコマンドの文法 —どちらも習得に時間がかかりますが、これらのエディターは、数千のキーストロークとキーコンボで数千のコマンドにアクセスし、記憶するための有名な巧妙なシステムを備えています。こうすることで、マウスを使用する必要性を完全になくすことができます。

ビルトインヘルプシステム —多くの言語とそのAPIのオフラインドキュメントは、これらのエディターに組み込まれているのが一般的であり、同様にシンプルな方法で、機能する広範で包括的なヘルプシステムにアクセスできます。オートコンプリートは、ほとんどの一般的な言語に追加されています。さらに、事実上すべてのヘルプトピックに関する豊富なディスカッションヘルプがあります。

ナビゲーション —タグ、pareditライク、マーク、ウィンドウ処理、タブ、vim-railsの ジャンプ、その他多くの組み込み機能。

パッケージマネージャー/リポジトリ — Emacsにはいくつか（elpa、melpa、marmalade）があり、Vimも良い（vundle、pathogen など）。これらに匹敵するものを提供するIDEの周りのコミュニティは知りません。で5,000以上のパッケージが表示され package-list-packagesます。

単なる編集を超えて — Emacsは、ニュースを読んだり、ウェブを閲覧したり、電子メールを管理したり、スプレッドシートを編集したり、プレゼンテーションを作成したり、あらゆるものを整理したりする機能を備えています。

その他すべてを統合 —デバッガ、ブラウザの同期、コンパイル、シェル、テスト実行。

無限にカスタマイズ可能 — Elispは、Emacsを拡張/変更するための非常に強力な言語です。VimLはVimと同等です。両方に書かれた本があります。色のテーマと動作を微調整して楽しみましょう！

すべてのコンソールベースのエディタがGUIエディタよりも優れている点の1つは、screenやtmuxなどのターミナルマルチプレクサで実行できることです。なぜこれが良いのですか？

• マウスを使用して、またはalt-tabを使用してGUIコンソール間を切り替えるよりも、ターミナルマルチプレクサコンソール間を切り替える方が高速です。これは、コンソールに名前を付け、名前のいくつかの文字を入力することで切り替えることができるためです。
• エディタセッションがターミナルマルチプレクサのコンソールにある場合は、どのマシンからでもアクセスできます。自宅から仕事をする必要がある場合は、自分のボックスにsshを実行し、すでに実行中のターミナルマルチプレクサをsshセッションに接続して、仕事を辞めたときに中断したところに戻ることができます。

2003年以降、vim / emacsがプログラマーやC＃ユーザーとして頻繁に使用されているため、このバイアスpovから、これ以外の点では不公平な比較を行うことができます（別の方法は、VSC ++とVisual Assist Xの比較vs vim / emacsのC ++です）。

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機能が存在しないか、十分にテストされていません。

マウスベースのGUIナビゲーションの問題は、

a）非常に静的な位置に座っているのと同じように、おそらく悪い場合、マウスは指も静的な位置に置く傾向があります。私の手首の痛みはトラックボールへの変更で消えました。私は最初に垂直マウスを試しましたが、問題は何もしませんでした。

b）理想的なキーボードにはテンキーのない2列のファンクションキーがあり、トラックボールをより近くに配置できるため、ジャンプ距離がより耐えられます。

ただし、最終的に、特定の場所の間を行き来したい場合は、「マークリング」の方が効果的であることは明らかです。VSはそれらの線に沿って何かを持っています...最後に私がそれを使用しました、それは確実に機能しませんでした...

c）そして、リリースごとに壊れる小さな機能がたくさんあるので、これはVSの欠点です。

この「クローズドソース」の問題の解決策：VS全体をC＃で記述し、ソースを解放せずに、コンパイルされたコードの変更/編集を可能にします（実行時に、オプションで次の起動時に読み込まれるパッチとして変更を保存します）。これは、デコンパイラーにコードを出力させることで実行できます。ネイティブコンパイラーの動作から180度です。次に、バイナリがソースコードと実行可能ファイルになり、代わりにこの.csファイルや.exeファイルなどの混乱が発生します。これをほぼ実行できるサードパーティのツールが既に存在するため、C＃exeの「改造」はかなり簡単ですが、これを実行することをお勧めします論理的な結論：.exeと.dllにコメントも含めます。コンパイルされたC / C ++アプリと比較すると、ファイルはまだ小さいです。最適化？事前に最適化されたコードを含めることもできます。アプリの実行中にmodderがexeを変更すると、変更されていない「AST」とそれに付随する最適化されたバイナリがプラグインされます。C＃コンパイラと同じアイデアですが、さらに使用されます。次のステップ：OS全体をこの言語で記述します。これにより、Windowsがクローズドソースであっても、すべてのバイナリにソースコードが付属しているため、簡単に変更できます。環境の設定、コンパイル、リンクは不要です。実行中にOSを変更するだけです。類推：Common LispでWebブラウザーを作成した場合、Webブラウザーを停止せずに編集して、ブラウザーと同じ言語でWebページを作成できます。ソースコードはすべてのバイナリに付属しているため、簡単に変更できます。環境の設定、コンパイル、リンクは不要です。実行中にOSを変更するだけです。類推：Common LispでWebブラウザーを作成した場合、Webブラウザーを停止せずに編集して、ブラウザーと同じ言語でWebページを作成できます。ソースコードはすべてのバイナリに付属しているため、簡単に変更できます。環境の設定、コンパイル、リンクは不要です。実行中にOSを変更するだけです。類推：Common LispでWebブラウザーを作成した場合、Webブラウザーを停止せずに編集して、ブラウザーと同じ言語でWebページを作成できます。