内部再プログラム可能性

プログラミング中に、現在入力している行の上に空行を追加したくなりました。使用していたエディターにはこの機能が組み込まれておらず、ついにこの要望が十分に高まったので、本当に必要になりました。簡単なグーグル検索で数行のコードを見つけ、それをスタートアップファイルに貼り付け、実行したところ、キーを1回押すだけで上に空行を作成できるようになりました。数分しかかかりませんでしたし、プラグインをインストールしたり、エディターを再起動したりする必要もありませんでした。これはEmacsユーザーにとっては日常茶飯事です。

Emacsは古いソフトウェアで、1970年代半ばまでさかのぼります。ライブ環境を修正することで簡単に拡張できるようにするという哲学は、LispマシンやSmalltalkなど、他にも古いながらも画期的なシステムと共通しています。

その哲学は現在では珍しくなっているようです。確かに、拡張可能なシステムはたくさんあります。FirefoxのようなブラウザやEclipseのような編集スイートにプラグインをインストールできます。フリー/オープンソース運動全体は、マシンを実行するコードにアクセスできるようにし、理論的には好きなように調整できるようにすることです。しかし、これらの環境のほとんどの拡張機能と、EmacsやSmalltalkで行う再プログラミングの種類には、明確な違いがあります。上記で追加した新しいコマンドのように、小さな変更をすばやく簡単に行えるということです。また、環境を離れることなくそれを行うことも重要です。Emacs関数を追加するために別のツールチェーンを起動するのではなく、Emacs自体の中で作業します。

これは、何らかの「マクロ機能」を追加するツールとも異なります。新しいelisp関数を追加することは、Emacs自体がプログラムされている方法とまったく同じです。小さな拡張機能をプログラムする方法と、ソフトウェアのコアプログラミングとの間に違いはありません。この一体性により、エディターの内部に深く手を伸ばすことができます。また、変更が何らかの「スクリプト」メニューに追いやられるのではなく、ツールの他の部分と区別がつかないことも意味します。

この機能は、ツールとの関係性に関する哲学でもあります。多くの人にとって、使用するソフトウェアは比較的固定された製品です。プラグインでさえ、比較的限られたメニューのオプションを追加します。内部で再プログラム可能なツールを使用すると、ソフトウェアの任意のパーツを追加または変更できるため、比喩的に言えば、自分の手にぴったり合うようにツールを作成できます。

この考え方は、プログラミング言語自体にも当てはまります。LispとSmalltalkはどちらも、言語拡張がコアとまったく同じに見えるように言語を簡単に拡張できる最小限の言語です。どちらの言語にも、条件付きロジックのような基本的な言語機能に対する特別な構文はありません。この柔軟性により、Smalltalkは言語を変更せずに例外処理を追加することができました。

内部再プログラム可能性に関する最大の課題の1つは、ソフトウェアのインスタンスが断片化してしまうことです。Emacsインスタンスを多くの個人的な関数で変更すると、自分のマシンのEmacs構成に密接に結合された独自のカスタムバージョンのEmacsが作成されます。必然的に、これにより、コアアプリケーションのアップグレードへの対処や、関数を他の人と共有するのがいかに簡単かという疑問が生じます。

プラグインアーキテクチャとマクロ言語を備えたシステムは、カスタマイズの表面積を減らすことでこれに対処していますが、Nic Ferrierがうまく言ったように、「再プログラム可能なシステムは非常に強力です。力を乱用することは常に可能であり、再プログラム可能なシステムでは、人々がそれを乱用できることが原則です。」

もちろん、Emacsコミュニティは、これが実際にどのように進展したかを示す良い例です。Emacsは十分に安定しており、定期的なアップデートにもかかわらず、ほとんどの人が深刻な問題なくアップグレードできます。Emacsはパッケージ管理システムを使用して、共有可能な変更を配布するのに役立ってきました。元のEmacsとSmalltalk時代から、コードを共有する方法について多くの進歩がありました。分散型バージョン管理ツールの台頭により、共有コードを管理するためのアイデアが増えました。

ほとんどの開発者にとって、おそらく内部再プログラム可能性の哲学に最も近いのは、Unixコマンドラインシェルでしょう。これは、誰もが新しいコマンドを簡単に作成し、組み込みのコマンドと区別がつかないようにシステムに追加できるため、これの（単純な）例だと考えています。パッケージを使用すると、より多くのコマンドを追加して、コマンドライン環境を特定のニーズに合わせて調整できます。コマンドラインの対話モデルはEmacsやSmalltalkほど豊富ではないため、それらの環境が提供するもののごくわずかな反映にすぎませんが、その経験のヒントを与えてくれます。

プログラマー向けのツールでは内部再プログラム可能性がまれである場合、プログラマー以外向けのツールではさらにまれです。私はそれが変わるべきかどうかをよく疑問に思いました。より多くのツールにこの品質を持たせると、何が得られるでしょうか？これにより、より多くの人々がプログラミングについて学び、多くの時間を費やす環境をより適切に制御できるようになるでしょうか？これは確かに、アラン・ケイのダイナブックのビジョンの一部でした。彼は子供たちをメディアの受動的な消費者としてではなく、積極的に環境をプログラミングする存在として見ていました。

プログラミングは簡単ではありませんし、プログラマーが日々直面する課題を過小評価するつもりはありません。しかし、それは内部再プログラム可能性が1970年代の未来のビジョンに追いやられるべきであることを意味するものではありません。現代のダイナブックがケイのビジョンの内部再プログラム可能性を欠いている理由の大きな部分は、それが十分に高い優先度になっていないからです。おそらく、それについてもっと考える必要があるのでしょう。