[MD:6272] Discussion about our mission. (was: stay tuned!! our mission will be stated by himi)

[MIYASHITA Hisashi (宮下 尚:HIMI) <himi@xxxxxxxxxxx>]

年の終わりは近づいてくるというのに、今年忙しくて放置していたことを片付けつつ
論文などを読みつつ、なぜか部屋中の掃除や配線の変更をし、あーそういえば永野さんに、
まずい宿題を約束をしてしまったなぁと思いつつ、そろそろMeadowのmission statementを
まとめないとなぁというわけで、Meadow 2の開発のほとんどを行ったThinkPad i1124を
取り出したら、HDDがまるで足りないことに気づきHDDを換装してほっと一息ついてる
ところですが、皆さん如何お過ごしでしょうか。

Missionを考える前に、Meadowの開発の原点を軽く振り返ってみるのも悪くないと思います。

大体、Mule for Windowsの開発が一段楽して、私が次に何を目標にしたかというと
Mule for Windowsで放置された多言語処理をもう少しまともに考えてみようかなと
いうことでした。これが、大体、1996年頃のことでした。

1996年頃は、Emacsの方もだいぶ面白いことになっていました。当時の電総研のMule
Projectは、MuleとEmacsの統合化作業に邁進しており、Mule 2.3も大きく作り変えられて
Emacsに統合化していく上で、様々な機能の変更や拡張が行われていた時期でした。

これは、多言語処理という目標と、Emacs 20をWindowsでも実装するという目標が自然に
一致していたという大変よいタイミングだったので、Mule for Windowsにも
いったん一区切りという意味をこめて1997年にMeadow Projectを始めることとなりました。

その後のProjectの流れは、皆さんもご存知のとおりです。
まぁ、いろいろあったというわけです。^^;;;

Meadow 2は、私が陰でこそこそやっていた実装を林さんに宴会で挑発されて、
それからわずか1月たらずで外に公開されてしまったという特異な歴史も
持っていますが、目標という意味ではMeadow 1こそがMeadowの真の目標でした。
そして、その後の蓄積があったからこそMeadow 2が出てきたともいえましょう。
それは、私だけでなく、communityが少しずつでも広がりを見せてきていて、
様々なcontributorの層が厚くなってきたからともいえます。

## みんながいなかったらMeadow 2は永遠に世の中に出てこなかったでしょうね。

とはいえ、すでにEmacs 20, 21ともにNTEmacsという実際のところのoriginalの
GNU Emacsでも、Meadowの目標としてきた機能は実現されることになりました。
我々は、NTEmacsの選んだデザイン・チョイスとは異なった方向を選択することに
なりましたが、既にMeadowは、GNU Emacs自身を鏡にするという意味では、
明確なProjectの方向性とはなりえなくなっています。せいぜいEmacs 22のUnicode対応が
待っているぐらいですが、これは、GNU Emacsとsync. upを行い、Win32 APIのbindingを
考えるぐらいの作業で終わる話です。それはそれで結構面倒かもしれませんが、目標と
いうにはちょっとつらい。

世の中を見渡してみると、時代は大きく進んでしまい、ある意味でGNU Emacsによる
convensionalなデザインは、最近の機能を実現する上では大きな足かせとなっています。
例えば、concurrent処理や、component modelを実現する上で、GNU Emacsのある意味で
古い設計は厳しい障壁となっていると言わざるを得ません。

しかし、だからといって、このEmacs LispやGNU Emacsによる膨大な資産を捨てることは、
我々には選択肢として残されているようには思えません。もし、そんなことを今更、
夢見るのならば、相当量の血を流す覚悟がいります。^^;;;; 

originalのGNU Emacsの開発を見ていても、ある意味で進むべき方向性を明確に
見出しているとは言いがたい状況です。言い換えると、私を含む相当数の人々が、
現在の機能に、それなりに満足してしまっていて、そこから逃れるには、
相当のエネルギーを必要としているといえます。

これは、ものすごく大きな山を越えれば面白いことが出来るかもしれないし、
普通のことをやっていても、たいした目標にはならないという、ちょっとつらい
状況と見てもよいのかもしれません。

とはいえ、Projectの目標には面白さが必要だと思っています。それも、最小限のコストで
最大限の効能が得られるような目標が必要です。

そのためには新しい血を入れる必要がありそうだという気がします。

自分の身の回りを振り返ってみると、私が今、Meadow以外に最も使っているツールは、
実のところEclipseだったりします。Eclipseは、高度にコンポーネント化された構造を
持っていて、非常に大きな拡張性を持っています。また、Eclipseのコンポーネントは
非常に様々なところで活用されています。例えばEMF。これによるモデルは、今後Eclipse
以外にも利用されることになるでしょう。他にもJDIのcompilation partは、
tomcatに持ち込まれることになりました。

## 自分でもいろいろplug-inを書いてみましたが、やっぱりかなりよく出来ていると思います。

こういう状況を見ていて、コンポーネント化は、ひょっとすると、このMeadowを取り巻く
閉塞感に対する解になるのかもしれないと考え始めました。

もしかしたら、コンポーネント化すれば、もっと面白いことが実現できるかもしれない。
うまくdisplay engineだけ取り出せば、それなりのコンテナになるかもしれない。
interaction処理部分だけ取り替えられれば、Emacs Lisp Engineだけ取り出せれば、
process処理部分だけ取り出せれば...?

これは、結構面白そうだし、何よりstep-by-stepで実現できそうな気がするんです。

もっとも、この目標の場合、初期はどうしても実験にならざるを得ないと思います。
今のごちゃごちゃのろくでもないEmacsの内部構造をきちんと整理するのは、相当
大変な作業です。その場合でも、Meadowの場合には、originalのGNU Emacsの部分だけ
とりあえず閉じ込めてコンポーネントに出来ればいいなぁと思ってはいるので、少し
やりやすいところはあるかもしれません。ただ、Emacs Lispの部分だけは何とかしないと
いけないんでしょうけど...。

そういうわけで、Meadowの次の目標を開放系のシステム作りに持っていけたら面白いと
思っています。実際、GNU Emacs本体の開発者はEmacs Lispと違って、非常に少ないと思います。
その理由の一端は、モノリシックな非常に拡張のしにくい構造にあったのではないかと
考えているところです。Emacs Lispに少し限界が見えつつある昨今、一つ下がって
考えてみるのも面白そうだと思います。

具体的には以下のような目標を考えています。

0 ... GNU Emacsをベースにしたオリジナルとの互換性維持は大前提。

1 ... Meadowの拡張部分のコンポーネント化を進める。GNU Emacs部分の保守性を損なわない形で
      インターフェースを定義することを試みる。

2 ... 外部開放系との連携作業を進めよう。

? ... もしかしたら、GNU Emacs本体のコンポーネント化もできるかも?

実際、我々のprojectは、ある程度曲がり角にきていると思います。ここらで、新しい
missionを明確化しておいたほうがいいようには思ってはおりました。問題は、その
missionを考えているとかいうやつの手がまるで動いていないことにあるんでしょう。
来年はある程度コードがcontribute出来たらいいなぁと考えてはいるんですが、
今の状況じゃ、もうしばらく先のことになりそうだなと思いつつ、来年に向けて
努力をしていきたいなと思っております。

Meadow Projectで蓄積された資産を有効活用しないのは、まったくもって
もったいないことだと、いま、Meadow 2を開発するのに使ったThinkPadで作業をしながら
感じています。

# こいつもだいぶキーボードが傷んでしまって、時々反応しないキーがあるんですが、
# まだ頑張ってもらいましょうか。^^;;;

それでは、皆さんよいお年を。

from himi