Matzにっき

_ [生活]確定申告

ようやっと済ませた。また〆切ぎりぎりだ。

手順は簡単。まず昨年分の支払調書を集めて金額を計算しておく。 それから、昨年集めた領収書のうち、経費分を合計しておく。

後は源泉徴収票、支払調書を持って 確定申告会場に行き、係の人に相談すれば終わり。 PCで申告用紙に入力後、印刷までしてもらえる。 私の場合には玉湯町中央公民館が会場だ。 待っている人もおらず、15分程度で完了。らくちん。

_ [本]Hacker and Painters

Paul Grahamからメールが来た。「今度O'Reillyから論文をまとめた本を出すので、 "Blurb"を書いてもらえないか」だそうだ。"Blurb"ってなんだろうと思ったら、

Blurbs are those quotes where people say "this is a good book."

なんだそうだ。

そういえば、海外の本の裏表紙にはたいてい「この本は素晴らしい」とかほめる言葉が載っているっけ。 私はPaul Grahamの論文のファンだし、彼の主張の多くには大変共感している。 大変名誉な事なので引き受けようと思うのだが、身に余る気がしないでもない。 ちなみにforewordはEric Raymond。

載る論文のリストは以下の通り。

• Hackers and Painters
• Taste for Makers
• What You Can't Say
• Why Nerds are Unpopular
• The Other Road Ahhead
• Ho to Make Wealth
• Mind the Gap
• A Plan for Spam
• The Hundred-Year Language
• Beating the Averages
• Revenge of the Nerds
• Succinctness is Power
• Why Arc Isn't Especially Object-Oriented
• The Roots of Lisp
• The Dream Language
• Design and Research

私の好きなのは、「The Hundred-Year Language」と「Succinctness is Power」。 「The Dream Language」って読んだことないな、と思ってたら 「Being Popular」の改題のようだ。

これらのほとんどにはShiroさんによる訳ができているので、 オライリー・ジャパンからも出版するのはどうだろうか。

_ [教会] 新見

ステーク大会土曜の部で新見に。 前々からおそれていた通り、朝から雪。

今回は国道181号経由で新見に向かったが、 明地峠が積雪と凍結で大変。スノータイヤが減っているのもあってかなり恐かった。 峠を抜ける30分でぐったり疲れた。

集会は第一部、第二部ともにわかりやすくてよかった。 もっとも、「わかる」だけじゃだめで、実践が伴う必要があるんだけど。

ある人が「事故をみかけたが助けてあげるべきだったかもしれない」と話していた。 私たちも来る途中スリップしてガードレールにぶつかった車を見かけたが、 特になにもしなかったのを思い出す。運転手にもけががなさそうだったし、 とりあえずなんとかなりそうだったのだが、声かけくらいはしてもよかったかも。

帰りの峠は完全に凍結していて、チェーンが必要だった。 車に乗り換えてから14年になるがチェーンを使ったのは初めて。

滑らないから恐くはないが、うるさい。

_ 言い訳

おくじさんの日記から。

私が応募者に必ず尋ねる質問の一つに、「フリーソフトウェア・プロジェクトに参加したことがありますか」というのがあります。「ない」というのが大多数で、決まって「時間がないので」と言います。

応募者はほぼ学生なんですが、これは絶対に言い訳でしかありません。学生より暇な人種がこの地上に一体どれぐらい存在するでしょう。

(中略)

じゃあ、本当のところ何なのかと言うと、単なる意志の欠如だ、と話していたのです。かなり高い確率でそうだと私は信じていますが、一方で新たな疑問というか、納得しきれないところもあります。

うむ。そろそろ面接希望の人も出ているし、来週には会社説明会もあるし、 この質問を聞いてみようかなあ。

ただ、うちの場合、松江での面接希望者の大半は「松江にある(面白そうな)ソフトハウス」という認識で就職を希望するＵターン希望者のような気がするから*1、フリーソフトウェアの関りは期待できないかなあ。

つまるところ、エネルギーの問題なんですかね。電気とかじゃなくて、人間の持つ精神的活力というやつ。実際、長期的に活動している人って、みんなエネルギッシュだもんなあ（私自身は疲れ気味にしか見えないかもしれませんが）。

うーん、エネルギーの問題というのはありそうな気がします。 それより大きいのは敷居かなあ。なんだか敷居が高いみたいなんですよねえ。

_ [教会] ステーク大会

ステーク大会。電話があって「1時間早く来て下さい」と言われてあせる。

新見まで移動。始まるのが午後からなので、出発はいつも教会に出かけるのとさして変わらない。

米子から181号を使って新見へ。100Km、約2時間。

面接。両親や弟たちと一緒に昼食。

ステーク大会。松江ワードの監督会が再組織。 また副監督に召された。今度は第一。

若い人、そうでもない人などいろいろな人からお話を聞いた。 大変興味深い。今回はわかりやすい話が多かった気がする。

松江に帰る。無事に帰れてよかった、よかった。

_ [言語] インド語の「あいうえお」

昔からなぜ「あ、い、う、え、お」という順番なんだろう、と不思議に思ってはいたが、 まさかインドに由来があるとは。

以下はインド方言の一つBrahmi語 インド地方のBrahmi文字の一覧。 ちょっと母音が多いがおおむね「あいうえお」の順番に並んでいる。 他のインド語でも同様の順序らしい。子音も「あかさたな〜」に近いように思える。

知らんかった。

_ スラッシュドット ジャパン | 文字エンコーディングはUTF8で本当に十分なのか？

先日、「シフトJISを捨てられるか?：ITpro」についてとりあげたら、tagohさんが「The day-to-day thoughts - UTF-8は十分かどうか」と反応して、さらにスラッシュドットでとりあげられた。

厳密な話をするならば、 欠点のない文字集合もエンコーディングも存在しないので、 どのような文字集合を選んでもどのようなエンコーディングを選んでも 不満を持つ人はいるに決まっている。

この文字集合には私の使いたい文字が無いとか、 性能上の問題がどうとか、文字化けがどうとか。 これについては、ケースバイケースとしか言いようがない。

というわけで、各論。

「シフトJISを捨てられるか?」について言えば、要旨は

• シフトJISでは文字が足りない(ような気がする)
• Unicode(UTF-8)では日本語のデータ量が増える
• だったら、新しいエンコーディングというのはどうだろう

というものだ。実際、この記事の流れではUTF-8でダメな理由ってのは、 「日本語のデータ量が多くなること」、「シフトJISではないこと」だけなので、 それってのは「新しいデータ」についてはさほど問題ではないと思う。

「新しいエンコーディング」というものは、

• エンコーディングを決めて
• 実装を提供して
• それを広く使ってもらうように働きかける

という手順を踏んではじめて実用的になる。どの段階もそれなりに大変だ。 特に「広く使ってもらう」というのは技術的な問題ではないので、 相当難しい。今時、単にちょっとデータ量が節約できるくらいの理由で まったく新しいエンコーディングが採用されるってことはほとんど期待できない。

ちょっと考えただけでも、

• 主要なエディタで対応する
• 主要な言語で処理可能になる
• iconvで変換できるようになる

くらいは必須だろうけど、気が遠くなるくらい難しそうだ。

とはいえ、ITproくらい影響力があると(あるんでしょ？)、 なんかで間違っちゃってその気になる人がいないとは限らないので、 うれしくない。

純粋に技術的な観点からは、スラッシュドットで紹介されてた 「新しいUnicode符号化方式」とかは、文字数が多く(Unicode文字集合)、データ量が少ない、という点で条件を満たしている。 本気で新しいエンコーディングを設計しちゃう心意気には感服するが、 実用するのは難しいだろうな。

tagohさんのはもうちょっと違う角度からのツッコミだ。

本当に多言語を扱おうと思えば Han UnificationなどのためUTF-8では十分でないかもしれない、という話だ。 確かにたとえば「骨」の字など、日本と中国では字形が違う。

本当に多言語を扱おうと思えば、TRONコードのようなアプローチの方が良いのかもしれない。 しかし、今度はソートや検索で同一視問題が発生する。 あまり詳しくないのだが、TRONコードを扱うライブラリではその辺の正規化もサポートされているらしいけど、残念ながら誰もが使えると言う状況にはなっていない。

「カジュアルな多言語表現では字形の違いは気にしない」というポリシーもあるかもしれない。 実際、はてなで中国語ダイアリーを書いている人とかもいるわけだし。 「きちんと多言語を扱うのはエンコーディングじゃなくてもっと上のレイヤでいいんじゃね？」という気もするし。少なくとも「言語タグ」なんてものを導入して状態を持ち込む(エンコーディングがステートフルになる)のはさらなる不幸を招きそうだ。

あと、Unicodeは文字集合で、エンコーディングにはUTF-8、UTF-16(BE,LE)、UTF-32(BE,LE)があるという指摘もある。

が、実際問題としてまったくしがらみがない状態であれば、UTF-16を選択するのは正気だとは思えない。だって、UTF-16ってば

• エンディアン問題がある
• しかも、可変長

という過去のエンコーディングの悪いところを寄せ集めたような存在である。 UCS2で話が済んだ牧歌的な時代ならともかく、サロゲートペアが入ってUTF-16になった時点で もうアウトだろう。UCS2時代からのJavaはしょうがないとして、あらたにUTF-16を選ぶ理由はない。 でも、なぜかWin32ってUTF-16なんだよね。

では、UTF-32はどうか。

UTF-32には可変長問題はない。データ量がかなり増えるが、それは無視できるとしよう。 しかし、やはり情報交換用エンコーディングとしてはエンディアン問題が気になる。 個人的には「BOMで解決」なんてのは信じない。いつもついてるわけじゃないし、 逆にデータにBOMなんてタグが「いつもついてないといけない」というのもうっとうしい。 っていうか、Unicode論者はBOMのうっとうしさを軽視しすぎ。

UTF-32が意味があるとすれば、データの内部表現としてじゃないだろうか。 情報交換用に用いないのであればエンディアン問題は発生しないし。 固定長による処理効率が高いのがうれしい人もいるだろう。 でも、UTF-32を直接扱うライブラリはあまり充実していないように思えるんだけど、 それは私が知らないだけなんだろうか。 内部交換用として広く使われるためにはもうちょっとライブラリなどが充実する必要があるような気がする。

というわけで、個人的な印象としてはUnicodeを使うならエンコーディングはUTF-8で決まり だと思っている。情報交換用としても内部表現としても。 欠点らしい欠点と言えば可変長なことだけだし、 われわれ日本人は長い経験から、可変長マルチバイト文字列の扱いが実用になることを知っている。

最後に、非常に興味深いブログエントリ、 「Open ブログ: ◆ シフトJIS と unicode」。

私のエントリも含めて「素人の暴論」であり、「勘違い」なのだそうだ。 私(たち)が素人なのは否定しないけど、その「勘違い」の指摘はあまり上等には思えない。

要旨は

• データ長の問題はどうでもよい
• 文字数の問題も無視してよい(え？)
• Unicodeは各種エンコーディングが乱立している
• だからUnicodeは万人の使うエンコーディングにはならない
• だから現行のシフトJISを拡張した新しいエンコーディング(南堂私案)を

だそうだ。勘弁して。 我田引水とか牽強付会とかいう言葉はこういう時に使うんだろうな。

まず、要旨のうち最初の点には同意する。二番目はちょっと「勘違い」があるみたい。 三番目の各種エンコーディングが乱立している点については、 困ったものだがUTF-8以外のエンコーディングは情報交換用としては重大な欠点があるので、 事実上UTF-8固定でよいと思う。

最後のものは、世の中に存在するレガシーエンコーディングがシフトJISしかないのであれば、 シフトJISの上位互換と言うのはある程度は価値があるのかもしれない。 このエントリの著者の周辺ではそうなのだろう。 だけど、たとえば私の日本語データのほぼすべてはEUC-JPだし、 世の中そんなに単純じゃない。

まあ、それは良いとして、提案する解決策と言うのが「南堂私案」なるものなのだそうだ。 あいにく「南堂私案」についての生きたリンクがなかったので、 どのようにシフトJISを拡張してくれるのかよくわからないのだけれど、

だから、シフトJIS:X 0213 でも文字数が不足するということはない。（普通の用途では。）

ということだから、おそらくはシフトJIS:X0213にいくばくかの文字を追加することを許したものなのだろう。シフトJISだとあんまり空間に余裕はないような気がするけど、 まさかGB18030みたいに最大４バイトとかじゃないよね。 それはそれで大問題を引き起こしそうだし。

で、彼(南堂さん？)が見落としているのは、 元のITproの記事も含めて「文字が足りない」って話をしている時には、 彼が思っているように「日本語の範囲内で文字が足りない」というわけじゃなくて 「カジュアルに多言語の表現がしたい」というものだろうということだ。 要するに日本語の文章の中でも ハングルやベトナム文字、あるいはアクサンとかのついた文字を表現したいってことではないんだろうか。具体的には最近の「ふぇみにん日記」とかのイメージだよね。

私には「南堂私案」なるものがそういうのに対応しているようには思えないんだけど。 これで「Unicodeを使えばというのは素人の勘違い」とか 「南堂私案であらゆる問題が解決」とか断言できちゃうのは、いかがなものだろうか。

私はUnicode絶対主義者ではないし、選択肢は用意されるべきだとは思っているが (だからRubyの多言語化は選択肢を用意する設計になっている)、 とはいえ、理由もないのに事態を複雑化するのにも賛成はできない。

しがらみが無い状態では、文字コードに関する 現時点で一番ましな選択肢はUnicode(UTF-8)であるというのは 事実といってもいいんじゃないだろうか。

で、Unicodeでカバーできないなにかがあれば、 それはそれ、その状況にもっとも適切なエンコーディングを選べばよい。 新しいエンコーディングを作る必要があることはめったにないが、 もし本当にそれが必要であれば、それをじゃますることはしたくない。 必要だったらUTFCP/UTF-JPだろうが、南堂私案だろうが サポートできる枠組みは提供したい。

でも、それらは本当に必要なの？

_ The Third Bit >> Blog Archive >> Beautiful Code

というわけで、「Beautiful Code」というエッセイ集が出ます。 以前に依頼されたもの。

「英語できないから」と断ったんだけど、 先方が訳者まで用意してくれたので、引き受けることにした。 私のぶんのタイトルは「Code That's Like an Essay」ということになっている。

内情をばらせば、実はこれは今度出る「（るびま）出張版 正しいRubyコードの書き方講座」のコラムとほぼ同内容。 手抜きと言われてもしかたがない。

私のはあんまり良くなくても、他の人のはすごいですから。 そっちはお薦めです。

なお、印税は全額アムネスティに寄付されることになっている。

_ [Ruby] アジアの技術者にRuby実習，経産省の委託事業で：ITpro

うち(NaCl)の講習会教材を英訳して外国人むけ講習会を開いたという話。 最近、プレスでNaClの名前をよく見るようになったな。

_ なぜ彼らは空を飛び海を渡り膝を突き合わせてプログラムを書くのか：ITpro

コードフェストの話。

実際、顔と顔を合わせてハックするといろいろ進むよね。 こないだの合宿のときに実感した。

たまにはやりたい。

とはいえ、私にとっては結構体力を消費するので、 毎日はできないな、という感じ。 若い人はオッケーなんだろうか。

_ [知財] 「おふくろさん」改変問題に見るＪＡＳＲＡＣの危機感｜エンタメ｜カルチャー｜Sankei WEB

財産権しか管理していないJASRACが著作者人格権にまで口出しするのは 筋違いにしか思えないのだが。また、あれが改変であることは認めるにしても、 それを許せないというのもいかがなものかと思う。

フェアユースの概念が無い国では正当化は難しいだろうけど。

_ 移動

夜の米子便で東京に移動。

羽田空港→天王州アイル→新木場→舞浜。 舞浜からモノレールでヒルトン東京ベイへ。

はなはだしく場違いな気がする。

ホテルで次の日の講演(英語)の原稿の準備。朝の４時まで。 わずか３０分のためにこれだけ準備して、 なお、「ちゃんとした」気になれないと言うのはどうだろう。

日本語なら苦もないことなのに。

_ 取材

東京にいるからと取材を受ける。今週も取材ウィークが続くのか。

ビジネスとRubyのようなテーマで。 主にRubyアソシエーション理事長としての「帽子」を期待されてのインタビュー。 十分に期待に応えられただろうか。

_ [言語] 動的型の言語でも以下のようなプログラムの問題を検出できます - koguroの日記

先日の動的言語で検出できないエラーの例でも Gauche用のglintならちゃんと検出できる、という話。

プログラムに内在的に含まれている情報を十分解析できれば 動的言語でも相当の問題を自動的に検出できるはずである。

解析時間の関係から、おそらくは静的言語の型チェックのように コンパイラに組み込みとはいかないかもしれないが、 それでもいろいろできることはあるはずだ。

Rubyでも自動検出をやってる人がいたような気がするんだけど。

_ [Ruby] RubyにLazySweepのパッチを作った - I am Cruby!

RubyのGCのためにLazySweepパッチを作った、という話。

LazySweepとはマーク・アンド・スイープ法でGCをする場合、 マークフェーズはプログラム本体を止めないと行うことができないが(ここではインクリメンタルGCは無視)、 スイープフェーズは並列に行えることに着目し、 スイープフェーズを行わずにGCを終了してしまうことで、 GCによる停止時間を削減しようというもの。

実際にはスイープのためのコストは個別のオブジェクト割り当てに分散されるので 停止時間は改善されるが、スループットは変化しない(or 若干低下する)。

いつかやりたいことだと思っていたので、 実際に取り掛かってくださったことにはauthorNariさんにすなおに感謝したい。

しかし、あちこちで話を聞くと プロセスサイズ問題とcopy-on-write問題の方が 停止時間よりも深刻なケースが多いようなので、 優先順位としては

• ヒープサイズ縮小
• copy-on-write friendly

の方が高いようだ。その上で、(そう遠くない将来)このLazySweepも取り込みたいものだ。

ところで、GCの性能評価のためにはベンチマークは必須である。 どこかに良いGCベンチマークはないものか。 GCの挙動はオブジェクトの割り当てパターンに大きく依存するので いろいろなパターンのものを取り混ぜたものが望ましい。

<URL:http://lloydforge.org/projects/ruby/>のものを もらってくるかなあ。

_ [言語] PragDave: The 'Language' in Domain-Specific Language Doesn't Mean English (or French, or Japanese, or ...)

Pragmatic Dave Thomasによる「DSLってのは英語っぽいプログラムのことではありません」宣言。

一般的にはともかく、 最近のRuby界では「Rubyの文法を「悪用」して、英語っぽく書くのがDSL」 という流れがあるので、それに釘を刺すというところか。

まあ、

2.weeks.ago

くらいならともかく、

add.a.diary.entry.for("Lunch").for(August.10.at(3.pm))

はやりすぎだろう。

_ [言語] Arc: I/O

ArcのI/O関数群。

基本的にSchemeのに似てる気がする。 まあ、Arc自身がMzScheme上に実装されているので当然といえば当然だが、 これらのportを使った抽象化は、学ぶ価値があると思う。 RubyでもStringIOを使って似たようなことはできるけど、 こっちの方がもっと洗練されている。