Boost.Localeがクソすぎる

Boost.Localeがレビューされているので見てみたが、クソすぎる。しかも、作者はそれが糞であることに気がついていない。

Boost.Locale: Boost.Locale

Boost.Localeはstd::localeの機能を持っている。しかし、日本人なら誰でも知るように、std::localeはクソの役にも立たない。よって、Boost.Localeも、その機能としては役立たずだ。

Boost.Locale: CollationとBoost.Locale: Conversionsでは、大文字、小文字、アクセント記号の有無に対する無視や、相互変換などの機能を提供している。これは、日本語には何の役にも立たない機能である。

Boost.Locale: Numbers, Time and Currency formatting and parsing

これは、数値や日付、貨幣単位に対する変換である。たとえば、123456789という数値を、それぞれのロケールに合わせて、123,456,789（3桁区切り）にしたり、あるいは1,2345,6789（4桁区切り）にしたりできる。また、時刻を、これまたそれぞれのロケールに合わせて、文字列で返すことができる。また、通貨単位も付加できる。

これは、ポルポが食べていたクラッカーの歯クソほどの事もない機能である。あるひとつのロケールに置いてすら、数値や日付のフォーマットは様々あり、単にひとつのフォーマットに置き換えるなど、何の役にも立たない、ましてや、Jan 1st 2011とか、1月 1日 2011になったところで、何の役にも立たない。そもそも、日本語はどうするのだ。バックスラッシュ（日本語フォントでは半角￥）を使うのか？　￥（U+FFE5: FULLWIDTH YEN SIGN）を使うのか？

まあ、これは何の役にも立たないから無視してよい。次。

Boost.Locale: Messages Formatting (Translation)

これは、翻訳である。unixのgettextをモデルにしている。これは最悪である。原理としては、各国語のマッピングを持っておき（"hello"と"こんにちは"）、それを使うのだ。これは、英語から日本語への翻訳には、ある程度有効だが、日本語から英語への翻訳には絶望的に適していない。実は、私は昔、あるgettextを用いたあるソフトウェアの翻訳をしたことがある。まさか、その知識がここで生きるとは思わなかった。

std::cout << translate("hello") << std::endl ;

translateが引数として受け付けるのは、char const *かstd::stringである。wchar_ｔは受け付けない。この理由を作者に問いただしたところ、信じられないような答えが返ってきた。

「あらゆる言語は英語を基調とすべきであり、それプログラマーたる者は、すべからく英語を使うべし。まず英語で書き、つぎに各国語に翻訳するのだ。これこそがunixのgettextの思想であり、また本ライブラリーの目的でもある」

これほど現実を無視した馬鹿げたことはない。入力にcharを使うということは、NULL終端されたあらゆるバイナリ列が渡されるということだ。

たとえば、MSVCにおいて、translate("あ")とtranslate("궇")は同じバイナリ列である。前者はシフトJISを使い、後者は、おそらくKS X 1001という韓国語の文字コードを使うはずである。

作者はどういうわけか、ソースファイルをBOM付きUTF-8にすれば、MSVCはencoding prefixなしの文字列にUTF-8を使うと信じている。とんでもない誤りである。MSVCは、現在知られているあらゆる文字コードに対応し、encoding prefixなしの文字列に対しては、自動的に対応するMBCSの文字コードに変換をしてくれるのだ。作者が何故このような誤った事を信じているかというと、おそらく、UTF-8はASCII互換だからなのだろう。このことは、何度説明しようとも、作者は盲信を改めようとはしなかった。典型的だ。

また、このライブラリーはcharの入力としてASCIIのみを期待しているので、別の文字コードを渡すのはプログラマーが悪いとのことである。現実を全く見ていない。そもそも、charのエンコードはASCIIだと保証されているわけでもないのに。

作者は、wchar_tはコンパイラーによって実装がまちまちであり、ポータブルなコードでは使うべきではないという。それを言えば、charだってエンコードはまちまちであり、使うべきではないのだ。なぜC++0xでは、UTF-8用のchar8_tのような型を用意しなかったのか。

普通、日本人がこのライブラリーの噂を聞けば、これは対応する翻訳文へのマッピングを行ってくれるライブラリーであり、当然、日本語から英語へのマッピングをサポートしているだろうと期待するだろう。しかし、実際にドキュメントを読んでみると、「英語以外の言語は二級市民である。日本語は二級市民である。お前は英語を使わなければならない。このライブラリーは英語から各国語へのマッピングをするのであって、お前の言語から多言語へのマッピングはしない」とあれば、さて、どうなることやら。

日本人プログラマーはほぼ全員、英語が使えない。書けない話せないだけではなく、読むことすらできないのだ。日本人にとって、「プログラミングには英語を使うべし」というのは、クリンゴン語やエルフ語やヒュムノス語を使えというのと同義である。（おそらく、日本人プログラマーは全員オタクであると想定して差し支えないだろうから、このうちでもっとも可能性のあるのはヒュムノス語である）

さらに、作者は、Unicodeでは、ワイド文字列を使わなければならないというのは都市伝説（Myth）であり、実際にはそのようなことはない、UTF-16は最適なエンコード方式ではないなどと、意味不明のドキュメントまで書いている始末。

Boost.Locale: Recommendations and Myths

我々はワイド文字列を使う。我々はUTF-16を使う。確かに、UTF-16は最適のエンコード方式ではないが、UTF-8だって最適ではない。これを単に都市伝説として扱うというのは憤懣やるかたない。

さらに、pluralへの対応は汚すぎる。pluralとは、英語で例を上げれば、I have 1 file. I have 2 files. というように、単数と複数に応じて名詞にsがつくものをいうのだ。pluralはソフトウェアで対応すべきではないのだ。あのマイクロソフトが、その気になれば数千人の翻訳作業用の人員を簡単に雇えるほどの資金力を持つマイクロソフトが、Windowsではpluralを正しく扱っていない（I have 2 file(s).）ことを考えれば、そもそも自然言語の方を合わせるべきである。

ゆえに、このライブラリーはrejectすべきである。もし採用するのならば、ドキュメントで明確に、日本語とMSVCとWindowsのサポートを否定すべきである。

数日前、このような内容のメールをBoostのMLに投げつけたのだが、作者は一向に問題意識を持たない。このライブラリーがどうなるにせよ、我々日本人には関係のないことだ。