2003/12/18

#permalink

新しいことをする場合、最適な仕様というものが、作ってみるまでわからないということはままある。実際に作って、動かして、使ってみて、直して…と、粘土をこねるみたいにして形を作ってゆかざるを得ない。ただ、どちらに向かうべきかがはっきり見えなくなることが時々ある。こういう作り方をしている時は、テストもコードに合わせてどんどん変化してゆくので、テストドリブンというのも(方向を決めるのには)あまり役に立たない。

そんな時は、ドキュメントを書いてみると役に立つ。ある程度形が出来てきたところで、そのAPIのマニュアルを書き下してみるのだ。すると、自分の中で整理がついていないところは、綺麗に説明が出来ない。不必要に長い説明を必要とする場合は、方向がおかしいと判断できる。逆に、APIをこう変えれば説明しやすい、というアイディアを得ることもある。

最初にちゃんとした仕様を書いて…という形式との違いは、既に動くものが手元にある状態で、それを説明するために書く、ということ。

Tag: Programming

2003/12/11

#permalink

RFC:2822ってまじめに扱おうとするとめんどいなあ。ところでstructured fieldはどうしたってCFGなんだが、誰かがアドレスをパーズするPerlのregexpを書いてたよなあ、どうやったんだろうと思ってぐぐってみたらあった。うーん変態的。でも良く見たら「コメントはあらかじめ取り除いておく」って書いてあるじゃん。コメントはネストするからRGじゃ無理だよな。そうか、残りはgroupがネストすることはないからRGでいけるのか。

Tag: Programming

2003/12/02

#permalink

チュートリアルについて。バカが征くより:

以前、Javaの強みはコミュニティにあるといいましたけど、その特徴の1つが Java Tutorialです。これはSunがやってるのでコミュニティの力というと叱られそうですけど。でも、Java Tutorialがあるおかげで、「何かを作ったらチュートリアルを用意する」というのがJavaの文化として摺り込まれちゃったんですよね。Jakartaを見ても、チュートリアルのないシステムはありませんし。

そうだなあ。布教には重要なのだろうなあ。個人的には、チュートリアルの類は滅多に見ない。チュートリアルというのはどうしても性質上"How to"が中心になりがちな印象があって、でも本当に知りたいのは"Why"なので、読んでていらいらさせられることが多いから。いや、そうでない良いチュートリアルもあるのだろうけど。 "The Unix Programming Environment" みたいに、WhyとHowを絶妙にブレンドしたドキュメントが書ければベストだと思う。

ちなみにその前のCLOSに対する記述は、まさしくそのとおり。

CLOSはとても歴史のあるシステムとは思えません。CLOSが世に出てからもう10 年以上経ってますよね。にもかかわらず、この情報の少なさは一体どういうことですか。
Paul Graham氏の"ANSI Common Lisp"なんて上っ面をなでてるだけ。Web上のチュートリアルもいくつか見ましたが"Common Lisp Cookbook"が、まぁマシかという程度。結局"Common Lisp HyperSpec"を見なきゃなんないなんて状況はおかしいですよ。こっちは仕様書が読みたいんじゃなくて、使い方が知りたいんですから。

似たような状況はCLIMにもある。すごいシステムだと思うんだけど、まともなドキュメントは仕様書しかない（自分も使ったことは無くて、仕様書読んで感心して、部分的に実装したりしただけだけど）。

LISP/Scheme界隈はまだユーザー＝実装者な空気が強くて、仕様書があれば使える&実装できるって状況に甘んじちゃっているんだろうな。それじゃ裾野がひろがらないからダメなんだが。

あー、Gauche-0.7.3ではオブジェクトシステム周りのドキュメントを多少充実させる予定。あくまで予定だけど。

Tags: Programming, Lisp

Comment (1)