Categories |
CPUの創りかた |
Modern Compiler Implementation in ML |
NerdTV |
PDP-11シミュレータで古代のUNIXを動かしてみる |
The Yakumo Project |
やさぐれ読書録
最近のツッコミ:1.dyendignify(2008-08-18 10:20)
2.Dominic(2008-06-23 05:05)
3.CheapestCheapOEMoem(2008-06-17 03:00)
最近のトラックバック:1.濃縮還元オレンジニュース:プロ.. (2006-12-22 22:02)
NerdTVの第四話はInternet Archiveの運営で知られるBrewster Kahle氏へのインタビュー。同氏はMITからThinking Machinesを経て、WAIS Inc.(Kahle氏はWAISプ ロトコルの設計者でもある)、その後にInternet Archiveを設立したという人物である。今回紹介するのはインタビューの44分40秒から始 まる一節、1976年に起きたアメリカの著作権法改正と、それが与えた影響について。
Bob: このNerdTVの配布は…最初GPLでやろうとしていたんですが…
Brewster: ええ。
Bob: Creative Commonsがちょうど登場してきたので、それを使うことにしたんです。でも普通の放送局に行って、これを無料で配布します、ちなみにコピーも改変も自 由ですと彼らに言うと…彼らは、私のことを頭が三つある化け物のような目で見るんですよ。
Brewster: そうでしょうね。でもCreative Commonsライセンスは素晴らしいものですよ。オープンソースソフトウェアの考え方を打ちたてたRichard Stallmanという巨人の肩の上に立つ存在です。
Bob: そうですね。
Brewster: 彼の考え方は完全に正しいと思います。我々の分野には偉大なヒーローが何人かいますが、Richard Stallmanはそのうちの一人です。
Bob: 人々の目に触れ、人々の耳に届くようにするには、こうしなければいけないのですよね。
Brewster: そうです。そしてこれは昔の姿への回帰であるとも言えます。人々はこれが革新的な新しいアイディアだと言いますが、実際には全然そんなことはないんです。 著作権法の内容というものはある時期を境にガラリと変わったのですが、それがいかに害をもたらしているかが認識されるようになったのはようやく最近になっ てからのことです。つまりですね、1976年の著作権法の改正で、突如すべてのものに著作権が発生するようになってしまいました。
Bob: はい。
Brewster: それ以前は、宣言をしない限り著作権は発生しなかったんです。自分の作ったものに小さく"c"の文字を入れて、アメリカ議会図書館に送らない限り、それは 著作物とならなかった。ということでほとんど全てのものが著作物になっていなかったわけです。
Bob: ええ。
Brewster: 実際のところ、私たちがRichard Stallmanなどと共にtechnical schoolで書いていたソフトウェアには作者の署名が入っていませんでした（注: 英文のトランスクリプトでは"they were signed"となっているが、音声では"they weren't signed"と聞こえる。文脈上も妥当と考えられることから、ここでは「署名が入っていませんでした」を採用する）。これはハッカー文化の一部でした。 私たちはテクノロジーを一緒に作り上げていたんです。利用制限などというものはありませんでした。そしたら著作権法が変わってしまったんです。そして MITは私たちの作ったものを取り上げてパッケージにして売ったんですよ。そして…
Bob: けしからんですね。
Brewster: まったくけしからんですよ。（笑い） 共有財産を売り渡す行為、共有財産の独占化でした。まったく常軌を逸している。それでRichard Stallmanはキレたんです。
Bob: ふむ。
Brewster: 彼は、こんなのは間違っていると言ったんです。全ては1976年の著作権法改正のせいです。それ以前はこんなことは起こりようがありませんでした。しかし その改正後、このようなことになってしまった。それで彼はオープンソースの運動を始めたんです。彼はかつて存在していたバランス、私たちがその中で育って きた、そのバランスを取り返そうとしたんです。
Bob: なるほど。
Brewster: ということで、オープンソースの考え方は - 実はかつての姿に戻る復古運動なんです。そしてCreative Commonsはその上に、柔軟性とゆとりという、アイディアを扱う上で社会が特に必要としているものを提供しようとしていると言えます。
Bob: MITが売ったものとは何だったのでしょう?
Brewster: 彼らはLisp Machine Systemのライセンスを二つの会社に売りました。SymbolicsとLisp Machines Incorporatedにライセンスしたのです。私たちが作ったマシンを取り上げ、そのソフトウェアを企業にライセンスするというのは、私たちの信頼を 大きく裏切る行為だと思いました。
Bob: そうですね。
Brewster: それに対してRichard Stallmanは「オレが目を離した隙にこんなことをやりやがって」と言ったわけです。
Bob: ふむ。
Brewster: そして彼は、自分たちが活動する上で必要となる絶妙な着地点を見つけ出し、使えるライセンスを作ったのです。以後、さまざまなバリエーションが登場するこ とになるわけですが。
Bob: ええ。
Brewster: しかし彼の出した基本的アイディアは非常に大きな一歩でした。
（NerdTV #4: Brewster Kahle by Robert X. Cringely and PBS、福 盛秀雄訳）
今回は全体を通してラディカルな内容の、面白いインタビューになっている。hirさんのところで、同インタビューの抜粋ムービー(Juicy Bit/Nerdy Bit)の訳が掲載されているのでこちらもぜひ参照願いたい。
NerdTVの第四話(Brewster Kahle: 復古運動としてのオープンソースとクリエイティブ・コモンズ)にて話題に上っていた、MIT Lisp Machineだが、そのソースコードが10月2日に公開された模様だ。NerdTVでの放送直後というあまりのタイミングの良さに、何か関係があ るのでは と思ったが、ざっと見た限りではそのような形跡は見られない。こち らのページ(MIT CADR Lisp Machine Source code)か らダウンロード可能である。
長く、だが同時に楽しくもあった探索の末、私はMIT CADR Lisp machineの1980年前後のソースコードのスナップショットが格納されていると見られる9-trackのテープ一式を発見した。これは最終版のソースコードではな く、また私の出す最後のソースコードのリリースでもない。だがこれは最初のソースコードのリリースである。
(MIT CADR Lisp Machine Source code, やさぐれ訳)
このソースコードリリースについて紹介しているblogの記事を一部紹介する：
Brad Parkerから、「LISPMのソースコード全てを、"BSD風"のソースライセンスの元にリリースするという許可をMITから受けた」というメールが やってきた。これはすごい知らせだ。というのも、Lisp Machinesを構成するキーとなるソフトウェアコンポーネントが、長い年月を経た末についに公の場に現れるということを意味するからだ。
(MIT Open Sources the LispM Code, やさぐれ訳)
私自身が思うに、もしもMITが、(CADR Lisp Machineの)ライセンスを2005年でなく1980年に放棄していたならば、歴史は大きく変わっていたかもしれない。だがそこはまた議論の余地もあ ることだろう。
(Reading Old Code, やさぐれ訳)
10月2日付のartonさんの日記に書かれているスティーブン・レビーの「ハッカーズ」の紹介と併せて見ると、このソースコードにまつわる背景がさらに浮かび上がってくる：
すべてはグリーンブラット流のハッカー企業（LMI）か、ノフツカー（RMSをMITのラボに雇った人間でもある） のビジネス企業（シ ンボリックス）か、という経営理念とハッカー倫理のせめぎあいみたいな話になっている。で分裂（と言ってもグリーンブラットは孤立）が1979年に明らか になり、1982年から1983年にかけてRMSがリンボリックスに対してリバースエンジニアリング攻撃（と言ってよいだろう）をかけていく。シンボリッ クスの12人のLispハッカー対MITに残ったたった1人のRMSだ。読み物としては抜群のおもしろさではある。
(L'eclat des jours - 2005年10月2日)
抽 出されたファイルの一覧を見ると、タイムスタンプは1980年前後のものがほとんどである。ということでStallmanがリバース エンジニアリング攻 撃でSymbolicsに対抗していたころよりも前のもののようだ。今後のリリースでこのあたりのソースも出てくると面白いのだが…ちなみ にStallmanがLisp Machineについて語った講演"My Lisp Experiences and the Development of GNU Emacs"のトランスクリプトがGNU Projectのページに存在する。ソースコードともども、少し時間をとって読んでみようかと思う。
NerdTVの
第五話はTim O'Reilly。
もはや改めて詳しく紹介することもなかろう。今回はO'Reillyのシンボルとも言える動物本に
関するお話を。インタビュー開始後10分29秒から始まる一節である。
Tim: 最初の本の多くは非常に小さいものでした。最初に私たちが出版した本は、どれも70ページか80ページかそこらで、個別のユーティリティを対象にしていま したが、その、個別のプログラムを対象にしたということが、私たちのブランドとなる動物本のアイディアにつながりました。デザイナーの一人が、Unixのプログ ラムには、ヘンな動物のような名前がついていると言ったのです。動物本が始まるもう一つのきっかけについては、ちょっとしたエピソードがありますが、その話 にからむ女性、Edie Freedmanはうちの社員ではありませんでした。その当時、彼女は私たちの知りあいですらなかったのです。後のオープンソースソフトウェアとのかかわりを思 うと、私たちにとって最も大事な、動物本のブランドと言うのが、自分たちの知らない人物によってもたらされたというのは、なんとも幸運な運命の皮肉という か、そんな感じがします。
彼女は私たちのライターの一人の家で家政婦をやっていました。当時私たちは、外部に本のデザインをいくつか依頼していたのですが、 その 出来に私は満足していませんでした。そのライターが週末に自宅へ帰ったときに、たまたまそれを彼女に話したのですが、かつてDigital Equipment Corporationのデザイナーだった彼女は、「それは面白そうなプロジェクトですね」と言ったのです。その週末、彼女は我々の ために7種類のカバーデザインを仕上げてくれました。それが私たちのところに送られてきたのですが、どれもかなりインパクトがありました(they were pretty weird)。大きな目やずん ぐりした 体の動物の絵です。中には特にインパクトの強いものもあって、私たちはそれらを一週間ほど壁に張って仕事をしつつ眺めては、「こりゃすごいな」と言ってい ました。
そのうちにEdieは私たちと共に仕事をするようになり、クリエイティブ・ディレクターとして何年もの間にわたり働いてくれました。彼女と私たちは現在も一緒に仕事をしており、彼女は今はグラフィックスに関する本の編集をやっています。でも、これはすばらしくツイていたというか、純粋に運があった結果だと思います。
Bob: 動物本の存在は成功に寄与したと思いますか?
Tim: ええ、間違いありません。というのも、本の出版を始めたとき、私たちは出版について全くと言ってよいほど知りませんでした。それがおもわぬツキの元となっ たのです。動物本の表紙にからんだ良い例を一つあげましょう。これはいくつかの出来事が重なっているのですが、まず私たちが出していたのは個別のユーティ リティ向けの小冊子でした。背表紙がなく、ホッチキス止めになっているやつです。というのも、これらは普通の本にするには小さすぎたし、また私たちは、こ の手の本は通常製本タイプの薄めの本のように、開いたまま机の上に置いて使えるように作ったほうが良いだろうと思っていたためです。
結果、私たちの本は他の本と一緒に置くことができなくなったため、別のセクションに置かれることになりました。私たちの本は平置き(face out display)で陳列されるコーナーに行くことになったのです。
Bob: コミック本とかと一緒に置かれてたんですか?
Tim: ええ、まぁそんな感じです。私たちの競争相手はきっと、やつらは一体何者だ? 彼らの本が平置きのスペースを埋めているのはいったいどういうことだ? と思ったはずです。 他の出版社はみんな平置きのスペースに置いてもらうためにお金を払っていたのですが、私たちは他に自分たちの本を置く方法がなかったために、自動的にそのよう な扱いを受けることになったわけです。さらに動物本のあの表紙はインパクトがあり、他の本とは異なっていて、とにかく目立ちました。良いブランドの要素を 備 えていたと言えるかもしれません。若干カルト的な要素もありました。知る人ぞ知るという裏話的な感覚です。いろいろな意味で、動物本の動物はさまざまなプ ログラムの象徴となったわけです。
このような現象は長い時間をかけて起こったものです。最初は単に「あれは一体なんだ?」という感覚で受け止められていたと思います。X Window Systemのシリーズはかなりの人気を博しましたが、あれをやったときには、企業向けであることをまず念頭に置いていました。企業の人間 は動物が表紙に書かれた本を敬遠するだろうと予想して、あのシリーズでは動物を表紙にしなかったのです。しかしその後5年、10年経つにしたがい、動物本 の知名度が上がるにつれ、あらゆる企業で動物が表紙に入った本は受け入れられるようになりました。
Bob: 当初動物本にしなかったものを、改めて動物本として出し直した、ということはあったんですか?
Tim: いえ、それはやったことがありません。Xのシリーズはあのまま打ち止めになりましたし。私たちはまた、長年にわたり、自分たちのブランドを守るための活動 もやってきました。今までに我々のモデルに合わない本を出すことも結構あったのですが、それらの本については動物を表紙に入れませんでした。これについて はちょっと面白い話があって、我々の競争相手であるAddison-Wesleyにいた人物を一人うちで雇ったのですが、彼いわく「あなたがたが本の表紙 に動物の入っていない本を出すたびに、我々は喝采を送ったものです」とのことでした。私はそれに答えて、「そうでしょう。それこそが私のところに強いブラ ンドがあり、あなたのいたところにはそれがなかったという証拠ですよ。動物を表紙に載せるということの意味を、私たちはよく理解していた、という ことです」と言ったんです。
ということで、動物を表紙にしない本もいくつかあったんですが、私が未だに覚えているのは、我々の最初の編集者であるDale Dohertyと私が、動物を表紙に入れないという最初の決断を下したPOSIXの本です。POSIXはUNIXの標準規格といったものですが、その本は悪 くは ないんだけれども、面白みのないリファレンス本というのがふさわしい一冊でした。私たちが出した動物本にはいずれも、本を書くために雇われたテクニカルラ イターという枠を打ち破る解放感がありました。例えばそのプログラムの悪い点を遠慮なく書いたり、実践的なアドバイスを与えたりするといったところです。 で、問題となった本は悪くはないんだけれども少々退屈であると。ということから、私たちは、これは動物本には値しないため、一種の教科書として取り扱うと いう決断を下したわけです。その本は結構売れましたが、そこで私たちは、動物本というのが自分たちにとって特別であることを改めて、本当に認識したので す。動物本と言うのは実際の体験に基づいた、実践的な、最前線からの報告とでも呼ぶべき存在であると。
(NerdTV #5: Tim O'Reilly by Robert X. Cringely and PBS、福 盛秀雄訳）
今回のインタビューも全編を通して面白い内容になっている。時間と余裕があれば他の部分も紹介することにしたい。
本エントリの内容はクリエイ ティブ・コモンズ・ライセンスの下に公開されています
# CheapestOnlineUSpharmacy [http://viagra-without-prescription.net [b][u]GENERIC VIA..]
# CheapestViagraWithoutPrescription [http://viagra-without-prescription.net [b][u]GENERIC VIA..]
# SuperCreativeSuiteWeb [[b]can't install ADOBE CREATIVE SUITE 3 [/b] http://for..]
# NewDownloadCreativAdobOEM [[b][u]DOWNLOAD Adobe Creative Suite 3 Web Premium.[/b][/u]..]
# CheapestCheapOEMoem [http://forums.foxytunes.net/viewtopic.php?p=8172&sid=c5538..]
# dyendignify [[b]マ�鵁� - 蒡髓齒 碌繝6 頌瘠繪 [/b], [b]鴃珞蔬蓆迯��[/b], [b]琿琺[/b], [b]粽黹..]
前回の「Tim O'Reilly: 動物本のはじまり」の中では、オライリーの動物本がいかにして成立・発展したかについて、Tim O'Reillyの視点から語られていたが、ではその動物本を最初にデザインしたEdie Freedmanの目に、動物本というものは一体どう映っていたのだろう？
ということで今回は、それについて語られている同氏の文章、"Origin of Species: A History of O'Reilly Animals"を(oreilly.comからの許可の下)紹介することにしたい。
by Edie
Freedman
(日本語訳: 福盛秀雄)
04/01/2000
私がO'Reillyの最初の動物本の表紙のデザインを手がけた1980年代の終わりごろから、現在に至るまで、私の元には読者から の、本の表紙にする動物をど うやって決めたのかという質問が山のようにやってきています。皆、あるトピックにあの動物が選ばれたのはこういう理由だろうとか、さまざまな推理をめぐら せ ているようです。本の著者自身が質問をしてくることすらあります -- 私の選んだ動物を見て、気を悪くする著者もいたりするのです。いわく、表紙を見た読者が、自分のことをカバのように太っているとか、アオアシカツオドリ のように頭が悪いと思ったりするのではないか、と。本に載せる動物をどのようにして選ぶかについて、私は誰にも言ったことがありませんが、それぞれについ てきちんとした理由があった、ということだけは全ての関係者に言っておきたいと思います（とは言ってもここでその理由を教えたりはしませんよ。あしから ず）。
彼らの本の新しいカバーについて、O'Reillyからアプローチを受けた時期、私はDigital Equipment CorporationのVAX/VMSの世界に染まっていました。UNIXのことは聞いたことはありましたが、それが何者であるかについては、非常にぼ んやりとしたイメージしか持っていなかったのです。UNIXプログラマーにも会ったことはありませんでしたし、viを使ってドキュメントを編集した経験も ありませんでした。viやsedやawk, uucp, lex, yacc, cursesなどにまつわる用語は、あの有名な「ダンジョンズ&ドラゴンズ」と言うゲームで使われている言葉のように聞こえました。 そこで私はUNIXプログラマーのことを「ダンジョンズ&ドラゴンズ」のプレイヤーのような人たち、というイメージでとらえることにしました。そして本の表 紙に使うためのイメージを探し始めて間もなく、19世紀に作られた、素晴らしい木版画たちに出会ったのです。その木版画にあった奇妙な動物たちは、あの 奇妙に聞こえるUNIXの用語にぴったりであり、私の想像するUNIXプログラマータイプの人々に受けそうな、通好みな感じも備えていました。
最初の動物本の表紙一式をO'Reillyの人たちに見せたときの反応は微妙でした。
「これって、すごく不細工ですよ」と、ある人は言い、
「多分誰も手に取ってみようと思わないんじゃないですか」と、他の人が言い、
「なんかおっかないなぁ」とも言われたり。
でもTimは私の出した動物の、妙な感じが気に入り、また、これを使えば他の出版社の本よりも目立つことが出来るだろうと思ったようで す。そして今日、 O'Reillyの動物本のブランドは世界中でよく知られる存在になりました。
The Making of an O'Reilly Animal -- ここで、皆さんにO'Reillyの編集者であり、パートタイムで美術もやっている Lorrie JeJeuneを紹介したいと思います。あなたのお気に入りのO'Reillyの本の動物も、彼女の手によるものかもしれませんよ。
私たちは本の表紙にした動物について、いろいろなことを読者や著者の人たちから教えてもらいました。ある本の著者は、彼の本の表紙にワ タミハナゾウムシをどうしても使ってほしいと言い、この題材にはワタハナミゾウムシがなぜふさわしいかという理由とともに、それに関する山のような資料を 私の元に送ってきました。結局、私は彼の本であるOracle Web Applicationsに、その虫の絵を使うことにしました。
ときには、元絵となった版画についての情報が少なかったために、書かれている動物の名前を間違えるということもありました。そのような ことがある と、私たちの読者はそういった間違いについて、いつも熱心に指摘してくれます。一度私が、サルの版画にあるキャプションを読み違えて、奥付の担当者にその サルはチンパンジーであると伝えたことがありました。その結果私たちは、チンパンジーに尻尾があるということは断じてありえないと言う、読者からのなだれ の様なメールを受け取ることになったのです！
特定の動物、特にクモやヘビやネコといったあたりに恐怖症を持つ読者から連絡を受けることもありました。ある読者の旦那さんから、私た ちがWebmaster in a Nutshellに 使ったクモの絵について苦情がきたことがあります。その本の読者、つまり彼の奥さんはクモが大嫌いだと言うのです。彼はその本全体に目を通して、彼女がク モを目にすることがないように、全ての章の最初のページにあるクモの絵に、白いテープを張ったとのことです。別のケースでは、私たちのウェブサイトの中の あるページにヘビの絵があるために、そのページに行けないと言う怒りのメールが来たこともあります。問題となったのは「注文方法」のページだったので、そ こには別の動物を使うように修正することにしました。
ここで少し真面目なお話を。動物の版画を扱う仕事をしているうちに、私は自分たちの環境に何が起きているのかを気にするようになりまし た。私たちの表紙に登場する動物の多くは、絶滅の危機に瀕しています -- 例えば、Learning the vi Editorのメガネザル、sed & awkのノロマザル、 lex & yaccの ビクトリアカンムリバト、Java Foundation Classes in a Nutshell のフロリダパンサー、などです。動物たちの版画が作られた19世紀には、こういった動物はたくさんいました。私たちは表紙に動物の絵を使うことで、我々とこ の惑星を共有している動物たちを救うために、皆がより一層努力するという、そんな意識を高めるための手助けが出来ないか、と思ったりもするのです。
NerdTVの 第五話、Tim O'Reillyのインタビューから、本の未来について語っている部分を紹介する。インタビュー終盤、1時間1分15秒のところ、 「本はなくなってしまうのでしょうか?」という(Bob) Cringelyの質問に対して：
Tim: それは鋭い質問ですね。私が思うに --
Bob: 答えは「ノー」なんでしょ？
Tim: 場合によると思います。本と言うものに関して私が気にしているのは、多くの人々が本の物理的なかたちにとらわれてしまい、本と言うものを、単一のカテゴリ のものとしてとらえてしまっているのではないか、というところです。本と言うものはその役割ごとに分けてとらえるべき存在だと思います。というのは、ある タイプの本は…ほぼ間違いなく消えてしまうと思うからです。一方、種類によっては、現在よりも発展していくタイプの本もあることで しょう。例えば、リファレンス本にはwebとの激しい競争が待っています。webというのはリファレンスとしては強力ですからね。ファンタジー小説の場合 には、EverquestやWorld of Warcraftといったゲームとの競争となることでしょう。提供するものが同じですから。
私は、本が好きな人たちというのは必ず残るのではないかと思っています。ただし市場の規模がかなり小さくなるという可能性もあるこ とで しょう。私たちは、本というものがどのように変わっていくのだろうかということについて考えてきました。一例を挙げると、私たちの会社はスタンドアロンの 電子ブックに興味を示して来ませんでした。その理由として、私たちの提供する本は、一つにはリファレンスという役割を担っているわけですが、オンラ インにすることでリファレンスというものをより使いやすくすることができないか？と考えたからです。リファレンスをより使いやすくするために追求すべきと ころとして、まず一つ目に検索のしやすさ、二つ目に常に最新の情報が提供されること、三つ目に、他のドキュメントとリンクを通じて協調する可能性、があり ます。これらのいずれも、webが非常に得意とするところです。
私たちのsafariというサービスはそこから生まれたものです。現在はPearsonとの協業により3000冊以上の本がオンラ イン で閲覧可能になっています。Microsoft Pressからもコンタクトがありました。彼らの本も答えを探すために使われる、という点で一致していたためです。また読者には複数の本にまたがって検索 をしたいというニーズがあります。それに対応するために豊富なコンテンツを用意するわけですが、その一方で、私たちはトレーニングというビジネスにもから んでいます。人々に新しいことを教えるという仕事です。これは未だに、正解が見つかっていない世界でもあります。ただ私たちは、ある種のタスクについては、か なり簡単に教えることができるかもしれない、と思い始めています。例えばアプリケーションの使い方などは、スクリーン動画のデモ(screencasting) を使って説明するのが有効なのではないでしょうか。
ということで、アプリケーションの操作方法に特化したタイプの本の多くは消えるのではないかと私は思っています。一方、複雑なコン セ プト などを教えるような場合は、本は最も良い手段であり続けることでしょう。あるいは単に、あちらには画面、こちらには本、という風に並べることで、目から入 る情報量(bandwidth)を増やすという使い方も有効であり続けるかもしれません。したがって、さまざまな場面で、本が役に立つ状況と言うのは存在 しつつけることでしょう。でも実際のところ、私は本というものは次の十年で大きく変化するのではないかと思っています。
Bob: そうですね。でもあなたはまだ本を持っていますよね。
Tim: ええ、私は本のコレクターとしてはかなりのものですよ。蔵書として6000から7000冊くらいの本がありますし、本が無くなってしまう、なんていうこと は考えたくないですね。
(NerdTV #5: Tim O'Reilly by Robert X. Cringely and PBS、福 盛秀雄訳）
このような会話が展開されるのだが、実は上の文章では決して伝わらない大きな山場が一つ、動画の中、1時間1分42秒から始まる約10秒のシーンに隠されている。その中でTim O'Reillyは「ある タイプの本は(Because there are some kinds of books that are...)」と言い始めた後、一瞬横を向い て3秒ほどためらい、そこから意を決したかのように顔を上げて「ほぼ間違いなく消えてしまうと思うからです(I think (they) are almost definitely going to go away)」と語るのだが、その3秒の沈黙の間に浮かぶ表情は、言葉ではなんとも表現しがたいものがある。彼の頭の中に浮かんだであろうことについていろいろ と想像をめぐらすこともできないワケではないが、ここでは書かないでおこう。直接映像を見て確かめてみてもらえれば幸いである。
本エントリの内容はクリエイ ティブ・コモンズ・ライセンスの下に公開されています
NerdTVの第六話はDave Winterへのインタビュー。RSSの生みの親として 知られる人物である。以下、インタビューの44分45秒のあたり、RSSの誕生にまつわるお話から：
Bob: （RSSは）どのようにして生まれたのですか？
Dave: RSSが誕生したのはですね、ええと、あれはある意味偶然の産物みたいなものです。我々にはこれが必要だ -- といったビジョンの元にRSSが生まれたわけではありません。少なくとも最初のうちはそうでした。簡単に説明すると、MicrosoftにAdam Bosworthという人物がいて -- ちなみに彼は今はMicrosoftにはいないのですが -- 彼が何かと言うと私のところに聞きに来たんです。Adamとはかなり昔からの知り合いです。私と同じような、灰色のひげをたくわえた感じのベテランと言ってよいでしょう。実際には彼はひげを生やしてはいません けどもね。ともかく、シリコンバレーの技術者の元祖の一人と言えます。
彼はデータベースの仕事をしていました。確か彼のやっていたデータベースはANSAと言う名前で、それをBorlandに売り、そ の後 Borlandでスプレッドシート、その後にMicrosoftでデータベースをやりました。Accessは彼の仕事だったかな。
Bob: ええ。
Dave: そう、Accessは確か彼の仕事のはずです。その後彼はMicrosoftでXMLの専門家になりました。で、彼は -- 有能なエバンジェリストでもあります。つまり、彼はある技術がどのようにして動くか、その仕組みを良く分かっているということです。これと決めたら -- 決してノーとは言わない、自分の求めるものは何かをきちんと心に描いて、それに向かって一心に進んでいく。そして決してあきらめない。で、彼は、私が XMLをやるべきだ、というか、自分がXMLの仕事をするには私が必要だと思ったようです。ということで彼は私のところまでやってきました。私はそのとき Woodsideに住んでいたんですが、彼はそこへ訪ねてきたんです。Microsoftではかなり上のほうにいる人物です。もちろん、私は彼に会ったこ ともあるし、知り合いだし、好きな人物でもある。彼は素晴らしいソフトウェアデザイナーであり、自分の手がけているソフトウェアについて良く理解している 人物と会うのが楽し いという人物です。
でもその場で私は「うーん、その話には乗れないなぁ」と答えました。彼に対して、これは大きな会社が手を出して、最終的には台無し に なってしまうタイプの仕事だと言ったんです。先ほどの話でも出ましたが、本棚一杯に埋まった仕様書を作って、そのままダメになって終わり、と。
「そうか、じゃぁまた来るよ」と言って彼は帰ったんですが、しばらくするとまたやって来る。私は同じことを言って「その仕事はやら ない よ」と断る。それを三回繰り返したんですが、四回目になってついに、「わかった。やってみることにしよう」と言ったんです。
Bob: 彼は四度あなたの元に来たんですか？
Dave: ええ、四度やってきました。それで --
Bob: 彼があなたをそこまで必要としたのはなぜでしょう？
Dave: なぜか、ですか？
Bob: ええ。
Dave: 分かりません。彼 -- ええと、 -- 彼が私にいったことは覚えていますが、それが答えなのかはちょっと分かりません。彼は直感的に、XMLとアウトライン文書は技術的に非常に似ていると思 い、私がアウトライン文書技術の専門家として有名だったからやって来た、と言っていました。
Bob: なるほど。
Dave: 理由としては私がコンピュータの業界でアウトライン文書技術の専門家として知られていたこと、それと -- 私がXMLに対して何かできるんじゃないかと直感していた、といったあたりでしょうか。確かにその点で彼は当たっていたと思います。どうでしょう？
Bob: そうですね。
Dave: その後、私はXML化できそうなものを探してまわりました。手元にあるデータのうち、使えそうなものを探したんです -- というのも、それこそがXMLの土台となるアイディアだと思ったからです。XMLというのはファイルフォーマットを生成するための手段です。あまり派手な ものではない。とってもシンプルですよね。
Bob: はい。
Dave: だから - いろいろな人がXMLについて語っていたんですが - 彼らが何を言っているのかが理解できませんでした。どうもXMLがプログラミング言語であるかのような話をしている。
Bob: ええ。
Dave: でもXMLはプログラミング言語ではない。ファイルというか -- ファイルフォーマットを生成するための手段である。当時私はそういう風に考えていましたし、現在もその考えは変わっていません。そして最終的には、そのよ うな結論に落ち着くものと思っています。ということで、私はWebサイトで変更のあったページすべてを追跡するための仕組みを作りました。実際には Googleが現在そのようなことをやっていますがね。それが1997年のことです。良いアイディアだったのですが、しばらくして手を引いてしまいました。あまり 熱心にやるつもりがなかった。
その後にScripting News Formatというものをやりました。これは、私のblogであるScripting News、www.scripting.comをXML化するというものです。私が毎日Scripting Newsに記事を載せると、HTMLバージョンに加えて、XMLバージョンも生成されていきます。そこで思ったのが「これならばニワトリ（アプリケーショ ン）が先か、卵（データ）が先か、という問題を気にする必要はないな、よし、このフォーマットを公開して、広く使ってもらえるようにしてみよう。『これを 使ってアプリケーションを作りたい人は誰でも自由にやってみていいよ』と言ってやろう」ということでした。
しかしあまり盛り上がりませんでした - それが1997年の終わりごろのことです。1998年になって、コンテンツマネジメントをやっている会社、Vignetteがいくつかの 実験を やったり、オープンソースの開発者がいくらか開発をやったりという状態になりましたが、あまり大した進展はありませんでした。そして1999年の初めに なっ て、Netscapeの人たちからメールを受け取るようになったのです。彼らはかなりエキサイトしており、自分たちのやっていることを私に見せてくれましたが、何 をやっているのか私には理解できませんでした。でも彼らがScripting Newsを読んでいる、ということは確かに分かりました。彼らが仮想新聞と呼ぶものを作ろうとしている、ということも理解しました。
仮想新聞と言うのは一種の -- 説明が難しいのですが、彼らはコンピュータの画面を新聞ととらえて、画面の中を複数の区画に区切った後、情報を、その区切られた区画に割り当てていく、と 言うことを考えていました。で、彼らはScripting Newsのフォーマットをそこに使おうとしている、と私は思ったわけです。私が見た限りでは、そのような状況に見えました。ところが彼らは実際には、車輪 の再発明をやっていたのです。彼らが出してきたのは私のものとはまったく、完璧に互換性のないフォーマットでした。
それに気がついたときには、彼らがやったことに対してえらく腹が立ちました。一番最初にがんばっていろいろと作ったのにもかかわら ず、二番手の人間が全然別の方法でやってしまう。結局のところ、標準を作る力を得るのは最初にやった人間ではなく、二番手の人間である。 これはとても大きな発見だったと思います。最初にやった人間は、自分の作ったものが世の中に認められるかどうか、手をこまねいて見ているしかない。
という状況で、私の姿勢もそんな感じにならざるを得ない。もはやどうしようもなかったのですが、最終的には突破口が見つかること になりました。彼らのフォーマットを受け入れ、自分の持っていたフォーマットは過去のものとするいう選択です。簡単に言うと、まず最初に彼らのフォーマッ トにあった機 能のうち、自分のところにはなかったものを全て取り込む、ということをやりました。
Bob: ふむ。
Dave: そして私はScripting Newsのバージョン2.0を出したわけです。これはNetscapeの連中に対する牽制球(a shot across their bow)みたいなものでした。それと同時に私は「あなた方のフォーマットであるRSSは、私の作ったサイトの全てにおいてサポートしますよ」と宣言して、 MyUserLand.comというアグリゲータを作りました。現在あちこちに存在するアグリゲータの元祖とも言えるものです。
彼らのやっていたのはMyYahoo!の先祖のような感じのものでしたが、現在ではMyYahoo!の方も、もう一方のモデル、つ まり アグリゲーターの方にシフトしてきています。そちらのほうが有効であるためです。彼らは私の投げた牽制球に気づき、Netscapeの社内で何か話し合っ たようです。そして私の努力に答えてくれました。彼らはオリジナルのRSSに対してScripting Newsフォーマットにあった全ての機能を追加し、RSS 0.91としてリリースしたのです。これは私が彼らに望んでいたことそのものでした。この時点で私は「Scripting Newsフォーマットは廃止し、RSS 0.91を全面的に採用する」と宣言しました。以後はRSS 0.91一本で行くと。
ということで、今度は私が二番手の座に座ることになったのです。私はNetscapeが出してきたものを承認する立場となり、 それが標準となった、というわけです。
(NerdTV #6: Dave Winter by Robert X. Cringely and PBS、福 盛秀雄訳）
といった具合に、RSSの誕生のいきさつというのはやや混沌としているのだが、その後のRSS Version1.0から2.0にかけての展開も実は上の話に劣らずかなりややこしい。興味のある方はとりあえず
あたりを見てもらうと良いだろう。
本エントリの内容はクリエイ ティブ・コモンズ・ライセンスの下に公開されています
上田さんの「シリコン バレーって、谷なの？」にもあるように、シリコンバレーというのは谷ではなく、実際にはただっぴろい平野、と言うべき場所であ るのだが、その名前から渓谷地帯をつい思い浮かべてしまうのは日本人だけ、というわけでもないらしい。以下はNerdTV第六話の13分30秒あたりから 始まる一節、Dave Winterがウィスコンシン州マディソンからシリコンバレーに出てきたときのエピソード：
Dave: （…）荷物を車に乗せて（シリコンバレーに）向かいました - Byte誌の裏表紙にあった広告の住所はどこも、ほぼ同じエリアに集中していることには気づいていました。Mountain ViewとかSunnyvaleとか。その名前から、自分の頭に浮かんだのはスイスのアルプスの風景です。山々の眺望とか、日の当たる谷とか、素晴らしい 響きじゃないか、と思いつつ車を走らせたんです。
Bob: あと斜面に沿って並ぶ建物とか。
Dave: そうそう、それですよ。小さなスキーのリフトが山を登っていく姿とか、レー ダーホーゼン（アルプスの民族衣装）をはいた人たちとかヨーデルとか。本気でそんなのをイメージしてたんです。で、いざハイウェイ 280に入ったときにはカルチャーショックを受けました。というか、車でシリコンバレーに入ったときのガッカリ感は大変なものでしたよ。あれはなんという か -- まぁやめときましょう。それで --
Bob: 今日に至るまでレーダーホーゼンは見ていない、というわけですね。
Dave: ええ、まぁEl Caminoでレーダーホーゼンを見ることはありませんね。
(NerdTV #6: Dave Winter by Robert X. Cringely and PBS、福 盛秀雄訳）
心暖まる（？）お話だ。シリコンバレーがアルプスのようなところだと本気で思っていた、というあたり、Dave Winterもなかなかお茶目な人物のようである。
本エントリの内容はクリエイ ティブ・コモンズ・ライセンスの下に公開されています
ひょんなことから、"Modern Compiler Implementation in ML"の第11章、つまり現在僕が製作しているレジスタ割り付け部の、元ネ タとおぼしき論文を見つけた。
論文の中身は上記ページからダウンロードすることが出来る。よく見ると"Modern Compiler Implementation in ML"の第11章とほとんど同じ内容だ。2005年1月23日の日記では、
"LivenessAnalysis"と、"Build"に相当する部分は前の章（第10章）で既に作成済みだし、そこで作成した コードがほぼそのまま使 えるだろうと思ったのだが…どうも勝手が違う。扱っているデータの表現形態が、現在の章とその前の章で微妙に異なっているのだ。 「記述の断層」とでも言うべきか。まだまだ苦労しそうな気配である。
なんてことを書いたのだが、つまるところ、この論文の内容を本に丸ごと取り込んでたのね（論文は1996年に、本は1997年に、それぞれ発行されている）。道理で前の章（第10章）ときれいにつながらないわけだ。
論文の中では、このアルゴリズムをStandard ML of New Jersey (SML/NJ)に実装し、計測した結果も載っている。SML/NJのレジスタ割り付け部分の ソースコード（実体はMLRISCのコードで ある）を見る限りでは、この方式がそのまま実装されているようだ。時間が出来たら自分の書いたコードと比べてみようか。
NerdTVの 第七話はDan Drake(Autodesk co-founder)だが、はっきりと僕の目（耳？）に留まるエピソードはなかったため、翻訳のほうは今回はお休み。
その間も着々と、hirさん主導によるisla-plata.org Wikiの翻訳プロジェクトは進行している。現在はNerdTVの第三話までの全文翻訳が完了し、第七話までについても部分訳が仕上がって いるという状況。以下日本語訳ページのリスト。
「Rogue Engineer's Diary/やさぐれ日記」 でカバーしきれなかったお話も掲載されているので、興味のある方はぜひ一度訪れてみてほしい。
遅れはせながら、CNET Japan Blog - 江島健太郎 / Kenn's Clairvoyanceの「XML とアフォーダンス」を題材に一つ話をしてみたい。「XMLとアフォーダンス」で書かれていることを（かなり乱暴に）まとめると、XMLによって記述され た データが人間に理解可能であるということを再評価しよう、ということ。例えば
XMLデータは、「オブジェクト」という抽象概念を理解できるプログラマーよりもはるかに大勢の人たちにとって、手に取ってみて理 解す ることのできるリアルなデータなのです。ダウンロードしてテキストエディタやブラウザで眺めてみることのできるデータなのです。
ということを言っているわけなんだけれども、「手にとって理解することのできる」ことを本当に徹底させようとするならば、いっそXML のタグも 「大勢の人たち」の母国語で書くと良いのではないか、と思うのだ。
■ XMLタグを英語以外で書くということ
下は「XML とアフォーダンス」での例だけれども
<Payment>
<Price>100</Price>
<Price>200</Price>
<Price>500</Price>
</Payment>
これを例えば日本語で
<支払>
<価格>100</価格>
<価格>200</価格>
<価格>500</価格>
<支払>
と書けば、「プログラマーではなくて、もっと桁違いに多い一般人に近い人たち」との距離はさらに縮まる、と僕は考えるわけ。
「でも"Payment"とか、"Price"って書いてあれば、ふつう英語のままでもたいていの人は分かるんじゃないの？」という疑 問を持ったアナタ、では次の例ではどうかな。
<BalanceSheet>
<Assets>
<CurrentAssets unit="MYen">150</CurrentAssets>
<NoncurrentAssets unit="MYen">200</NoncurrentAssets>
</Assets>
....
これは例えば日本語で書くと
<貸借対照表>
<資産の部>
<流動資産 単位="百万円">150</流動資産>
<固定資産 単位="百万円">200</固定資産>
</資産の部>
.....
となる。（会計の知識がちょびっと必要ではあるけれども）英語で書かれたものと比べて、日本人がこれを読もうとした場合の読みやすさは 段違いである、と言って良いと思う。このような用語がタグとなって100も200も登場するような文書があれば、その差はさらに開いていくはずだ。
ちなみに読み手の母国語（この場合は日本語）でXMLのタグを付けることに関して、他の人はどんなことを言っているかを確認しようと、xml-users メーリングリストのアーカイブを眺めてみたところこんな記述が見つかった。
名前を付けるなら:
1. 日本語がよい。例: <結論>
2. 次善はまっとうな英語。例: <conclusion>
3. 日本語のローマ字書きはよくない。例: <ketsuron>
4. そして最低なのは、番号。例: <R0073>。
([xml-users 1032] Re: 漢字を使おう)
これ、実はかなり古い時期(1999年)に投稿された記事なのだが、これに対する他のメーリングリスト参加者からの異論は出ておらず、 その後も日本語タグに関する記事がちらほらと出ているところからして、タグに日本語（≒英語以外の言語、といって良いか）を使うことの妥当性については、 それなりの合意が取れていると思っても良さそうである。
■ プログラミングはどうなる
XMLのタグを英語でなく、読み手の母国語、例えば日本語で書けば、「XML とアフォーダンス」で言われているような夢は（潜在的な利用者、つまりその母国語を使わないようなユーザの数と引き換えに）その実現 可能性を一気に増すことになる。
…が、これはXMLデータを処理するプログラムを作る側にとってもう一つ面白い（頭の痛い？）副作用を提供して くれることになりそうだ。つまり、基本的に英語ベースで書かれていたプログラムの世界に、それ以外の言葉（日本語）が本格的に攻め込んでくるきっかけにな りうる、ということ。
だってタグ名に「流動資産」と書いたら、プログラム中でそれに対応する変数名をいまさら"CurrentAssets"とか書きたくな いでしょ。英訳し直すタグが一つだけならばいいけれども、これが100個も200個もあったら最悪だ。"RyudouShisan"とかするのはなおさら ダメ。 上で引用した[xml-users 1032] Re: 漢字を使おうでも、「日本語のローマ字書きは良くない」とあるのに、XMLデータでダメなものがプログラムの中に 入ったらOKなんて理屈が立つはずもない。
「変数名に日本語を使うなんてどうかしてる」というのが、プログラミングの世界での今までの常識（暗黙の了 解）であったが、それが一気に崩れるということだ。さあどうする。
■ まとめ ― 二つの問い
上の話はそのままどこまでも展開していきそうだが、キリがないので今回は一旦まとめてしまおう。まずここまでの話を整理する：
でもって、上の仮定がもし正しいとした場合には、
という二つの問いが生まれることになる。どちらの問いも（少なくとも僕にとっては）面白いので、もうしばらくの間考えてみることにした い。
# kenn [面白い考察をありがとうございました。 そうなんです。英数字タグという制約は、 １）プログラミング言語とのバインディ..]
# 福盛 [コメントありがとうございます。真面目な答えを考えているうちに、いつの間にか上の２）３）の逆、つまり 「自分の国の言葉..]
# (・Θ・) [昔PC-88VA2のBASICでプログラムを組んでいるときに、変数名に日本語が使えると分かり、全ての変数を日本語で書..]
# おのの [そういえば、かなり昔に「ぴゅう太」の日本語BASICってありましたよね…。おお、23年も前か。 http://ja...]
# 福盛 [「ぴゅう太」かぁ、懐かしい…昭和は遠くなりにけり、ですねぇ。 というのはとりあえず置いといて :-) 本題へ。 先..]
# たろすけ [昔、2bytes文字をコンパイラがシンボルとして認識可能な文字列に変換するプリプロセッサを書いた事があります。で、そ..]
# anomaly [それぞれの国で 見る時 だけ母国語に変換すりゃいいんじゃないすか？ ]
# fukumori [> それぞれの国で 見る時 だけ母国語に変換すりゃいいんじゃないすか？ 純粋に技術的な観点で見るのならば正解だと..]
ソフトウェアの「インタフェース」にまつわる、もろもろの呼び名について、以前から一つ気になっていることがある。今回はそれに関する お話を。
■ 「インタフェース」にまつわる既存の用語を整理・図示してみる
まず用語を整理するところから始めよう。ユーザに対するインタフェースにはGUI(Graphical User Interface)とCUI(Character User Interface)があり、かたやプログラミングのインタフェースとしてはAPI(Application Programming Interface)というものがあり…というのを図にしてみると、こんな風になる。
だが出来上がった図を見るとなんだか、しっくりとこない。そもそもUIのとなりがAPIというのはどうも座りが悪いのだ。APIの定義 は、例えば
（APIとは）標準化され、文書化されたプロトコルとデータ構造のことを指す。APIは外部のソフトウェアアプリケーションによ る、一 次(primary)ソフトウェアシステムへの一貫性のあるインタフェース(consistent interfacing)をサポートするものである。
(BBN Technologies Glossaryより、やさぐれ訳)
にあるように、（大まかには）外部に提供することを意図したプログラミングインタフェースのことを指す。だが実際のプログラムでは、外 部から使われる部分だけでなく、内部に閉じた部分でもインタフェースを意識する必要がある。具体的には一般に公開することのない箇所でも、例えば構造体や 関数、あるいはクラスやメソッド、などをきちんと定義し、それを使うということだ。しかしその「内部向けプログラミングインタフェース」 に対 応する名前というものを僕は今までに見たことがない…
■ 図の修正と新しい用語の導入
…ということを考えながら書き直した図がこれだ。
PI(Programming Interface)とか、IPI(Internal Programming Interface)とかいう、怪しげな名前を捏造してしまった。でも少なくともUIのとなり にくるなら ばPI(Programming Interface)というのがあってもいいんじゃないかな。で、APIはその下に座るという構図は、バランスとしては正しいように見える。
問題はIPI(Internal Programming Interface)という名前だ。ここはAPIとバランスをとるならばSPI(System Programming Interface)とするのが妥当なのかも知れないのだが、APIが事実上「外部プログラミングインタフェース」を意味するのに対し、SPIでは「内部 プログラミングインタフェース」という印象を持たせにくいことから、ここでは仮に"IPI"としている。
■ まとめ
ともあれ、今回の話で言いたかったのは、
ということ。IPIという名前自体は必要ならば後で修正すれば良いが、少なくともPI(Programming Interface)という呼び名と、その下に展開される階層構造は、UI(User Interface)に対置する存在として必要なのではないかと思う。いかがだろうか。
# arton [>対抗していたころよりも前のもののようだ。 だと思います。1980年のオリジナルを元にLMIとSymbolicsで付..]
# 福盛 [なるほど。今回のソースコードはある意味でオリジナルに近い(というかオリジナルそのものといって良い?)という意味で貴重..]
# arton [へー、面白いですね。 さらに検索していたらこんなトリビアも。 「CG 用コンピューターを開発していた米国 Symbo..]