2007年12月30日

冬コミ御礼

 本日の冬コミにて西在家香織派のスペースにお越しくださった皆様に厚く御礼申し上げます。
 香織派は搬入した本が早々に売り切れてしまい、あまりの風と寒さにめげて早退しました。御用のおありだったかたにはお詫び申し上げます。

Posted by hajime at 21:47 | Comments (0)

2007年12月29日

冬コミのお知らせ

 西在家香織派は冬コミ2日目にサークル参加します。西そ-05bにて皆様のお越しをお待ちしております。なお今回は新刊はございません。

Posted by hajime at 19:03 | Comments (0)

2007年12月28日

国際法ハッカー

ピラミッドの著作権
 ベルヌ条約は古くて欠陥だらけで、21世紀を愉快なタコ踊りの時代にしてくれるはずの代物だが、こんな大穴を実際にexploitしてみる加盟国があるとは思わなかった。ベルヌ体制はあと100年は続くと思っていたが、案外短いかもしれない。

Posted by hajime at 23:00 | Comments (0)

2007年12月26日

『BLスタディーズ』をいまごろ読んだ

 ユリイカ 2007年12月臨時増刊号『BLスタディーズ』(青土社)をいまごろ読んだ。
 作品以外の話が多すぎる。もし『ライトノベル・スタディーズ』などという本が出たら、紙幅の大半が作品論に割かれ、作者や読者の人物像などほとんど問題にならないだろう。
 BLは今、まんがに比べて小説に勢いがない(新人が人気を得られないなど)という印象を抱いているが、そのへんの考察が見当たらない。BL作家の人気トップ4(斑鳩サハラ・ごとうしのぶ・あさぎり夕・秋月こお)がろくに言及されておらず、ラウドマイノリティ御用達の木原音瀬が何度も言及されている、というあたりにBL小説界の辛さがにじみ出ている。野村美月(いまだかつて週間ベストセラーリストに登場したことがない)を論じて時雨沢恵一や賀東招二を論じないラノベ論、ほりほねさいぞうを論じて鬼ノ仁や月野定規を論じないエロまんが論、といった趣だ。

Posted by hajime at 00:00 | Comments (0)

2007年12月23日

地層

 TCP/IPスタックを介さずに直接Ethernetフレームを送受信すれば遅延が減るはず、なら低遅延のためにデータリンク層をEthernetとL2スイッチに決め打ちしたプロトコルがあるはず、と思ってぐぐっていたら、こんなものを見つけた。
Ethernet Type Codes
 消滅してしまった企業の数々と、忘れ去られたRFCの数々が並んでいる。
 わざわざEthernet Typeを割り当ててもらうくらいなのだから、それぞれ当時はそれなりに力の入った規格だったのだろう。成功する規格がどれほど少ないかを客観的に見せ付けられて、ため息が出た。
 なお、Ethernet決め打ちプロトコルは現状GAMMA一択のようだが、プロトコルの詳細がどこにも出ていないような気がする。

Posted by hajime at 04:35 | Comments (0)

2007年12月20日

上月司『れでぃ×ばと』がブレイク?:週間ベストセラーリスト動向

 今月17日発表の週間ベストセラーリスト(文庫、日販調べ)によれば、上月司『れでぃ×ばと』が『アスラクライン』『9S』を破ってRを201上昇させ、R1047に達した。ブレイクか。『アスラクライン』『9S』はいずれも手堅い人気シリーズで、比較対象として信頼性が高い。
 甲田学人『断章のグリム』が下げ止まらずランク外。有沢まみずの新シリーズ『ラッキーチャンス!』は、『いぬかみっ!』読者を引き継げなかったと見えて苦しい立ち上がり。

Posted by hajime at 04:37 | Comments (0)

2007年12月17日

血染めのガウン、高温殺菌オレンジジュース、メガビタミン

 大昔、微生物と感染症が発見される前のこと、ヨーロッパの外科医は、血染めのガウンを着て外科手術をした。このガウンはずっと同じ一着を使いつづけ、けっして洗わない。
 血のついていない真っ白なガウンを医者が着ていると、「まだたいした外科手術をやったことがない新米」という意味になる。たくさんの血を吸って赤黒くごわごわになったガウンは、「数々の大きな外科手術を経験してきたベテラン」という意味になる。ガウンを染める血は、医者の経験の証だった。
 微生物と感染症が発見されてからは、血染めのガウンはなくなった。そのかわり、高温殺菌オレンジジュースが現れた。
 食物経由の感染症を恐れるあまり、殺菌していない食物を徹底して避けるようになり、生の果物まで避けて高温殺菌オレンジジュースを飲む、という次第だ。オレンジジュースを加熱すれば、ビタミンCは失われる。日本の有名人では森鴎外がこれをやった。
 ビタミンが発見されると、メガビタミンの登場である。メガビタミンというのは、「必要量以上にビタミンを摂取すると寿命が延びる」という妄想だ。
 
 人間は指標に振り回される。経験→微生物→ビタミン、というわけだ。新しく現れた指標に振り回される人間は滑稽だが、昔ながらの知恵、いわゆる「ベスト・プラクティス」は血染めのガウンかもしれない。
 プログラミングの世界にも、血染めのガウンと思しきものがある。たとえば、「ルーチンの行数を短く(数十行以内に)しておけ」がそれだ。
 Steve McConnell『Code Complete 第2版』(日経BPソフトプレス)上巻213~214ページから引用する:
 
・BasiliとPerriconeによる調査では、ルーチンのサイズがエラーと反比例することがわかった。ルーチンのサイズが増えるにつれ(最大で200行のコード)、コード1行あたりのエラーの数は減っていく(Basili and Perricone 1984)。
・別の調査では、ルーチンのサイズにエラーとの因果関係はないが、構造的な複雑さやデータの量がエラーに関係しているという結果が出ている(Shen et al. 1985)。
・1986年の調査では、小さいルーチン(コードが32行以下)とコストまたはエラーの発生率の減少とに相関関係はないことがわかった(Card, Church and Agresti 1986; Card and Glass 1990)。このことは、ルーチンが大きくなるほど(コードが65行以上)、コード1行あたりの開発コストが下がることを示している。
・450個のルーチンで実験を行った調査では、小さなルーチン(コメントを含め、ステートメントの数が143行未満)は、大きなルーチンよりもコード1行あたりのエラー率が23%高いものの、修正コストは逆に2.4倍も少ないことがわかった(Selby and Basili 1991)。
・別の調査では、コードの修正が最も発生しにくいのは、平均して100~150行のルーチンであることがわかった(Lind and Vairavan 1989)。
・IBMの調査によると、最もエラーが発生しやすいルーチンは、500行以上のものであることがわかった。500行を超えると、エラーの発生率はルーチンのサイズに比例する傾向にある(Jones 1986a)。
 
 200行以内のルーチンを分割すべき理由はない。「ルーチンの行数を短く(数十行以内に)しておけ」というルールは、長いルーチンがいくつかの短いルーチン(どれも1箇所から呼ばれるだけの)に分割される、という結果を生む。これはコードの長さ(=目につきやすい指標)をコールスタックの深さ(=目につきにくい複雑さ)に変換して、バグを増やすだけだ。
 かといって、長いルーチンがよい兆しなわけもない。長いルーチンがたくさんあるのは、悪い設計やコードの重複の兆しであり、「長いルーチンは不吉」となら確実にいえる。指標としては有効なのだ。
 「ルーチンの行数を短く(数十行以内に)しておけ」というルールの問題は、「指標をいじっているだけで、実態は改善どころか悪化する」という点にある。まさに血染めのガウンだ。
 
 どんな分野であれ人間が努力するところには、血染めのガウンやメガビタミンがある。ただ努力するだけでなく成果を出したいのなら、指標に振り回されやすい人間の性質を知ろうと努め、血染めのガウンやメガビタミンと思しきものを日々探すべきだ。このような態度こそ知恵である。
 私はいま、Pete Goodliffe『Code Craft』(毎日コミュニケーションズ)を読んでいる。
 知識はなるほど詰まっているが、知恵のほうは『Code Complete』に及ばない。ソフトウェア工学の知見があまり紹介されていないし、俗耳に入りやすい迷信への反駁も少ない。正直なところ、著者が筋金入りのプログラマかどうかも疑っている。
 本書を読むかどうか迷っているかたには、367ページをご覧になることをお勧めする。私の知るかぎりでは、「hack」には「華麗なやっつけ仕事」というニュアンスがある。膨大な作業量を伴う仕事は、どんなに華麗なものでも「hack」とはいえない。基礎工事のような地味な仕事はなおさらだ。このため、ちっとも華麗でない手抜きしただけの仕事を正当化するために「hack」という言葉が使われることが多く、自称としての「hack」は危険な兆候だと感じている。しかし著者の知る「hack」はそうではないようだ。ああいう綺麗事の「hack」が許せるなら、本書を読んでもいいかもしれない。

Posted by hajime at 21:16 | Comments (0)

2007年12月11日

「中国語の部屋」を作る

 レベッカ・ワーフスブラック、アラン・マクキーン『オブジェクトデザイン』(翔泳社)を読んでいる。
 「中国語の部屋」という思考実験がある。本書を読んでいて私は、この「中国語の部屋」を連想した。
 「中国語の部屋」で注目すべきは、部屋の中ではなく外だ。
 
・中国語
・部屋の外にいる中国語を理解する人間
・部屋を構築・運営する作業
 
 自然言語は社会活動の中にある。形式言語の文には「形式的に正しい」という状態が想定できるが、自然言語にはそれはない。話者の社会の中でどう機能するか、しかない。とすると、「部屋の外にいる中国語を理解する人間」とは実質的に「中国語」と同じものだ。
 話者が世界中に一人しかいない、そしてその話者のほかに資料が一つもない言語を想定しよう。これを仮に「ヴォイニッチ語」と呼ぶ。「ヴォイニッチ語の部屋」という思考実験の持つ意味は、「中国語の部屋」とは根底から異なる。
 部屋がヴォイニッチ語を理解しているかどうかを判定する方法が、世界中にたった一人のヴォイニッチ語話者では、あまりにも胡散臭い。中国語には10億人のピアレビュアーがいるが、ヴォイニッチ語には一人もいない。
 話者以外のヴォイニッチ語の資料といえば、その話者からの聞き取り調査で作ったものだけだ。その資料をもとに部屋のヴォイニッチ語理解を判定するのは、中の人がマニュアルどおりに動いているかどうか、マニュアルが資料と整合するように書けているかどうかを判定することでしかない、つまり「部屋を構築・運営する作業」を見ているだけで、ヴォイニッチ語を見ていない。
 というわけで、「中国語の部屋」で注目すべきは、部屋の中ではなく外だ。部屋の中で起きていることは単純だ。複雑さは部屋の外にある。
 
 中国語の部屋を、実験装置や見世物ではなく、なにか現実的な仕事をさせるために作るなら、完璧な中国語の実装をあきらめるべきだろう。現実的な仕事のための予算では、中国語のあらゆるニュアンスをマニュアルに押し込むことはできない。
 実装すべき言語は、中国語の形式化されたサブセットになるだろう。これを仮にミニ語と呼ぶ。ミニ語にはわずかな語彙だけを採用する。その語彙も、元のニュアンスをはぎとり、あいまいさを形式化で切り捨てる。中国語にはない語彙も、必要に応じて追加する。
 このような変形・人工化を推し進めてゆくと、ミニ語は中国語から遠ざかるかわりに、「ミニ語の部屋」をより経済的なものにすることができる。
 だが、話者が一人もいないミニ語は、一人はいるヴォイニッチ語よりも、胡散臭くはないか。
 
 ソフトウェアの設計とは、ミニ語(とそのマニュアル)を作るだけでは十分ではない。ミニ語話者を作り出すことも必要だ。
 CRCカードのセッションはまさにそのようなものだ。ミニ語を作ると同時に、ミニ語話者を作り出している。「CRCカードのセッションは百聞は一見にしかず。説明を読んでもよくわからないが、実際のセッションを見るとすぐ自分でもできるようになる」「コードができたらCRCカードは捨てる。ドキュメントなどに流用しない」という逸話(出どころを失念)も、ミニ語話者を作り出す作業としてセッションを理解するなら、なるほどと思える。
 
 本書『オブジェクトデザイン』は、ミニ語の人工化を高度に推し進めることを目指して書かれている。ミニ語に採用すべき語彙の選択、あいまいさの発見と除去、中国語にない語彙の創造や採用について、広範かつ詳細に述べている。これほど高度な人工化を目指し、これほど広く深く書かれた本を、私はほかに知らない。
 だが、その質の高さにもかかわらず、なにか途方もなく片手落ちだという印象を抱く。本書が、ミニ語を作る作業ばかりに饒舌で、ミニ語話者を作り出す作業については寡黙だからだ。
 だがこれは、著者の関心が偏っているせいなのか。
 
 CRCカードのセッションが百聞は一見にしかずなのは、なぜなのか。ミニ語話者を作り出す作業のなかには、なにか根本的に説明困難なものがあるのではないか。
 オブジェクト指向の発祥から40年近くが過ぎてもまだ言語化のできない、口移しでしか伝えられない「術」にソフトウェア設計の本質がもしあるのだとしたら、コンピュータシステム(ハードとソフトと運用のセットという意味で)はすでに、クルマや建築物のような道具ではなく、意識というべき何かを持っている社会の一員なのかもしれない。

Posted by hajime at 19:16 | Comments (0)

2007年12月06日

Peter Van-Roy、Seif Haridi『コンピュータプログラミングの概念・技法・モデル』

 Peter Van-Roy、Seif Haridi『コンピュータプログラミングの概念・技法・モデル』(翔泳社)を読んだ。読んだというか、ページを最後までめくった。特に後半は、書いてあることを適当に妄想しながら読んだ。理解しようとして読めば、おそらく半年はかかる。
 
・データフロー変数が格好いい
 (未束縛の変数を読もうとすると、その変数が束縛されるまでスレッドがブロックされるという変数)
 
・遅延実行構文が格好いい
 (X = ByNeed hoge と書くと、Xを読もうとするまで hoge の実行が遅延される)
 
・「継承は、プログラムを構造化するための、1つのプログラミングツールにすぎない、と見る。この見方は全く奨められない。クラスが代替性を満たさないからである。バグと悪い設計が後を絶たないのは、この見方のせいである。名前は控えるが、大きな商業プロジェクトが破綻した例がある。」(532ページ)「数年前、ある有名な会社がOOPに基づく野心的なプロジェクトを立ち上げた。数十億ドルの予算にもかかわらず、プロジェクトは失敗に終わった。その原因の1つがOOPの誤用であり、特に継承に関してであった。」(535ページ)というのはTaligentのことか?
 (Taligent: 「オブジェクト指向OS」なるものを作って売ろうとしたチャレンジャー。10年以上も前に潰れたが、Javaに呪いをかけた(1, 2)ことで今も悪名を轟かせる)
 
・制約プログラミングは表記法に工夫の余地がある気がする。制約プログラミングが普及しないのは、表記法のせいではないか。
 
・プログラミング言語の計算モデルにありうべき拡張として、「1. 動的スコープ。2. 膜(membrane)。3. トランザクション支援。動的スコープとは、コンポーネントの振る舞いが状況によって変化することである。膜とは、プログラムの一部に囲いを巡らし、その囲いを通して参照しようとすると「何かが起きる(something happens)」ようにすることである。これは、データ構造や手続き値の内部に隠蔽されている参照についても同様である。トランザクション支援とは、あるコンポーネントの実行が成功裡に終了しなければキャンセルできるようにすることである。」(870ページ)
 トランザクション支援は、トランザクションという概念の構成(ファントムリードをどう考えるか等)に踏み込むので、あれこれ妄想すると楽しい。
 
 ろくに読んでいないので、お勧めかどうかよくわからない。

Posted by hajime at 18:50 | Comments (0)