Shiro:log:2003後半

Shiro:log:2003後半

Shiro


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

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

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

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

(2003/12/02 14:07:56 PST): チュートリアルについて。バカが征くより:

以前、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ではオブジェクトシステム周りのドキュメントを 多少充実させる予定。あくまで予定だけど。

(2003/12/01 02:12:08 PST): 10年くらい前に関わっていたプログラムが オープンソース化されたそうな→http://www.oyukibo.com/kohoan/ もう番組には使わないからってことなんだろうな。

(2003/11/09 00:23:26 PST): いよいよR6RS始動か?。何年かかるかわからないが。→ Scheme Workshop 2003 Notes

(2003/11/01 18:57:40 PST): Scary: Shark maims surf star

(2003/11/01 05:13:25 PST): Wataru's memoで今度は uPD765 (FDC) の話題が。 私が参考にしたのは別冊トランジスタ技術special No.11 「フロッピ・ディスク・インタフェースのすべて」だったな。 今も手元にある。昭和63年9月発行だ。 トラ技別冊にはずいぶんお世話になった。

Fascinating: How Hercules Beat the Hydra.

(2003/10/24 20:59:17 PDT): /.-J 経由でトースターPC (このサイトには他にもいろんなPCがある)を見て、 Wataru's memoで8ビット時代の話を読み、 昔を懐かしく思い出したので、写真を掘り出してみた→Shiro:OvenPC

(2003/10/19 19:19:39 PDT): YAMDAS現更新記録経由で 新山さんの日記をみる。そうか、 NYに行くんだったらお会いすれば良かったなあ。でもILC前後は忙しそうな記述が あるからどのみち無理だったかなあ。

Wataru's memoで74181のこと。 中学生の頃は憧れだったなあ。74181と、確か74シリーズで64bitくらいの SRAMがあって、それといくつかのゲートを組み合わせてプロセッサができるよなあ と回路図を引いて夢想していた。

しかーし。ハード小僧の夢、今からでも遅くはないかもしれん。 今ホットなのは組込み系Schemeだ。Marc Feeleyは100円ショップで買った 小指の先ほどの電池入れを加工してワンチップCPUとLEDをくっつけて Schemeを走らせていたし、湯淺先生はMindstormのH8でSchemeを走らせていた。 むむ、手元に何故か未使用のAKI80セットが数枚ある…

(2003/10/17 03:26:12 PDT) ILC2003より帰還。 からじゃないよ。

今年はFranz Incは運営に関わらず、 ALUが全面的に運営することにしたそうだが、 色々あってかなり運営はぐちゃぐちゃだった (c.l.l等参照のこと)。 が、集まった面子は相当なもので、それだけでも行った価値は充分にあった。 Phil Wadlerがlambda calculusとSchemeの関係に言及したらすかさず フロアからSussmanが突っ込みを入れたり、Paul GrahamがLispの起源に触れたら すかさず最前列にいるJohn McCarthyが突っ込みを入れたりとか。

Grahamと直接会ったのは初めてだった。意外とかわいい話し方をする。 トークは彼のが一番面白かったかな。Kiczalesのトークも、 (正しいかどうかは別にして)AOPで彼が目指しているところがわかりやすくて 良かった。湯淺先生はデモに使ったLego MindstormをSussmanにあげて、 かわりに"MIT Nerd Pride"のバッヂをもらっていた。いいなあ。

論文はちかぢかwebに上げる。またproceedingsが出るまで時間がかかりそうだし。

(2003/10/06 18:14:04 PDT): Another nice analogy between programming language & vehicles.

From Ray Dillinger: Re: CL & Practicality:

Common Lisp and Scheme are both like All-terrain vehicles; it's just that Scheme is more like a dune-buggy or ATV and CL is more like a bulldozer. The surveyors and explorers are going to go out with light nimble vehicles that can handle the terrain and find routes to problem solutions that exactly fit the needs of the problem. But no two of them are likely to find exactly the same route, or to be able to share substantial parts of the routes they find, except that they will talk with each other about the terrain and features.

When civil engineers want to build roads they follow with earthmoving equipment, which can also "handle" the terrain, although in a different way, and create routes that are a lot easier for later people to drive on or switch between.

(2003/09/24 18:54:23 PDT): From Philip Greenspun's Weblog:

(2003/09/23 04:34:06 PDT): なぜ翻訳書はダメなのか?: 翻訳には翻訳ならではのスキルや創造の余地があるんで、 自著が書けない人が翻訳をするというのは少し極論かもしれない。 (オリジナルと翻訳とは頭の使う場所が違うのでバランスを取るのにいいと 言ったのは村上龍だったっけ)。

むしろ、健全なフィードバックが作られにくいというのが翻訳の質を 上げにくい理由ではないか。原書が読める人は翻訳を手に取ってその 質を調べたりはしないから、まずい翻訳がけなされることは少ない。 一方で良質の翻訳をしても、原書の評判を上げこそすれ、 翻訳が広く褒められることはあまりない。

皆が原書を読めるならそれでも良いのだけれど、翻訳書の必要な場面が 無くなるとも思えない(自分も日英以外はほとんど全て、どちらかへの翻訳で 読んでいるし)。翻訳を評価するという行為がもっと一般的に なれば良いのかもしれない。でも、原書読んでから翻訳読むのは二度手間で 億劫なのは確かなんだよなあ。

なにぃぃぃっ→yomoyomo in Tokyo Reloaded。 その時間は東京にいたのに。 RHG読書会とハシゴすればよかった。

(2003/09/17 05:34:57 PDT): ありゃ。Erann Gatの裏だ。生Erannが見られないのは残念だが、 去年みたいに朝イチじゃないのは助かった。

(2003/09/15 01:48:21 PDT): 「コードの再利用」ってのはオブジェクト指向アプローチの メリットとしてよく語られてたけど(最近はそうでもないか)、 実は関数指向アプローチの方がずっと コードの再利用がやりやすいように思える。

OOのコード再利用ってのは、 誰もがagreeできるような性質を持つオブジェクトに対しては可能だけど (stringとか、GUIコンポーネントとか)、そういうものはむしろ少なく、 同じものであっても見方によってモデリングの方法が変わって来ることの 方が多い。全ての見方に対応しようとするとインタフェースが爆発する。 色んな見方で組み立てられるように、要素を分割してモデリングして、 使うときに必要なものだけ集めてやろうとしても、継承使うなら 多重継承やmixinの嵐、コンポジションでやるのも小さなオブジェクトの 管理がめんどい。

関数指向は、ものの操作のみに注目する。 Scheme:オブジェクト指向表現でちょっと話が出たけど、 例えば木のトラバースをする関数は、(1)対象物がleafであるかどうか、 (2)対象物の子ノードへ操作をマップ、の2種類の操作さえ与えられれば、 対象物が何であるかは知らなくてよいし、そもそも対象物が 木としての動作を本質的に備えている(e.g. treeインタフェースを持つ)ことさえも 要求しない。本来は木じゃないものを、たまたま一時的に 木として見たくなった、といった場合に、呼び出し側はその場で 上記(1)(2)の操作をでっちあげれば、トラバース関数が使える。

言い替えれば、関数指向では、全てのコンポーネントは、対象物に対して何も仮定を 置かなくて済むということだ。なぜなら必要な操作は呼び出し側が提供して くれるから。従って、汎用的な操作を部品化する時に「それが誰に、どのように 使われるか」を気にせずに、アルゴリズムのみに集中できる。

オブジェクト(クラス)指向はむしろ、具体的な問題が与えられた時に、 関数指向で用意された部品を集めて具体的なものを実現する際の骨組みとして 大いに役に立つ。 そういう骨組みは問題毎に異なるから、 多くのクラスはその問題専用に作られ、再利用されることはない。

つうわけで、「部品はFP」「アプリはOO」ってのが結構いいんじゃないかと 思う次第。

Shiro: ここでのOOは言語の話ではなくて、モデリングやデザインの話です。 (だって関数指向とオブジェクト指向を混ぜる話になってるでしょ。 FPと言ったのがまずかったか)。 Java, C++はクロージャ相当のものがすごく書きにくいため混ぜにくいんですが、 ブロックを持つ動的なOOPなら両方の書き方が可能ですし、 そういう前提で話をしています。 で、OOPでも汎用的なライブラリにしようとすればするほど、 ブロックを多用する傾向があるんじゃないかなあと。 respond_to? でディスパッチする(=データにいちいち問い合わせる)より、 ブロックで渡してもらう(=操作を外部から提供してもらう)方が 綺麗だし柔軟性があるよなあと。 C++でもtemplateを多用してゆくとどんどんそっちの(関数的な)方向に向かうんじゃ ない?

ここで言っている関数指向では、あるデータを扱うある操作Aを実装しようとしたとき、 データに対して仮定を置くのではなく、操作Aを実装するためにデータに対して 必要となる操作B, C, ... を呼び出し側から提供してもらう、ってことです。 データに対する仮定は間接的に操作B, C,...により与えられますが、 操作Aにしてみれば、そもそも最初からデータが分離可能な形で 存在しなくたって構わないわけで。

(例えば、「木構造」が単なる2つの整数の配列でC[i]とS[i]で表されているような場合を 考えてみよう。ノードは単に整数のインデックス k で表現される。 C[k]はノードが子を持てば最初の子のインデックスを保持し、そうでなければ -1を保持する。S[k]はノードの次の兄弟へのインデックスか、兄弟が なければ-1を保持する。このデータ構造に、ルートノードのインデックスが 与えられれば、これは立派な木構造だ。 さて、Scheme:オブジェクト指向表現の関数版tree-walkをこの構造に 適用するのは簡単だ。リンクトノードで表現された木の場合と何ら変わるところは ない。一方、tree-walkが、渡されたノードに対するメソッド呼び出しを使う、 よくあるOOベースで作られていたらどうなるだろう。何らかの中間オブジェクト、 一時的なオブジェクトが必要になるのではないか。それは、クロージャが自動的に やってくれることを手動で模倣することになるだろう)

「何かが有り、何かを保持している」ことをモデル化するには、 その「何か」の見方を決めなければならず、そういう見方は既に アプリケーション依存なんじゃないか、ということです。 だから、アプリケーションから出発する場合はOOモデリングはうまく機能するけど、 具体的なアプリケーションとは独立して部品を作るなら、操作中心に ならざるを得ないのでは。

なお、私は Object == Closure (mod Syntax) な立場ですので、 あるものがオブジェクトか関数かを分けることはできないと考えています。 設計の段階で、どっち側から見るのが便利か、という話をしてます。

(2003/08/27 02:50:02 PDT): PS2で一般的なn×m行列を扱う場合、quad wordに揃わない 場合の処理をごちゃごちゃやらなくちゃならないんで、VU使ってもあんまり 速くならない。COP1でアキュムレータをうまく使った方が速いこともある。

SIGGRAPHで会ったMさんとも話してたんだが、年喰ってくると アセンブラを触るのがだんだん億劫になる。 面白さはまだ感じるのだが、 やたら時間を取られるのがたまらんと思うようになってきた。 知識を得るにつれ、やりたいことは増える一方で、やれる時間は減る一方だから、 開発効率を上げていかんと話にならん。

(2003/08/08 12:54:53 PDT): Unix User 9月号に スパムメール関連の記事を書いた。 コメントや質問等はShiro:UnixUser0309へどうぞ。

(2003/08/06 01:54:08 PDT): SIGGRAPH はそれなりに刺激的であった。 あとはアイディアを形にするだけだが、体力の要る作業だ。

SIGGRAPHの後の週末をちょいと拡張して、南カリフォルニアを ふらふらしてきた。宿を決めずに行き当たりばったりの2人旅。 金曜はLa Jollaのmotelに泊まられたのだが、 土曜夜はSan DiegoからCarlsbadまでの全ての海岸沿いの街の宿で断られ、 内陸ならばどうかとEscondidoからI-15を南下するも全滅。 夜中近くなり焦りも出てきて、電話をかけまくるもSan Diego近辺のホテル、モーテルは 完全にアウト。夏の週末を甘く見ていた。電話のための小銭も尽きて、 ダメもとでかけたHiltonの予約センター(フリーダイヤル)で 「San Diegoから最も近い宿でお取りできるのはPalm Desertになります。 San Diego中心からは87マイル離れていますが…」と言われた時は、 もうどこでも良いから取らないと夫婦の危機という状況であった。 一気に砂漠の真中へと車を飛ばして、2:00am近くにチェックイン。 翌日はPalm Springsあたりをゆっくり見て回って、結局Palm Desertに二泊して、 LAに戻ってLAXからHNLへ。終わってみればなかなかエキサイティングな旅だった。

(2003/07/27 13:21:20 PDT): 昨日LAXに着いて、LAの友人の車に同乗させてもらってSan Diegoへ。 綺麗な街だなあ。

相変わらずSIGGGRAPHの会場は猛烈に寒い。 冬の日本に行く時に持って行く上着を着込んでいる。

(2003/07/25 20:51:34 PDT) オブジェクトの広場のインタビューは、 受けた人が次のインタビューイを紹介してゆくというしくみになっている。 そこで、大学・大学院の同期の 佐藤隆君に 登場してもらった。 彼は覚えていないかもしれないが、私はUnixのUの字も知らない時に、 彼からftpコマンドを教わったのだ。 あとCP/Mについてもいろいろ教わったな。

あちこちで書いているが、GUIを記述する言語として私が最もエレガントだと 思っているのが、彼が学部時代に作ったオブジェクト指向prolog処理系、 SLOG/GOLSである。 なんとかあのエッセンスをうまく抽出してSchemeに乗せられないかと、 ずいぶん長く考えている。

(2003/07/11 04:21:32 PDT) 転職と無職じゃえらい違い (Matzにっきより )。 うーむ。こっちの業界では、「えらい違い」という程の印象は ないような気がする。転職しない方が少数派なんじゃないかと思うくらい、 みんなあっちに行ったりこっちに行ったりしてるし、 その合間にunemployedな状態になることも普通だ。 「おー久しぶり。今何してる?」「うーん、ぶらぶらしてる」って 会話が全然珍しくないからなあ。 (まてよ、ひょっとしておいらのまわりだけか?)

unemployedと言っても、レイオフによりやむなく、だったり、 単にひと仕事終えてちょっと休みたい、だったり、 ちょっとアイディアがあるからしばらく誰にも雇われずにやってみて ものになりそうかどうか見てみる、だったり、色々あって一概には言えないけど。 でも、ある程度以上キャリアのある人のunemployedな状態ってのは 個人事業ってのとたいして差がないようにも思える。

雇われていたって、この御時世、先がどうなるかさっぱりわからないし。

まあ、不景気の影響は勤め人よりも個人事業の方がずっと大きいから、 全く差がないわけじゃないけど。個人的には、勤め人をやめたことによって 生活に一番影響が大きかったのは、医療保険だ。 self employedだと、あんまりいい保険に入れなくて、 勤め人時代にかかっていた歯医者と眼医者で保険がきかなくなってしまった (こっちの保険は色々あって、種類によりかかれる医者が決まっている)。 ちゅうわけで、長い目で見たらやっぱり自営業でもちゃんと軌道に乗せて、 いい保険に入れるようにした方がいいんだろうなあ。

More ...