この話題、すっかり乗り遅れてしまった。

2009-03-22 - 未来のいつか/hyoshiokの日記
プログラミング入門書では、デバッグについて、ほとんど議論されていないし、仮にふれられていても、おざなりな方法というか、かなり邪険にあつかわれていたりする。プログラマの多くの時間がデバッグについやされていたとしてもだ。

あえていわせていただく。コードはデバッグできるだけはるかにましなのだ、と。printfを使うかどうかなんぞ、その問題と比べれば屁ですらないのだと。

デバッグよりもはるかに重要なもの、それはデータ構造の選定。

ここで一歩間違えると、バグが仕様化し、デバッグどころかバグにあわせてプログラムを書かねばならぬ羽目になる。

その最も顕著な例が、Unicodeだろう。最初の設計を間違えたおかげで、最新のソフトウェアまで仕様という名のバグに引きずられる羽目になった。 Java の char はちっとも char じゃないし、JavaScript　までそれに引きずられているというのはご存知のとおり。普及にこれだけ時間がかかったのも、仕様がバグっていたからだろう。そして今日もなお、Unicodeは新たなバグを生み続け、プログラマーたちは倦み続けている。

それでは、 Unicode は何を間違えたのか。

ひとえに、ひとえに、ひとえに拡張性である。「二つで充分ですよ」ならぬ「ニバイトで充分ですよ」が、すべての間違いのもとだったのだ。もはや歴史となったY2K問題も、これから歴史になるかも知れない2038年問題も、実は同根だったりする。バイナリー、すなわち固定長のフォーマットは、よほどのことがないかぎりいつか行き詰まり、そしてその日が来るのはほぼ間違いなくあなたが思っているよりも早い。

逆に成功したものと言えば、「テキストによる表現」であろう。それは電脳的には冗長で、計算コストが高い時代にはまさに「富豪プログラミング」だった。しかし、テキストの持つ無限の拡張性は、それを補ってあまりあるものだった。今ではバイナリデータさえ、テキストに「シリアライズ」されて交換するのが日常となっている。

最も成功したバイナリーフォーマットである IPv4 でさえ、拡張性の限界に達したことを思えば、「テキストでデータを表現する」ことの偉大さがわかる。

実は Unicode 、というより UTF-16というのはこの点でもクソである。一番クソだったのは折角のテキストをバイナリーにしてしまうこと。UTF-8の登場は本当に福音だった。あれは単に Unicode を符号化するという点だけではなく、32ビット(正確には31ビット;0x00000000 - 0x7fffffff)のデータを「テキスト化」する一般的な手法としても優れている。

「データ構造をどうするか」というのは、デバッグ以上に教則が確立されていない世界であり、今日のことだけではなく明日のことまで考慮に入れねばならないという点において、何にも増して難易度が高い。コンピューター言語ですら、「コードをどうデータとして表現するか」という点においてこのカテゴリーに入るのだし。

しかし、少なくとも一つは「あとで後悔しない」知恵がある。

迷ったら、テキストにしておけ。

バイナリーがいいと確信してても、テキストにしておけ。

どうしてもバイナリーが欲しかったら、テキスト化する方法も一緒に作っておけ。

Dan the Victim