Emacsの設計は、思想上の理由から、わざと貧弱であるという話。
Emacsの内蔵言語であるelispは、貧弱だそうだ。私はLisp系の言語に詳しくないが、少なくとも今まで出会ったLisperは皆elispは貧弱だと答えている。それにも関わらず、今まで出会ったLisperは全員、LispのコーディングにはEmacsを利用しているのは不思議だ。おそらく、Emacsとその資産を再実装する手間を考えたら、Emacsを使ったほうが得策なのだろう。
elispが近年のLispの進化を反映していないというだけではない。Emacsのelispはマルチスレッドに対応しておらず、ちょっと重い処理をしようとするとユーザーに応答できなくなってしまうし、共通の処理は共有のライブラリとしてまとめるという普通のことが難しく、ファイルI/Oなどの低級なAPIも不足しているという。
自然として、Emacsで高度なことをしようとすると、外部プログラムで実装して、Emacsと何らかのプロセス間通信でやりとりするという実装になる。これには副産物として利点がある。
外部プログラムは好きな言語で実装できるということ。外部プログラムはEmacs内で閉じずに、他の環境でも、バインディングを書くだけで対応できるということ。
これにより、Emacsの高度な拡張機能は、Emacs内で閉じることがなくなる。もちろん、タダで他の環境に対応しているというわけではないが、対応が容易になる。これはUNIX思想とも関係しているのだそうだ。
しかし、最近のEmacsの開発は、どうもこの思想を忘れ始めているので危惧すべきだとのことだ。
聞けば、GCCも似たような思想上の理由が設計に影響を及ぼしているそうだ。たとえば、GCCの実装は意図的にモジュール化されておらず、各機能を容易に分割できないし、各機能間のプロトコルや、入力と出力の間の内部表現のフォーマットも固定された仕様ではない。これは、GCCのうち、例えばパーサーを取り出してエディターのシンタックスハイライト機能として使うとか、パーサーとセマンティックアナライザーだけを使って高度なコード補完処理を行うとか、あるいは入力言語のフロントエンドだけ用意して、最適化やコードへの出力は既存のGCCのものを使うなどといった部分的な利用を困難にしている。
聞くところによれば、これはGCCの部分的に他の不自由なプログラムに流用するのを妨害する目的だという。
また、リチャードストールマンはコンパイル済みヘッダーの実装に反対していたし、またGCCが実装言語をCからC++に切り替えたのも、やはりストールマンの影響力が強いうちは不可能だっただろう。
その結果として、今GCCは、モジュール化を念頭に設計された後発のLLVMの猛烈な追い上げを受けている。
Emacsということで対比されるVimはどうか。Vimでも、やはり内蔵言語のVimscriptは貧弱である。ただしVimでは、Ruby, Perl, Python, Tcl, Lua, schemeといった主要どころのスクリプト言語をサポートしている。このような言語に対しvimバインディング用のライブラリを提供し、Vim側から呼び出して、結果をVimにもってくる。もちろん、これを実装する裏で、Vimのソースコードの汚さにますます拍車がかかるのは事実だし、結局Vimscriptを完全に使わなくてすむわけではないが、elisp一択よりは、個人的にはいいと思う。これはLisp系の文法に慣れないという個人的な嗜好が関係しているのだが。
ただ、Vimでも大掛かりな拡張機能となると、やはり外部プログラムで実装すべきだろうし、根本としては、やはりUNIX思想の影響を受けているのだろう。
ちなみに、件の記事は最近英訳され、Hacker Newsでも話題になっている。私もHacker News経由で逆輸入される形で知った。
英訳：Emacs is Dead (translated from Japanese)
Hacker Newsの反応：Emacs is Dead (translated from Japanese) | Hacker News
Redditでも取り上げられているが、現時点では反応は薄いようだ。
No comments:
Post a Comment