backquotes

[Katsumi Yamaoka]

>>>>> In [apel-ja : No.01447] 守岡知彦 / MORIOKA Tomohikoさん wrote:

>> これは単に見栄えだけの問題ではなくて、コンパイル時にわんさか警告
>> が出るプログラムの場合、真にバグに対して出された警告をも見なくな
>> る害があると思っています。

> grep を使うとか、log を filtering するのはいかがでしょうか？

警告を隠すという行為が、大事なものまで出力されないようにしてしま
う恐れがあるという点では、どちらも同じですね。で、プログラムの側
で隠蔽してしまうのはより責任が重いですから、ぼくは Gnus に仕込ん
だその手のものを不定期にチェックして、不要になった隠蔽を取り除く
などしています。

>>> ;; 個人的には、機械的書き換えに対して、上記のような心配を持ってし
>>> ;; まうので。あくまで、個人的印象なので、人それぞれだとは思います
>>> ;; が。

>> 機械的書き換えには違いありませんが、変更の大半はいろんな角度から
>> 検証済みです。「機械的」の意味は、例えば macroexpand の新旧の結
>> 果を比較することです。

> 実装前（書き換え前）に検証することは当然のことですが、それとは別に、書
> き換えた code 自体もチェックした方が良いと思います。トリビアルな変更で
> あっても、思わぬミス（あるいは、事故）はありうる訳ですから、code を書
> き換えたら cvs commit する前に必ず diff を見ることは必要ですし、動作を
> チェックすることもなるべくやった方が良いと思います。

> ;; 本当はテストスイートがあれば良いんですけども。

> ;; ちなみに、CHISE の文字データベースを書き換える時は、どんなわずかな
> ;; 修正であっても、コンパイラなんかと同様な不動点チェックを通過するま
> ;; で cvs commit しないという方針を取ってたりします。その上で、差分も
> ;; チェックします。

ぼくも必ず ediff を使って確認するようにしています。問題は動作チェッ
クで、特に入力されるデータによって切り替わる機能の膨大な組合せの
すべてを想定できなかった場合に、想定できなかったこと自体が後でわ
かることはありますね。そのためにも過去に起きた問題を対象にしたテ
スト治具があるのは良いことだと思いますし、dgnushack.el には実際
の例がいくつかあります。もっとも今回の変更に関しては、マクロの展
開結果が変更後でも同一であれば良しとしました。

>>> とりあえず、FLIM の変更に関しては、まず、emacs-mime-{ja|en} で議論
>>> してからやるのが良いんじゃないでしょうか？

>>> ;; 枝の持ち主以外がいきなり commit するのは望ましくない気がします。

>> 変更に際しては提案し、評決を経て実施するというルールを忘れたわけ
>> ではないのですが、それはすでに崩壊していると思います。いったい、
>> 有益な議論が行なわれたことが何回あるでしょうか?
>> そもそも何か変更を行なう人は、その人の尺度で十分に煮詰めたものであろ
>> うし、それを他者が詳細に検証するのを待って実施するのでは非常に効率が
>> 悪いでしょう。ぼくもそうですが、そのとき興味が無ければ「それでいいん
>> じゃない」すら言わないし、唐突に出てきた提案をすぐにみんなが検証して
>> くれることを期待するのは無理があります。特に、深刻な問題提起を繰り返
>> すユーザーに対してすら誰も反応しない現状では、そんな手順に意味がある
>> とは思えません。cf. [emacs-mime-ja : No.02148]

> emacs-mime-{ja|en} に投稿するのは、第一義的には『有益な議論』をするた
> めではなくて、記録を残すためです。これは、現在の私のように、すぐに反応
> できない人にとって、極めて重要なことです。これをやらないと
> 「cf. [emacs-mime-ja : No.02148]」というように、指し示すこともできませ
> ん。

はい、emacs-mime-ja ではなく apel-ja だけで変更の予告を行ない、
変更したことの報告をメールでしなかったのは問題でした。FLIM のリ
リースの話もあったので、今回の変更は取り下げました。

> 反論がなければ実施すれば良い訳ですし、time out の期間は自分で決めるこ
> ともできます。cvs commit しなくても開発はできます。さらにいえば、自由
> に自分の枝を作ることだってできます。flim-1_14 枝に commit する前に一言
> その意図を書くというのはそんなに非効率なものでしょうか？重要だったり
> 深刻だったりするなら、なおのこと記録に残すべきじゃないでしょうか？

枝を作る必要は感じなかったのですが、そもそもぼくが無意味だと思っ
ているルールがまだ活きていることを尊重しなかったのはすみませんで
した。

> ;; また、『その人の尺度で十分に煮詰めたものであろう』から良いとするの
> ;; は、ソフトウェア工学的にはちょっとまずい主張ではないかと思います。

確かに完成度は人それぞれ状況それぞれなので、CVS commit という行
為が、さらに客観的に検証して煮詰めるために俎上に載せることと同義
だと思っています。おそらく守岡さんの基準に依れば、ぼくは Gnus を、
ひいては Emacs を alpha 化しているのでしょう。Emacs 22.1 のリリー
ス直前に RMS の求めに応じて小規模でない変更を行ないましたし、リ
リース後に発覚したバグをいくつか修正しています。

> ;; それから、信頼性よりも開発を優先するフェーズ（例えば、開発用の枝）
> ;; では、効率を重視した方が良いと思いますが、枯れたソフトウェアでは信
> ;; 頼性を重視した方が良いと思います。そして、それは工学的には、プロセ
> ;; スによって保証するものではないかと思います。

> 少なくとも、flim-1_14 枝および将来の（開発枝 (status = alpha) ではない）
> 『公式枝』に関しては、従来の方針通り、（メインテナー以外の人が）事前の
> 宣言なしに cvs commit するのは止めて欲しいです。

わかりました。どうも意見の違いから、同じ話を何度もしているようで
すね。守岡さんにはたくさんの字数を尽くして相手をさせてしまい、申
し訳なく思っています。
-- 
山岡