APEL 問題、再燃？

1999年 11月 5日 (金) 00:03:28 JST

## あらかじめいっときますが、私はAPEL擁護派の立場です。
## ただ、それが嫌いな人だっていたって良いとのスタンスも
## あると。

将来的にXEmacsまわりのプログラムも始めたらAPELを使い出すように
なることは想像に難くありません。

tomo ＠ etl.go.jp (守岡 知彦 / MORIOKA Tomohiko) writes:

> himi> まあ、外野の茶々ですが、今回の件を端から眺めている立場では、社会
> himi> 的な対立点を軸にしていると見るのは、早計に過ぎると感じますし、そ
> himi> のような視点で物を眺めることは、決して有益にはならないと思います。
> 
> これが最初ならそうですが、技術的・開発体制的回答を行った上ですから。
> 
> ;; とはいえ、私が書いたことは誇張した意見です。だってその方が盛り上が
> ;; るでしょう？:-)

# ん、まあ、そうなんでしょうけど。対立軸がこの方向にいくと悲しいかなと。
# APELのせいでSKKのコミュニティが分裂する必要はないと思うんですね。

## あと、個人的には、どうしても、安易な社会的、人間的考察を拒否する
## ものが私の内心にはありましてね。

## 正直に言って、ソフトウェア開発において、その対立軸が出てくると
## かなり泥沼の道にはまると思う。

> himi> Library作成者には、それなりの意図があって、APELを取る立場もある
> himi> でしょうし、取らない立場もあるでしょう。それは、閉鎖指向、から来
> himi> ていると一概には言えないと思います。とくにLibraryをMinimizeする
> himi> 立場からいくと、APELのようにmacroの山で置き換わるシステムは、趣
> himi> 味に合わないということは想像に難くはありません。
> 
> 一般論としてはそうです。
> 
> ;; 特に、Steve はその立場から APEL に批判的です。（しかしながら、APEL 
> ;; の目的を批判している訳ではありません）

んーと、私は批判しているというより、そういうのが嫌いって人もいるだろうと。
### でも、W3のやり方は、はっきり言って不意打ちみたいで嫌い。

> himi> また、正直に言って、APELのInterfaceの定め方は直感的には程遠いも
> himi> のがありますし、個人的には紛争状態の中立地帯、のように見えます。
> himi> もちろん、それは悪いことではありません。むしろ、APELの延命の為に
> himi> は良い方向に働いていることの方が多いでしょう。Emacs間の聖戦(?)が
> himi> 続く以上はAPELのような、Emacs Abstraction Layerの存在は、有益に
> himi> 働くとは思います。
> 
> APEL やその前身に当たる部分を５年間やって来た経験からの感想では、構成
> を綺麗にすることには限界があり、APEL では悪の限りを尽くし、上位層を綺
> 麗にすることに専念した方が結果的に効率的であると思っています。

この判断は、私も正しいと思います。

> もっとも、
> 
> emu	--- 全部
>   poe	--- Mule 以外
>   poem	--- Mule 関連
>     pces	--- CES (coding-system) 関連
>   pccl	--- CCL 関連
> pcustom	--- custom 関連
> 
> という分け方は判りにくいとは思わないんですが。どういう点が直観的じゃな
> いんでしょうか？

私はファイル構成が直感的(念の為、直観的ではない。)でない、といっているのでは
ありません。Interfaceの定め方が直感的ではない。と、主張しています。
それは、APELの責任というよりも、Emacsの歴史的発展の所産といえます。

char-lengthを使うのは、Emacsの差違に頭を巡らせていないとできないでしょうし、
set-buffer-multibyteとか、XEmacsの人にはなんじゃそれ？でしょう？

あと、pcesだけでは、coding-systemのporatabilityは実はなくって、
mcharsetを使わなくてはならないという点も、厳しいものがあります。

それは、かなりの部分はAPELの責任ではありません。でも、Emacs間の差違に
どんな物があるのか、ある程度の把握が必要なのは、仕方ありませんよね。

# 個人的にはAPELにはEmacsに対するかなりの知識が必要なのだと思っています。
# それを好ましいと思えれば、かなり良い環境なのだろうと思っています。
# 逆にそれになれられないとつらいというかんじがしますね。

# もう一つ、そこに慣れられる人だったら、
# 自分で作りたいという誘惑に勝つのは難しいのだと思うのです。
# 往々にして。^^;;;

> himi> ただ、私はあまり直線的解決に見えないのです。それは、APELで吸収さ
> himi> れているEmacsen間の違いは、表層的なものにとどまっており、
> 
> おうおうにして問題は表面的なところで起こっています。例えば、UTF-2000 
> を除けば、従来の全ての Mule 実装の中身は概ね同じでした。逆に XEmacs
> UTF-2000 と XEmacs Mule は中身の意味は非常に異なっていますが、表面的に
> 同一にすれば program はそれなりに動きます。別の例を挙げれば、Common
> Lisp, Scheme, Emacs Lisp の３者では関数の意味的には多分 Common Lisp と 
> Scheme が近くて Emacs Lisp は遠いでしょう。しかしながら構文の近さから
> Common Lisp でも Emacs Lisp でも動く program は書きやすいですが、
> Scheme とでは難しいです。可搬性にとって重要なのは実は表層的な部分なの
> です。

まあ、これには納得いくところもあります。某MUAで最も問題になった点は
実は quoteの問題だったりしますし。

しかし、表面的な問題は、しばしば解決が容易にできる問題であることが多く、
本質的な問題は、解決が容易ならざる事が多いとは、Emacsの開発で感じています。
つまり、Emacsにおいて、その実現があるシステムにEssencialな問題であるならば、
他のシステムで実現することが、しばしば非常に困難に陥ったりするのです。

> himi> 結局はEmacs開発の側に働きかけた方が、長期的な視点からは有益であ
> himi> ろうことが多いと思うのです。
> 
> これはその通りです。また、実際そう思って Emacs と XEmacs の双方に働き
> かけていた時期もありますし、一定の成果を得られたと思っています。
> 
> ;; しかしながら、うまくやらないと双方のいたばさみになる。(^_^;
> 
> ただ、一般論としていえば、意味のない差異は統一すべきですが、発展のため
> の差異は積極的に支援すべきだと思います。
> 
> 実際、最近、Ben Wing さんの病状が少しだけ回復したとのことで、彼を中心
> に XEmacs Mule のデザイン/API/実装を全面的に再構築しようという話が持ち
> 上がっています。Mule Project もこの試みを支援するようです（もっとも人
> 的支援が十分にできないのが悲しい所(^_^;）。
> 
> 意味のある差異を支援するために APEL は役に立つと思います。

これは、Yes and No、では一部あるんですが、90%近く、これはNoだと思います。

わざわざ、差違を作るということは、その差違を認識したLibrary作成者でないと、
そのmeritを生かすことができません。

*-maybeなどで、APELで吸収することが役に立つことは確かですが、それは、あまり
重要なことではないでしょう。逆に、単なるEmulation機能を作ってしまっては、
差違を作成したmeritはないと思います。もしくは、APEL実装を軽減してくれるような
方向にAPELを変更するとかいう方向に向かうこともあるのかもしれませんが、
現状そういう事は、非常に難しいと思います。

APELで重要なことは、やはり、意味のない差違、本質的ではない差違、古い
Emacsenの腐った機能、欠けている機能を吸収してくれる点であり、この点は
高く評価されてしかるべきだと思います。

逆に、Emacsenの泥沼にはまりたければ、APELのお世話にならないことは非常に
有益であろうと思います。:-P

> himi> 結局のところ、APELを使うかどうかは、今回の件に限っていえば、かな
> himi> り、SKKを用いる人たちの個人的環境嗜好の問題であろうと私は思いま
> himi> すし、それ以上の社会的考察を加えるべきではないというのが、私の主
> himi> 張です。
> 
> himi さんの洞察は基本的には間違っていないと思います。
> 
> しかしながら、APEL の実装の問題点とは別に、複数の application 間で共有
> するという動きに関する逆風のようなものを感じています。

私は、某MUAのような「車輪の差違発明」の発見ならぬ、再発明は、嫌いなことですし、
有益なものは共有されてしかるべきだと思います。ただ、その為に必要なのは、
社会的な問題は、おそらく無視されても良い問題だと思うのです。

むしろ、作成者が、冷静な立場で、現在存在するSoftware Productを見とおせるかに
かかっています。それに、もちろん人間的、社会的なbackgroundが影響を
与えることは百も承知です。だけど、良い「技術者」として、仕事を成す時に
現在存在する「技術」「資産」を把握するなんてことは、基本中の基本でしょう。

また、今回の件でいうならば、そんな事を云々するようなレベルではきっとな
いと信じたいところですし、もし、それを持ち出すところまで話が悪化してい
るのなら、もう、私なんかが何を言ったところで無駄なのでしょうし。

> 例えば、custom は確か Gnus から派生しましたが、複数 application 間の共
> 有物として進化したと記憶しています。日本語圏からもこうした動きが起こる
> と楽しいと思います。

ですね。

> しかしながら同時に社会的・人間的問題を無視するのも好ましくないと思いま
> す。

たぶん、この地点で、私と意見が違うと思うんです。
普通、この様な議論で出てくる時に、そのような社会的、人間的backgroundは
よほど、対立点が深まらない限り、議論の対象にしては、焦点がおかしくなるから、
消去して考えるべきだと思います。

そりゃ、人間生きてきたらいろいろあるわけで、そんなbackgroundなんて
考慮していたらきりがありませんからね。

> やってくれないから嫌とか、問題が生じる*かも*知れないから嫌という姿勢よ
> りは、技術的な問題をみんなでわいわいがやがややりながら直して行く方が私
> は好きです。

そういう事を考えても、むしろ、APELにおいて、積極的な利点を打ち出して、
技術的な説得に当たるという方が、個人的には好みです。

個人的には、人間の問題にすりかえるのは、半分敗北宣言であるとも思うのです。

from himi