OPAMを導入することでOCamlの２つの問題であるうちの一つ、標準ライブラリが弱いという点を補うことができる。ちなみにもう一つの問題点は入門書が売ってない程度にマイナーなこと。言語仕様の問題点はこの際些細なことだ。少なくとも私がPythonでやってることの多くは実現できそう。ただしLinuxなどUnix系に限る。例えば画像ファイルを扱うCamlImagesはCのライブラリのlibjpegやlibpngなどを利用している。Zipファイルを扱うCamlZipはzlibを利用している。これはパフォーマンス的にCと遜色ないプログラムを書けるという意味にもなるが、これらのライブラリをWindowsに持ってくるのはかなり難易度が高い（CamlZipは可能なようだが、CamlImagesが可能なのかどうか私には判らない）。PythonやScalaの利点である、同じプログラムがLinuxとWindowsで動くといったことはOCamlにはない。
LinuxではOCaml、WindowsではF#を使う。あるいはScalaで書く。諦めてPythonで書く。ってあたりが現在の気持ち。
OPAMでライブラリの強化が可能なのはいいとして、どのOCamlライブラリも開発者それぞれの技量や哲学が反映されてか、非常に個性的だ。統一性なんてものは一切ない。CamlZipはZipエントリー内容をファイルまたはバイト列（文字列）で得ることができる。しかしCamlImagesはファイルしか読めない。Zipファイルに入ってる画像は一旦実ファイルにしないと扱えない。CamlImagesにはメモリ上に展開されたバイト列を読むための関数は用意されてない。F#やScalaはそれぞれC#やJavaのライブラリに依存しており、統一性のあるアクセスができる。Zipエントリーからはストリームが得られ、画像のインスタンスをストリームから作ることができる。ストリームはファイルから作っても良いし、HTTPのコネクションから作っても良い。といったことがとっちらかったライブラリしかないOCamlでは全くもって望めない。もしかしたらZipでバイト列（文字列）を扱うハメになったHaskellも同じ状況なのかもしれないが詳しくは調べてない。あっ、ストリームってOOP的な考え方なのかな。そういえばC++の特徴はファイルをストリームで扱うことだった。ううむ関数型言語には合わないのだろうか。
OCamlの各種ライブラリが個性的なのはまぁ大概はいいとしても、文字エンコードの変換をするCamomileの使い方は自動生成されたAPIドキュメントでは全く解らなかった。今でも使い方は解らない。適当にサンプルを見つけてきてCP932とUTF-8の間で変換をさせているだけだ。以下のようなモジュールを書いてブラックボックス化している。
module CodecCp932 = struct module U8 = CamomileLibraryDefault.Camomile.CharEncoding.Make(CamomileLibrary.UTF8) let enc = CamomileLibraryDefault.Camomile.CharEncoding.of_name "WINDOWS-31J" let decode s = U8.decode enc s let encode s = U8.encode enc s end
いくらなんでもモジュール名が冗長すぎるだろ、これ。
OCamlをPythonなみに普及させるには地道なライブラリとドキュメントの整備がかかせないが、OPAMはその第一歩といったところか。いやきっと、誰も本当にOCamlが普及する時代が来るなんて思ってないんだろうけどさ。
OCamlの利点を書き忘れていた。OCamlはなんと、PRINTデバッグができる。HaskellはIOモナドのせいでPRINTデバッグが事実上不可能。地味だけどこれは重要。ヘタレな私にはOCamlやF#やScalaの方が性に合う。
「諦めてPythonで書く」の解説。OCamlのサイトからマニュアルをダウンロードし、CalibreでEPUB2にしたものをepub2to3_P.pyに通してみた。なんだかマシンのファンが唸る。存外時間が掛かった。同じファイルをepub2to3_O.mlをネイティブにビルドしたものに通す。アレっという間にスルっと終わる。ちゃんとファイルも出来てる。うわぁこんなに効率が違うのかぁ。Pythonってやっぱり圧倒的に遅い。手軽さとの天秤だなぁ。ちなみにこれで出来たEPUB3ファイルはepubcheckでエラー出まくる。そもそもEPUB2の時点でエラー出まくってる。
2014.11.29
OSTRACISM CO.
OSTRA / Takeshi Yoneki