APEL 問題、再燃？

[Miyashita Hisashi (=?ISO-2022-JP?B?GyRCNVwyPBsoQiAbJEI+MBsoQjpISU1J?=)]

Mikio Nakajima <minakaji ＠ osaka.email.ne.jp> writes:

> > 個人的な感想を述べれば、APEL という system の技術的な問題が対立点なの
> > ではなくて、閉鎖指向と共同指向という社会 system 観の対立なんだと思いま
> > す。特に、日本では『国際競争人間力』、互いに対立したり協調しながら 
> > system を協同して作り上げて行く力、が足りない人や、そういうのにコスト
> > を払うのを嫌う人が多いように思われます。
> 
>   ぼくもそれを声を大にして言いたいです。例えば、APEL/SEMI/FLIM を共有
> しているプログラムの議論で、共通の話題であっても、自分が最も感心のある
> プログラムに閉じた議論をしようとする意図を感じたときは強い反発を覚えま
> す。

まあ、外野の茶々ですが、今回の件を端から眺めている立場では、社会的な
対立点を軸にしていると見るのは、早計に過ぎると感じますし、そのような
視点で物を眺めることは、決して有益にはならないと思います。

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

また、正直に言って、APELのInterfaceの定め方は直感的には程遠いものがあ
りますし、個人的には紛争状態の中立地帯、のように見えます。もちろん、そ
れは悪いことではありません。むしろ、APELの延命の為には良い方向に働いて
いることの方が多いでしょう。Emacs間の聖戦(?)が続く以上はAPELのような、
Emacs Abstraction Layerの存在は、有益に働くとは思います。

APELは、その生まれからして、MIME寄りの処理に偏ったAPIが多く
(もちろん、最近大幅に改善されていることは言を待たないのですが)
改善の余地は多いにありそうですが、大いなる努力の産物であり、
使用することは有益であろうと思います。ただ、私はあまり直線的
解決に見えないのです。それは、APELで吸収されているEmacsen間の
違いは、表層的なものにとどまっており、結局はEmacs開発の側に
働きかけた方が、長期的な視点からは有益であろうことが多いと思うのです。

古いEmacsenをサポートするという命題があるのであれば、APELを使用することは
非常に有益です。まあ、私はあまり古いEmacsenに縛られていることに意味があるか
疑問に思っているからでもあるのですが。

## 某「9月主義」のように、ふるいEmacsenは切り捨てる。との立場が
## 最も好きな私としては、気楽な立場といえば気楽です。
## まあ、つまりは、いろいろな立場があるといいたいだけです。

> ユーザーのフロントエンドに近い方で解決した方が直感的だし、短期的に見れ
> ば効率も良いのは分りますが、それに終始していると (もちろん、フロントエ
> ンドでまず対処の必要なときもあります。wl の y2k 問題しかり...)、中、長
> 期的に見れば共有物の発展が想像以下になってしまう恐れがあると思うからです。
> 
> まぁ、SKK の場合は、ある日突然 APEL required になったのだから、従来か
> らのユーザーの方々には色々反発があるのは分りますが、ぼくは APEL が好き
> だし効率も悪くないと思うので、その一部分を抜き出したりする努力をする時
> 間があれば APEL 全体の発展の為に貢献したいです。

結局のところ、APELを使うかどうかは、今回の件に限っていえば、
かなり、SKKを用いる人たちの個人的環境嗜好の問題であろうと私は思いますし、
それ以上の社会的考察を加えるべきではないというのが、私の主張です。

APELを使うことの、merit, demeritは、正確に把握されるべきだと思いますし、
その選択がLibraryに与える影響は、決して小さいものではないと思います。
ただ、それを、Library作成者の社会的、人間的な問題に帰趨されるのは、
個人的にあまり好ましいとは思わないのです。

from himi