THANK YOU MATZ for a scripting language where parts don't snap off the objects and choke small children. -- Rasputin
お子さまにも安心なRubyをどうぞ、ってか。
次女が熱を出した。また風邪かしら。 この冬から春にかけてわが家はたびたび風邪に襲われている。 これで何度目か。
来週金曜日に開催される「第103回ヒューマンインタフェース研究発表会」のプレゼンテーション資料を書きはじめる。
昨年松江で開かれたソフトウェアシンポジウム2002のキーノートを聞いた中小路先生が呼んでくださったのだ。 タイトルは「インタフェースとしての言語のデザイン:Ruby」というもの。 プログラミング言語はユーザインタフェースであるという(私にとってはいつもの)話をすることになる。 ユーザインタフェースという観点から見た言語デザインが一般のインタフェースのデザインに役に立つように還元できるといいなあ、と思っているのだが、はたして。
プレゼンテーション資料は公開する予定。
YAMLの方が1024倍良いという主張をより明確にしたい。
まず、前提から。前にも述べたがあらゆる局面でYAMLがXMLより優れていると主張するつもりはない。 YAMLは基本的には構造データ表現フォーマットである。 文章のマークアップの領域でXMLと競うのは無意味だ。「YAMLの方が良い」という主張は当然「汎用データ表現」、 今月のLinux Magazineで使った用語を使えば「メタ・データフォーマット」として、という意味だ。
では、そのような前提のもとに、なぜYAMLが優れているか。
データ量
XMLを採用するとデータが膨らむのは多くの人が経験している通りだ。 その理由はテキスト形式を採用していることもあるが、なによりもあのタグ形式が原因だ。 XMLってなんであんなに冗長なんだろう。その点、YAMLは記号とインデントで表現がコンパクトである。
可読性
YAMLの表現がコンパクトであると言うことは、すなわち読みやすさにつながる。 もちろん、YAMLだって万能ではないので、読みにくいYAMLは当然あるわけだが、 YAMLで読みにくい構造データは、当然XMLでも読みにくい。逆は必ずしも成立しない。
柔軟性
XMLとYAMLを比較すると、XMLの方が圧倒的に柔軟性が高い。 XMLはスキーマによってあらゆる構造が表現可能だし、 「構造データも表現できる柔軟性がある」というだけで、構造データ表現専用というわけではない。 一方、YAMLにもYOD(YAML OK Document)というドキュメント形式があるが、 やはり構造データ表現のためのフォーマットと考えるべきだ。 YAMLは「XML＋スキーマ」と同等の位置づけになるだろう。
柔軟性がある方とない方を比べたら、ある方が良いように感じられるかもしれない。 しかし、なんでもできるツールが使いやすいツールとは限らない。 むしろ目的に適合したツールの方が優れたツールである可能性のほうが高いだろう。 また、過度の柔軟性は人間に優しくないことを覚えておくべきだ。
使いやすく、現実に即したAPI
XMLを解析するAPIとしてはDOMやSAXがある。 しかし、構造データ表現のためには整形式では情報が足りない。 XMLを読み込んで取り出したノードからプログラム側で適切に型変換してやる必要がある。 XMLスキーマには型情報が含まれる(らしい)が、お手軽にXMLスキーマを使えるAPIってあったっけ。 一方、YAMLはロードとセーブのふたつのAPIでとりあえず利用できます。 YAMLデータは型情報を含んでいますから、型変換を気にする必要はありません。
「XMLは現代のＳ式」と呼ばれることがある。 どのような構造データもとりあえず表現できるという点ではその通りだろう。 しかし、一般人に広く知られてしまったという点でＳ式より罪は深い。 『図解で分かるＳ式とLisp』なんて本は今までもこれからも出版されないだろうし。
追記: 「YAMLが良い」という主張にもうひとつ暗黙の前提があるのに気がついた。それは「人間が読み書きする可能性がある」という点だ。人間の目に触れないならYAMLである必然はないものね。
今日は母の日である。とりあえず一番身近で「母」をやっている人をねぎらおうということで、 昨日のうちにこっそり買っておいた花を妻に贈る。 妻はカーネーションは好きでないと言うことなので、ピンクのバラの鉢植え。 この方が長持ちするだろう。
しかし、花は喰えないのにな、どうしてあんなに喜ぶんだろう。謎だ。 そりゃ、きれいだけどさ。
教会。松江出席はありがたい。が、今日は元々松江の日だったな。 風邪を引いているので、わりとおとなしくしている。集会終了後も早めに帰る。
夕方、浜松の母から電話。花が届いたとのこと。 そういえば妻が双方の母親に花を贈ったって言ってたっけ。 風邪でぼーっとしてわすれていた。 よく気がつくことでありがたい。
浜松にもいろいろあるらしい。後、半年、がんばってくらはい。
講習会はサラリーマンコスプレ、という話であったが、 正直くたびれたスーツしか持ってない。 毎日曜日、教会にはスーツを着ていくのだが、 そのまま子供の世話したりするので、 けっこう汚れたり傷んだりしてるのだ。
というわけで、スーツを買おうかなあ、と思っていたのだが、 なかなか時間が取れず、とうとう出発日になってしまった。
で、スーツ購入。なんだか泥縄で恥ずかしい気がする。
その後、東京へ移動。 くたびれたのでそのままホテルに移動。原稿を書く。
昼食時に妻に「夕食は吉野家の牛丼でしょう」と言われた。 今は吉野家、牛丼出してない、ということは置いといて、 そういうチープな食事が好きだということを見ぬかれている。
で、結局実際の食事はどうなったかというと、 コンビニのおむすびでした。もっとチープだ。
SIerの老舗CECがOSSの「新たなビジネスモデル」を模索中、という話。
あくまでも「模索中」であるせいか、 全然目新しさがない。商用ソフトとOSSを適材適所で組み合わせる という発想も、新しいどころかむしろ古臭い印象を与える。
日本で、大手SIerさえもOSSを無視できない、という点は やや話題性があると考えられないこともないが、 2007年の話題でもないよなあ。
もう一歩、新規性のある話題を期待したい。
Ruby on SolarisでDTraceが使えるようになったという話。
噂によるとTwitterのパフォーマンス危機の際には、 (サーバがSolarisだったので)DTrace for Rubyが活躍した、ということだ。
プロファイリングはパフォーマンス改善の基本なので、 優れたプロファイルが提供されることはとてもありがたいことだ。 問題は手元にSolarisがないことだな。
会社にはSolarisサーバが一台あるけど。
AACS LAがBlu-ray Diskのキー(09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0)*1を 載せているサイトに削除するように要請した、という事件から あちこちで祭りが起きているのだが、 AACS LAが128bitキーの「所有権」を主張できるのあれば、 私も同様に主張できるはず というのが、リンク先のエントリ。
このページを見に行くと、あなたのための128bitを用意してくれる。 ちなみに私の128bitは
A8 91 34 24 E1 7D 66 DD 5D 70 94 A5 D4 45 EA CF
であった。
*1 これを載せたので私のところにも通告が来るのかな
パートナーであるJavaへの別れの言葉。「さよならJava」
もう10年、一緒にやってきたけど、もうダメだと思う。 君が悪いってわけじゃない、いや、やっぱり君が原因かな。 僕はもっと若くてかわいい人に出会ってしまった。 そう、君の妹、C#さ。
言いにくいんだけど、君は整形手術が必要だと思う。
そもそもAWTの始め頃になにかが間違ってしまっていた。 Swingでそれはさらに悪くなった。
君はわかってない。ユーザインタフェースフレームワークの目的は 開発者が優れたユーザエクスペリエンスを構築するためのものなんだ。 それなのに君は美しいAPIやプラットフォーム中立性、 それにマイクロソフトを排除することばかり考えてた。
(後略)
JavaOneでのTim Brayへのインタビュー。
注目すべき点
サン・マイクロシステムズでWebテクノロジー関連のディレクターを務めるティム・ブレイ（Tim Bray）氏は、近い将来にプログラマが直面する問題は、CPUのコア数が増えてハードウェアの並列化が進むのに対して、現在使われている言語の多くで並列プログラミングのサポートが十分でないことだという。
ブレイ氏は、こうした問題に対して2つの方向性で解決を模索しているという。1つはグーグルが作った分散処理のフレームワークで「MapReduce」と呼ばれているもので、数万個のCPUで膨大なデータ処理をするといったときに有効だ。すでに、MapReduceをJavaで実装した「Hadoop」（ハドゥープ）というものがあるという。
「Hadoopは外部ライブラリですが、Java言語自体で並列処理をサポートすることも必要」（ブレイ氏）といい、そのモデルとして2年ほど前から“Erlang”（アーラン）に注目しているという。「Erlangはエリクソンが開発した古い言語ですが、とても興味深い特徴を持っています。きわめて効率的にプログラムの並列化ができ、ふつうのAMDやインテルのCPUを使って25万スレッドを動かすこともできます。ただErlangはオブジェクト指向言語ではなく、関数型言語です。つまり、一般的な言語になじんだ、ほとんどのプログラマには奇異に感じられるので、われわれとしてはErlangが持っているいいところを、もっと身近なRubyやJava に入れていこうと考えています」。Java上で動くRubyの実装であるJRubyが、本家Rubyより先にこうした並列処理サポートを取り込む可能性もあるという。
関数型言語は、一般的な言語とコードの書き方が大きく異なるものの、いずれJavaに関数型プログラミングの要素を入れていくことも必要だとブレイ氏は語る。「関数型プログラミングは、並列プログラミングに適しているばかりでなく、テストもやりやすいのです」。関数型プログラミングに対して感じる違和感について、「かつて、オブジェクト指向プログラミングは難しすぎて一般プログラマには習得できないといわれていましたが、今では当たり前のように使われていますよね。関数型プログラミングについても同様かもしれません」と楽観的な見方もあると指摘する。
マルチコア上でのスケーラビリティが将来のキーとなる点、 関数型プログラミングの要素(って、どこまで考えてるんだろう)が 有効である点においては同じところを見ているような気がする。
しかし、
Java上で動くRubyの実装であるJRubyが、本家Rubyより先にこうした並列処理サポートを取り込む可能性もあるという。
ってのはどういうことよ。負けてはいられないなあ。
Sunがオープンソース開発者に報酬を与えるというような話。 「お金だけが動機ではない」というごく普通の「オープンソース開発者」のコメントが続いている。
詳細がわからないので、これ以上コメントするのは難しいが、 Sunがちゃんとしたプログラムを用意して、 オープンソース開発者がなんらかの報酬を得られる新しいチャネルができるというのであれば それはそれで歓迎すべきことである。
たとえ、それによって恩恵を受ける開発者が いわゆる「オープンソース開発者」全体からいえばごくわずかであるとしても。 当然ながら。
本当は日曜日が〆切だった。あせあせ。
今回のテーマは「APLとJ」。 APLはプログラムが、「読めない」、「書けない」、「表示できない」の三拍子なので、 簡単に触れるだけで、実際のサンプルは簡単なJで。
とはいえ、考えてみるとAPLってのは40年前にMapReduceを実現してるんだよなあ。 もちろん分散じゃないけど。