メッセージ。 - diary

先日、テレビのNHKスペシャルで、2004年のイラク戦争のときアメリカ兵が起こした捕虜虐待事件の番組を見た。アブグレイブ刑務所で、アメリカ兵がイラク兵捕虜を裸にしたり犬をけしかけたりと虐待した件で、その写真が公になったというものだ。

個人的にはこの番組をみるまで、「イラク戦争ではアメリカ兵のストレスが大変大きく、そういったストレスが虐待として顕在した事件なのだろう」という風に捉えていた。つまり、この事件の真の問題はアメリカ兵に加えられた強いストレスであり、強いストレスがかかると今回のような事件はおうおうにして起こるのだろうと。

当時マスメディアの論調などははっきり覚えていないけど、上記の印象からそう外れることのない材料しか提供していなかったと思うし、その後も詳しい情報などはとくに報道されていないように思う（とくにテレビなどの大衆向けメディアにおいて）。

ところが今回の番組では、上記の印象を覆すような情報が提供されていて驚いた。番組では事件の加害者とされる女性や上官らに直接インタビューをし、現場にいた人間から事件がどう見えていたのかをレポートしていたのだ。インタビューによると、加害者の女性は虐待を「与えられた任務」だと捉えていたというのだ。

そういった感覚は、その女性だけが持っていたものではない。虐待に加わった人間たちは、多かれ少なかれ上層部の意図を汲み取って虐待を行っていたという。当時の上層部は、イラク人の捕虜を肉体的にも精神的にも追い詰めることで、情報を引き出そうとしていたという。そしてそういった方針のもと、本来の業務外の仕事（捕虜の監視）を加害兵士たちに与え、また虐待の様子を実際に確認してもいたとのこと。

しかし事件が明るみにでると、そういった方針は公にされなかった。単に加害兵士たちは「腐ったリンゴ」として扱われた。つまり、「虐待は軍による命令ではなく、兵士たち個人の意思により行われたものである」という態度が取られたのだ。実際、この事件で処罰されたのは写真に写っていたかシャッターを切ったとされる7人だけであるという。要はトカゲのしっぽきりだ。

インタビューの中では、加害兵士たちがまったくの潔白であるとは表現していない。彼らのうちの1人（男性）は、すすんで虐待を行う人格的な問題をかかえていたようだし、またインタビューを受けた女性は、その男性の恋人であったため、虐待を行う彼に加担するような行動をとっていたと表現されている。

ぼくは、この番組で報道されていたことが事実かどうか分からない。ただ、事実だとしたら大きな問題であるように思う。また、そういった切り口で報道している今回の番組のことを、とても素晴らしいものだと思う。

NHKスペシャル｜微笑と虐待　～証言　アブグレイブ刑務所事件～

ちょっとOCamlを勉強中。そもそもは、Haskellを使って大量データの統計を取るプログラムを書いていたのだけど、それがうまく動かなかったのだった。うまく動かない原因について、Haskell（GHC）のプロファイラを使って調べてみたのだけど、どうやら大量のデータをプログラムにロードする部分が重いらしい。具体的に言うと、CSVファイルを開いてそこに書かれている数字をreadするのだが、それ（read）が遅い。

もととなるCSVファイルは5MB（100万件）程度。プログラムを実行しているのは、ノートPC上のWindows XP上のcoLinux環境（メモリは192MB割り当てている）。5MBのデータで平均をとったり量子化して分類したりしたいのだけど、スワップを起こして20分以上待っても実行が終了しそうにない。Gaucheで同じプログラムを書き下して実行すると、2分30秒程度で終わるような処理内容なのに。

ちなみに、Haskell（GHC）でのプログラムのチューニングは、次のページの情報が非常に参考になった。
Chapter 25. Profiling and optimization

また、Haskellで性能劣化の原因となる「遅延評価によるスペースリーク」について、次のページの情報が導入として役に立った。
第9回　Haskellはなぜ遅いと思われているのか：ITpro

それでまぁ、現時点では、「Haskellは大量データを一括処理するのには向いていないのだろうなぁ」と結論づけた。だって、readという言語の中身がボトルネックなのだから改善しようがない（言語の中身をいじるほど力がいまのぼくにはない）。で、HaskellにかわるものとしてOCamlを勉強してみることにした。実際のところ、やろうとしている仕事に対してGaucheでも不足はないのだけど、静的型付き言語を魅力的に感じてしまったのだ。

ただ勉強しはじめてみると、OCamlもこれはこれで違和感があるなぁ。たとえば、ファイルの内容をいっぺんに読み込む関数が標準で用意されていないみたい。Gaucheでいうと、file->stringとかcall-with-input-fileとかがない。あとは、GHCみたいにライブラリの依存関係を自動で解決してくれないみたい。GHCだと、「ghc --make test.hs」などとやることで、ライブラリの依存関係を自動で解決してくれる。ちょっとしたことなんだけど、やる気にブレーキがかかるんだよなぁ。んー愚痴。

定額給付金はあまり良い案じゃないと思うけど、「やっぱりやめる」って方向は難しそうだから、まぁやってみればいいと思う。で、まぁそれはそれとして、もし次回の刺激策があるのだとしたらこんなんどう？っていうアイデアをば。ただの思い付きだけど。

「現状は大半の企業で給与の支払いが銀行振込となっているが、これを一定の期間現金支給にした企業に減税を施す」ってな感じで。要するに、市民にお金を使ってもらいたいのだったら、「銀行に入ってるお金を引き出す」という一手間を省いてあげて、現金を直接市民の手に渡せばいい。

基本的に人間はものぐさだから、きっと彼らは現状よりもお金を使うようになる。そんだけ。

パナソニックとサンヨーが合併するらしい。テレビで、企業の合併が進んでいるということを報じていた。パナソニックもサンヨーもメーカーだけど、メーカーにかかわらず、このところ企業の合併が進んでいるらしい。たとえば、家電量販店とかスーパーとか。で、ドラッグストアなんかはまだ群雄割拠の時代で、マツキヨでさえ市場シェアが1割ぐらい、これから合併が進むだろうと言われてるんだって。合併しようとしている人たちは、こんなことを言っていた。「合併することで、価格競争力が出てくる」と。

で、これはきっと要するに、カルテルってことなんだよなぁ。つまりドラッグストアで考えると分かりやすいけど、狭い地域にいくつものドラッグストアがあると、価格競争せざるを得なくなる。マツキヨとハックドラッグとどっちが安いか、みたいな。そういう競争を続けるのは、各ドラッグストアにとって痛い。できれば価格は下げたくないから、競争なんかしたくない。

ドラッグストア同士で連携して（つまり談合して）価格を高く維持できれば、利益率をある程度確保できる。でもこれはカルテルで違法だからダメ。で、どうするかという答えが、要するに「合併」なんだろうなと思った。談合して「同じ会社」であれば、各店で価格が同じでも問題がない。そりゃ、小売店にとってはお得だわな。

今日のパナソニックとサンヨーの合併報道では、家電量販店の人が「家電量販店の合併はメーカーの合併に影響しているのか？」と尋かれて、こんなことを言っていた。「合併が進んでくれば、小売店にとってもメーカーにとっても、今のような低い利益率という状態を改善できるだろうとは考えている」と。

小売店やメーカーにとどまらず、銀行なんかに至るまで、最近はいろんな企業の合併が進んでいる。これは要するにカルテルの存在を許しているというか、手綱を緩めているという状態なわけで、社会主義的な傾向を強めているんじゃないかと思う。かなり純粋な民主主義ならば、このようなカルテルは許さないのではないか。

ぼくはカルテルが悪いとは言わない。カルテルという存在も、社会においては0か1かではなくて、つねに「0と1の間」にあると思うからだ。カルテル度ゼロの社会は存在しないし、カルテル度1の社会も存在しない（ソビエトなんかはカルテル度1だったのかもしれないけど、腐敗が進んだのか崩壊してしまった）。状況によっては、カルテル度を上げ下げすることは、社会や政治にとって必要なことなのではないかと思う。

そして、現在の日本でこのようにカルテル度が上がっていく（カルテル度の上昇を許す）状況というのは、市場において企業というプレーヤーが疲弊し、競争を続けるだけの体力を失なっていることを裏付けているのかもしれない。あるいは「国際競争」というものが存在感を強め、国家間の代理戦争の様相を呈しているのかもしれない。つまり、国内のパイを争って疲弊するのではなく、国間の競争に立ち向かわなければならないという状況にあるのではないか、と。まぁでも前者の情勢がメインかな。

ええと、なんだ。単にテレビを見ていて思ったこと、でした。

昼になんか思い付いたんだよなぁ。なんだっけかなぁと考えていて、いまさっき思い出した。

HaskellってSQLに似てる。というか、関数型言語がSQLに似てるのかもしれない。というのも、たとえばSQLのSELECT文では、WHERE区で条件を指定して入力の集合を小さい集合に切り出し、その結果をまたSELECT文に渡すという感じでプログラムを組んでいくからだ。

要するに、SELECT文が返してきた「値の集合」は、必ず使用される。使用する主体は、別のSELECT文かもしれないし、ユーザーかもしれないけど、どっちにせよ使用される。一方で、普通の手続き型言語では、式を計算（評価）した結果は、必ずしも「使用」されない。感覚的には、使用する場合が6割で使用しない場合が4割ぐらいかなぁ。

たとえば代入文があるとする。「i = 4」とか。このとき、「i = 4」を実行した結果は、使用されず捨てられる。つまり、i = 4が成功したか成功していないか、「この式がもし値を返すとしたら何が返されるべきか」といったことは、誰も気に留めない。for文やwhile文、if文やcase文なんかも同様に、文を計算した結果は使用されず捨てられる。え？ それの何が問題かって？ そうさなぁ。

1つ言えることがある。「関数型言語のプログラマは、基本的に計算した式の結果（値）を捨てない」ということだ。捨てないで、できるだけ利用しようとする。括弧を重ねて式の結果に対する処理をどんどん膨らませていけば、自然にプログラムはできあがるからだ。そのようなスタイルを採ると、代入文はいらなくなる。for文やwhile文もいらない。それらは再帰で書けるし、再帰で書くほうが良いコードになる場合も多い。なぜ良いコードになるかというと、そのようなスタイルでコードを書くと、「集合に対する操作を書き下している」という感覚になるからだ。

「集合に対する操作」スタイルでプログラムを書くと、後で処理対象の値（値の型やクラス）を変更したくなった場合に、ロジック構造の変更を最小限にとどめることができる。ロジック構造は同じにしておいて、型だけ変更すればよいからだ。逆に、for文を使ったり、if文の中でelse節を省略したりしてしまうと、プログラムのロジック構造が本質から外れて、ad hoc（場当たり的）になってしまう。要するに本質的には必要のない「if文ばっかりのコード」になってしまうのだ。

if文がたくさんあると、条件漏れによるバグの温床になるし、シンプルさによるパワーが損なわれてしまう。現代では、天動説と地動説のどちらが優れているかと問われれば、ほとんどの人が地動説と答えるだろう。なぜ地動説が天動説より優れているかといえば、地動説のほうがシンプルなルール（法則）で説明しているからだ。天動説が正しいことを説明しようとすると、とてもたくさんのルール（法則）が必要になる。地動説のほうが、より少ないルール（法則）でより広い範囲のことを説明できる。つまり、地動説のほうがシンプルさによるパワーがあるということだ。

--

Haskellの嫌なところ。文字列を行ごとに分割・結合するlines・unlines関数が嫌い。たとえば、「lines "test"」も「lines "test\n"」も、どちらも"test"が返ってくる。違うものを入力して同じ結果が返ってくるというのは、美しくない。集合の写像が一意でなくなったら、可逆な変換が行えなくなってしまう（あとで元通りに戻そうと思ったときにできなくなる）。その結果、プログラミングの力は著しく削がれてしまう。

Schemeで文字列を行ごとに分割しようと思ったら、(string-split "test\n" "\n")を実行することで、"test"と""の2つの文字列が返ってくる。(string-split "test" "\n")の実行結果は"test"だけだ。このようになっていることで、Schemeで文字列を分割したり解析したりするときは、完全に問題集合に集中できる。Haskellのlinesでこれをしようとすると、どうしても「もしも○○だったら」と考えなければならなくなってしまう。

もちろん、プログラミングをしているときに、「"test"も"test\n"もどちらの入力でも"test"を返してほしい」というような関数を使いたい場合はよくある。ただそれは、ユーザーからの入力を受け取る部分だけだ。プログラムの内部においては、集合の写像が一意で可逆に決定される関数（Schemeにおけるstring-splitのようなもの）を使わなければならない。そういう部分こそ、プログラミングのパワーを分ける分水嶺となる。

Haskellにlinesがあることが悪いとは言わないけど、写像を一意に行分割・結合できる関数も用意しておいてくれたらなぁと思う。要は、大が小を兼ねるように（兼ねることがあるように）、写像が一意（可逆）であることは、写像が非可逆であることを兼ねるのだ。

ちなみに、Schemeでlines相当のことをやろうとしたとき、それ専用の関数が用意されていないので、おいらは次のようなコードを書くことにしている。(port->list read-line (current-input-port))。逆に、プログラム内部で文字列を行分割したい場合は、(string-split str "\n")としている。