時差があるので、ここではまだまだ９日です(日本時間では10日朝5時)。
スラッシュドット・ジャパンでも話題になっていたTim O'Reillyのキーノートを聞いてきました。
内容は事前インタビューなどにあった通りで、 別に目新しい内容はなかったのですが、世の中の変化という点からは興味深いものでした。
差別化が独自ソフトウェアによって行われていた時代から、 ソフトウェアそのものはコモディティ(日用品、どこにでもあるもの)になって、 それの組み合わせと蓄積したデータなどによるの「サービス」によって差別化される時代になった、 あるいはなりつつあるということか。
が、それってうちの会社がはるか以前から行っていたような気がする。 まあ、うちは直接サービスを提供しないので、差別化は主に価格と技術力と知名度で行っているわけだが。
そういえば、彼はDynamic Languageの効用を強調してました。これはインタビューには載ってなかったと思います。
マイクロソフトは３年ごとにリリースしているが、Yahoo!やAmazon, eBayは毎日でもリリースしている。 そのような速いサイクルの開発にはDynamic Languageが最適だという論旨です。
確かに。注目されるのはありがたいことです。
もっとも、いくら注目されても
では、Dynamic Languageのデザイナーは報われないことです。 今のところ私の立場は安泰みたいですけど。
追記
転職と無職じゃえらい違いという指摘が。でも、GuidoもZope Corporationが資金がショートしそうで転職せざるをえなかったということですから、言語デザイナー受難の時代に変わりはないようです。
OSCONの昼食はMicrosoftがスポンサーでした。曰く「Free as in lunch :-)」だそうです。
サンドイッチにナノマシンが入ってて、洗脳されて.NETでしかプログラムが書けなくなったら
などと冗談をいってましたが、現時点では大丈夫のようです。
私をはじめ何人かのDynamic Language関係者たちは夕食もMicrosoftにごちそうしてもらいました。 で、そこで私はLarry Wall, Guido van Rossumをはじめとする有名人とごあいさつしました。
Larryは日本語が上手になっていました。
皿があります 有名な人です
また自作の日本語学習プログラムも見せてもらいました。部首などからも単語が引ける力作でした。 すばらしい。
しかし、アメリカの食事ってどうしてあんなに大盛りなんでしょう。 隣の人が食べてたチキンなんで鶏半分まるごと(は冗談です。腿を1本まるごとくらいかな)が皿に乗ってました。 こんなには食えない。
昨日、Estraierでauthor属性の検索ができないとか書いたら、 さっそく平林さんからメールをいただいた。近いうちに対応していただけそう。ありたがいことだ。
追記
改めて調べたらEstlaier 1.2.16が出てるじゃありませんか、今まで1.2.7なんてのを使ってました。 メールオーガナイザーを作ろうと思った時に入手したのに、もうこんなに進歩してるとは。 いつのまにか正規表現やワイルドカードでも検索できるようになってるし。
昨日の時点で、関連検索以外のバックエンドはほぼ動いたので、 今日からフロントエンドを作ろう、と思っているのだが、 今までバックエンドのことばかり考えていて、 フロントエンドはイメージが固まってないので、 またしばらくはぐたぐたと脳内で考える日々になるのかもしれない。
なんか、いつだって何日も(あるいは何ヶ月も、何年も)ぐだぐたと考えないと、 コーディングに入れないのは年取ったせいだろうか。
追記
結局、フロントエンドには手をつけず関連検索を実装しました。
Debianのパッケージが更新されたので、0.1.7にアップグレードする。 すばらしい。
今までFirefoxと交代で使っていたが、これ一本に集約できそうな気がする。
すばらしい点
気に入らない点
しかし、気に入らない点も些細なことばかりなので、我慢できる。
Sun Microsystemsという企業がどのような経営判断するかどうかは、 私の手に余るので、「オープンソースプロジェクトのフォークと互換性」という点に絞って考えたい。
ここ数日いただいたコメントからは、 なんとなく「オープンソースではメンテナが望まないフォークが発生して、互換性を維持できなくなるケースがある」という暗黙の過程があるような気がする。
たとえば、
オープンソース化されれば、差別化、重視になるでしょう。
一部のコミュニティが互換性を無視することに対してコミットして、互換性は失われる方向になる。
オープンソース化すると、誰にも互換性の維持はできない。
あるいは
私は、仮にJAVAをオープンソースとした場合、SUNがリーダーシップを取れなくなってしまう「可能性がゼロでない」のを恐れているように感じます。 些細な分岐がSUNに変わる本流となりえないとは言い切れないところに躊躇しているんじゃなかろうかと推測してます。
あるいは
言語系とか（TEXなんかも含めて）は、これまで蓄積してきたソース・スクリプト（コンパイラ・インタープリタ側からみると「データ」）の互換性がでかいですよね？ だから「forkをおそれる」という企業のスタンスはよく理解できます。 「旧バージョンで動いていたプログラムが新バージョンで動かない」というサポートはとても面倒。ましてや「新バージョンはウチじゃなくて別のコミュニティで勝手にコミットしてるんですがーーorz」なんて間抜けな対応したくないでしょうし。
とか。
Mr.orzさんのコメントを取り上げてみれば、 前半の「互換性がでかい(重要ということか？)」というのは十分に理解できるのだが、 「forkをおそれる」というのはどういうことを想定しているのだろうか。 どのような事態が発生することをおそれているのだろうか。
オープンソース化しなくても新バージョンを出せば互換性問題の危険はあるし、 オープンソース化しても、勝手に「新バージョン」がリリースされるわけじゃない。 フォークはあるかもしれないが(めったにないけど)、 そんな場合でも「そのフォークはうちは知りません」の一言で済むはずだ。
オープンソースではフォークを禁止することはできない、これは事実だ。
しかし、メンテナが互換性を維持したいと望んでいるのに、 フォークなどの理由によって互換性の問題が発生するようなケースがあるのだろうか。 より厳密には、オープンソースだからという理由で互換性の問題が発生しやすくなることがあるだろうか。 私には想像できない。
私は「オープンソースが原因で互換性の問題は発生しない」と思っていて、 7月6日のエントリでも7月7日のエントリでも、 その理由を説明してきたはずだ。もちろん、あれでは「ゼロであること」を証明できてはいないが、 それはムリな相談だろう。やや危険なたとえを使うと、交通事故の可能性はゼロではないが人は車に乗るわけだし。
これは「オープンソースで互換性の問題が新たに発生しない」という意味で、 逆に言うと「オープンソースでなくても互換性の問題は発生する」と読み替えてもかまわない。
かつて「メンテナが望まないフォークが発生して、互換性を維持できなくなったケース」あったのだろうか。 これからありえるのだろうか。それともFUDにすぎないのか。
それをはっきりさせたいと思っているのだ。 もし、具体的なイメージはなく、ただ単におそれているだけならばかばかしい。
企業が自分のプロダクトをオープンソースにするもしないも、その企業の自由だ。 オープンソースというやり方を信じられない。結構。 オープンソースにしない方がビジネス上有利だと思うから。結構。 苦労して開発したソースは秘密にしたい。それも結構だ。
しかし、「オープンソース化すると互換性が損なわれるから」などという、 事実でないことを理由にしてほしくない。
言語の互換性問題と言えば、各種「方言」問題がある。たとえばPascalはいろいろ方言があり、 結局ある方言(コンパイラ)用のプログラムは、別のコンパイラでは動かない(ので結局別の言語と同じ)というような。
でも、このような方言問題の原因は、オープンソースではなく、 不完全な(あるいは曖昧な)言語仕様とそれに基づいた独自実装によるのではないか。 オープンソースの処理系があれば独自実装の必要性は薄れ、むしろ方言問題は回避できるのではないか。
Javaについては、おそらくはマイクロソフトの「J++ショック」が尾を引いているのかもしれない。
気持ちは想像できるが、その問題はSunのJDKのライセンスをオープンソースにしないことでは回避できない。
SunがJDKをオープンソースにしようとしまいと、 やろうと思えば、今日存在しているオープンソースJavaコンパイラ(たとえばgcj)を改造して、 Java方言を作るのは簡単だ。
私の知る範囲でプロジェクトのフォークが発生するのは次のような理由だ。
進歩の方向に意見の対立が発生し、意見の調整ができなかった。
この場合には「本家」はそのまま存続するので、本家についての互換性は問題ではない。 分家と本家との間には互換性の問題はあるが、これはオープンソースに限らない(独自実装とか方言とかの問題)。
メンテナがメンテナンスを放棄したが、後継者が複数登場し、一本化ができなかった。
「本家」が放棄されているので、少なくとも互換性は問題にならない。
あと、可能性としては「ただフォークしたかった」というものもあるのかもしれない。
オープンソースでフォークが発生すると、重複した作業が発生するので、 リソースの無駄づかいが起きるし、進歩が阻害される傾向があるので、 望ましくない。しかし、たとえ発生したとしても、すくなくとも「互換性」の問題は発生しない。
ありがたいことに、フォークというのはめったに起きない事態だ。 これはオープンソースプロジェクトではオーナーシップが尊重されていることを反映しているだろう。
日曜日は用事があるので、役場で期日前投票を行う。 国民の権利であり、義務だから。
もっとも青木自民党参議院幹事長を擁する島根県では結果が見えているわけで、 投票行動に対する動機づけが希薄なのは確かなのだが。
本番。ホテルから歩いて北大、クラーク会館まで移動。
いろんな人が来ているので御挨拶。 高橋さんもいらしてた。 日本Rubyの会はYARVのポスターとRailsによるブログツールTypoを展示していた。 TypoはAjax風味の表示が結構すてき。
日本Rubyの会の展示の隣はZopeが展示していた。 展示していた人は、私の顔を知らなかったようなので、 以下のような会話が交わされた。
展: プログラミングはなさいますか
私: ええ、すこしは。
展: 私はプログラムしないんですけどZopeは便利ですよ
私: Pythonの文法は知ってるんですけど
展: 使わないんですか
私: あんまりPython使わないですねえ。
展: 宗教上の理由とか(笑い)
私: いや、そーじゃなくて仕事上というか、立場上というか(苦笑)
展: そうなんですか(真顔)
...以後、ZODBに関する面白い話が続く...
そうこうしているうちにお昼になって、 スタッフの人が呼びにくる。「まつもとさん、こっちこっち」。 言われるままについていくと、 北大の敷地内芝生にビニールシートを敷いて、 七輪並べてジンギスカンを始めている。
なんとのどかな。
私の母校も敷地の広さでは負けないと思うのだが、 そんなのどかさはなかった。 私の発表は午後一番なので時間の余裕はなかったが、 しっかり堪能した。 しかし、私の一族のマスコット動物は羊なのだが、 それをよろこんでばくばく食べるというのはいかがなものか。 母親あたりにひどく怒られそうな気がする。
で、午後は発表。スライドはここ。
ま、わりとふつーの発表。なんかどこかで聞いたような話が多いけど、 まあ、こういうイベントは北海道では珍しいだろうから、 基本的なことから。基本的すぎて聴衆がどう感じたのか不安だったが、 数人に感想を聞いた範囲内ではおおむね好評であった。
発表終了後、松江に置いてきた妻子とSkypeで話をしてから、 北大博物館へ。やっぱりここまで来たらマンモスを見ておかないと。 次女が「どうしても見てきてほしい」ということだったし。
展示はこじんまりとしていたが、貴重な資料がたくさんあって、面白かった。 閉館直前であったがしっかり写真も撮ってきたし。
その後、みんなで移動して懇親会。そろそろ疲れが出てきていたが、
などなどについて。
懇親会終了後、みんなが「じゃあ次だ」と移動を開始する。 9時過ぎに会場を出て、予約が10時だということで、 「じゃあ、それまでラーメン食べにいこう」とかいう人までいる。 この人たちの胃袋はどうなってますカ？
と思ったが、実際に二次会の会場(石鍋屋)に着いたら、 ジンギスカンやらモツ鍋やらばくばく食べてしまう。おいしい。 私の胃袋もどうにかなってますヨ。
食べながら、Rubyは金の匂いがしないとかなんとかいう話もする。 そのうち、うち(NaCl)が「Rubyで10倍の生産性」とかなんとかプレスを打って、 世間の注目を集めたらちょっとは状況が変わるかな。変わらないような気も。
酔えば酔うほど高くなる高林さんの声。大企業の中の人は大変だ。
三次会に行くという人もいたが、 それは振り切って、東横インへ。ロビーの無線LANを使わせてもらいつつ、 morqのハックを。それから歩いて自分のホテルに帰り着いたのは夜中の2時をはるかに回っていた。
後輩が「月曜日にはどうしても必要なので」とせがむので、 morqをハック。今まで基本的にEstraierをベースに検索していたのだが、 当初の構想の通りRast上で動くように変更した。 で、前田くんのximapdを参考にさせてもらいつつ、ごそごそやっていたら、 1時間ほどで完成。東横インからホテルへ移動。
しかし、そこでマシンがハング。 そういう時に限って /tmp で作業していたりして、 1時間の成果を失った。出張中だし、夜遅いしでちょっと気が焦っていたのだろう。 普段なら致命的なファイルを /tmp に置いたりしないのに(本当か？)。
いずれにせよなくなってしまったものは帰ってこないので、 再挑戦。一度実装しているので今度は20分ほどでとりあえず動く。 何回か試してバグをとりのぞくとうまく動いているようだ。 完成したのは4時前だった。
OSC2005-DOの会場で高橋さんたちとした話。
なぜ私はいつまでたってもテスト駆動アプローチを習慣にできないのか、 改めて考えてみるとやはりドライブ感が原因のようだ。
「なにかを作りたい」と思った時、 テストファーストなら「そのなにかをテストによって表現する」わけだが、 私はその作りたいものがコードとして脳裏に浮かぶのだ。 そこでテストを書いていると、その浮かんできたコードがどこかへ逃げてしまうような気がする。 脳裏に浮かんだコードが消えてしまわないうちに、 素早くタイプして書き留めてしまわないといけない。
いわば「イタコ系プログラマ」。
いや、言い訳なんだけどね。とりあえずコードを打ち込んでからでいいから、 ちゃんとテスト書こう。
末娘が熱が出たとのこと。突発性発疹の疑いとか。出張中に限ってこんなことが。
6月にお話を依頼されていたのだが、 ちょうどファイアサイドの日だったので、 中止になったのだった。
安心していたら、監督から「7月9日に同じテーマで話をしてください」とのこと。 甘くなかった。
テーマは「謙遜」。正直、あんまり得意なテーマではない。
ま、理由はいくつかあって、ひとつは基本的に私は態度がデカい点。 行儀が悪いのと、外からはいつもリラックスしている(ものおじしない)ように見えるから、 らしい。内側は小心者でいつもビクビクしてるんだけどね。 外見に出すのはかっこ悪いと思ってるらしい。
もうひとつは、なんだかんだ言っても自分のしてきたことに自信があることだろうか。 人から尊敬されるプログラマと見なしてもらえるようだし、 世界的なプログラミング言語の設計者でもあるし、 そのことであちこちから仕事の依頼は来るし。
ま、そういう状態でキリスト教の勧める「謙遜」を維持するというのは 一種のチャレンジなのかもしれない。 「金持ちが天国に入るのはラクダが針の穴に糸を通すより難しい」そうだからな。
あれ、なんか違うような気もするが、ま、いいか。
あと、謙遜の反対、高慢の本質は「他者への敵意」なんだそうだ。 他の人を押しのけて自分が利を得たいとか、他人を見下すとか。
つまり、自信家であっても、能力が高いと自負していても、 他の人に親切にできるなら、理論的には高慢でないことができるというわけだ。 なかなか難しいけど。そういうところを目指していきたい。
スクリーンキャスト。JavaとK(APLの末裔)の比較(英語)。
まあ、このタスクが圧倒的にK向けということを置いておいても、 ベクタを扱うプログラムにおけるAPL系言語の生産性は間違いない。 ある程度はRubyにも取り込みたいんだけど、 どういうAPIにするのが良いかなあ。
まずは複数のベクタ(配列)の各要素に対して処理する(APLでいう
v1 + v2
でv1とv2の各要素を加算した配列を得るような)メソッドをEnumerableに加えればよいのかな。 良い名前が思いつかないけど。
セキュアなRailsプログラムの作り方。 こうやってまとめておくとありがたい。