メッセージ。 - diary

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

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")としている。

最近、拙いながらもだんだん、Haskellでコードが書けるようになってきた。いまは、習作としてWikiエンジンを作ってみている。それで、コードを書きながら思ったこと。

Haskellはモジュール化がやりやすくていいなぁ。Haskellでは、ある機能ブロックを作ったとき、それを別ファイルに保存してモジュールにするのが簡単にできる。「module CGI where」、「import CGI」みたいに2行ほど書くだけだ。単純な話でいうと、これはタイピング量が少なくてうれしい。タイピング量が少ないだけでも、モジュールを作るときの心理的負担が小さい。

それに加えて、Haskellではコンパイラが型チェックをしてくれるので、モジュール内に定義した関数インタフェースを簡単に変更できるのがうれしい。プログラミングをしていると、関数が授受する引数の型を変更したいということが頻繁にある。文字列で渡していた値を数値で渡したいとか、引数の数を変更したいとか、返り値の型を変更したいとか。

Schemeでそういった変更を行おうとすると、プログラマが目を皿にして（意識をかなり集中して）コード中のすべての部分をチェックし、不整合が起こらないようにしなければならない。これは案外しんどいのだ。とくに、ある機能ブロックをモジュール化して使うような場合、別のファイルがそのモジュールに依存していないかに気を配ったり、古い記憶を呼び覚ましてモジュールを書き換えなければならなかったりするので、モジュール間のインタフェース調整はしんどい。

そういう理由で、ぼくがSchemeのコードを書くときには、「とにかく長いコードは悪である」という考えに染まってしまっている面がある。コードが長いと、インタフェースを変更したいときにチェックが大変だし、モジュール分割するにしても、モジュールの内容をすべて把握しなければいけないような感覚になってしまうからだ。必然的に、たくさんの機能を持ったソフトウェアを作る気が起きにくくなっている。

Haskellではそのへんを機械的に解決できるので、気が楽な気がする。コーディングしている最中も、関数の仕様を簡単に変更できるし（いいかえれば、抽象化レイヤについて試行錯誤が容易になる）、いったんモジュールを作ってしまえば、細かいことは忘れて目の前にあるファイルに専念できる。要はハックしやすい。のではないかという気がする。まぁ、まだHaskellを勉強しはじめたところなので、いいところばっかり目につくのかもしれないけど。

Schemeでプログラムを書くときも、ユニットテストを書きさえすれば、もっと気軽に関数インタフェースを変更できるになるのだろう。そういう意味では、Schemeにおけるユニットテストは、Haskellの型チェッカに相当するのかもしれない。でも、ユニットテストを書くのはめんどくさいんだよなぁ。タイピング量が多いし、テスト書くのに頭使わなきゃいけないし、別ファイルにテスト書かなきゃいけないし。Schemeでも、型宣言ができるようになって、型チェッカが使えるようになったら、もっと便利になるかなぁ。

コメントとして書き始めたのだけど、ここに置くことにしますた。

「中出しハッピー！」は本当に「いい話」か？ | blog.yuco.net
<http://blog.yuco.net/2008/10/nakadashi_happy/>

さてさて、本エントリなんですが、ぼくは「いい話」とまでは言えないけど、男のほうはそんなに悪い人間でもないように思いました。というのは、別に「子供ができなければ結婚しない」と考えてたとは限らないから。じゃあなぜ、子供ができる以前に結婚しなかったのか？ 推測にすぎないですけど、単に結婚するだけでは、問題は解決しなかったからじゃないでしょうか。

ぼくは女じゃないから、女の人の気持ちは本当には分からないけど。でも、自分が子供ができにくい体質だったら、すごく結婚を躊躇するんじゃないかと思います。目の前にいる「今目の前にいる好きな人」を捨てて、子供ができなくてもいいって言う人を探してとにかく結婚することが、幸せだと考えられるでしょうか。

ぼくが女だったら、そうはできないんじゃないかな、と考えます（軽々しく推測してはいけないことだと思いますが）。ぼくが女だったら、今目の前にいる好きな人を、きっと捨てられない。ずるずる関係を続けていたら結婚できなくなるかもしれないけど、でもできるならその人の子供が欲しいし、自分のことはむしろどうなってもいい。自分の体が悪いんだから、と考えてしまうんじゃないでしょうか。

たとえそうだとしても、「そんなの関係ない」と言って男が結婚を申し込むことは、たしかにできるでしょう。ただ、結婚したからといって、問題が解決するわけではないですよね。女の人は自分に負い目があるって引き摺るだろうし、「子供のいない人生」をお互い引き受けなきゃいけない。2人にとって、きっとそういった呪縛を跳ね返すなにかが必要だったんだと思います。

人にもよるけど、男にとっての「ハッピー」は、単に自分が気持ち良くなることや、自分に都合のよい状況を続けることではないです。問題を解決して、目の前にいる人たちを幸せにしたいと望む男がいます。もちろん、すべての男がそうだというわけではありません。そういうことを望む女もいるでしょう。そういうことを望むオカマの人もいるでしょう。

ただぼくが言いたいのは、件のエントリーが「いい話」であるかどうか分からないのと同じように、それが「いい話ではない」かどうかどうかも分からないということです。まぁ、たくさんのことを推測しただけなので、真実は全然違うのかもしれません。ただぼくは、あのエントリを読んでそういう風に感じました。

 子供って欲しくても案外授からない。30代になると女性は「高齢出産」が目前。30代未婚の男女が多くなってる今、「結婚しても子供ができないかも」というカップルは多いと思う。できるかどうかというのは重い問題。

現代は価値観が多様化して、「幸せの形」もいろいろあると思う。「こうでなければならない」というものは1つもなく、「これが幸せで、これは幸せではない」と区別することはできない。ぼくはそう思っている。

ただ、1つの価値観としては、子供を産み、育てるということが1つの幸せの形として存在することを、ぼくは否定するつもりがない。それを望む人たちがいることを、それなりに自然なことだと思っている。

過去の小説やドラマに目を向けたときにも、「子供を産み育てることが男や女や夫婦の喜びである」という価値観に染められている作品をいくつか見てきた。そういった人生を送ることができなかった老齢の夫婦において、夫や妻が、伴侶に対し申し訳なく感じているという場面も見た。

子供のいない人生、ともに過ごしバトンを渡す相手を持たない人生というのが、「不幸である」とはぼくは言わない。それとは違う人生が不幸であるとも言わない。ただそれは、そう軽く扱われるべきものではないんじゃないかと、ぼくは思う。

人間の気持ちや、なにが幸福であるかは、そう簡単には分からない。それらはそれぞれに重いものだ。とてもとても重いものだ。

Haskellを勉強中。いやぁ、Haskell面白いなぁ。

たとえば、普通のプログラミング言語は最内簡約なんだけど、Haskellはグラフ簡約なところ（外側から簡約していくところ）が面白い。普通の（最内簡約の）プログラミング言語では、プログラムを内側（書かれたもののうち内側の小さい単位）から実行するという方式で、たとえば((1 + 2) * 3)は有無を言わさず(1+2)、1+2は3、(3*3)の順番で実行する。一方でHaskellのようなグラフ簡約の言語は、((1 + 2) * 3)という式を受け取ると、まず外側の()を実行する。つまり、括弧の内側を実行する必要があるかどうかを外側から順に計算していく。

これは要するに、Haskellではif文を関数で実装できるということだ。(if (= num 0) then 0 else (5 / num))みたいな式を書こうとしたとき、普通のプログラミング言語では、ifは「構文」であって「関数」ではない。もし普通のプログラミング言語でifが関数だとしたら、(= num 0) と0と(5 / num)の3つをまず計算し、それから(= num 0)がTrueかFalseかを判断して、それからその結果に応じて0とか「(5 / num)の結果」のどちらかを返す。

でもこれは、実際には動かない。(5 / num)を計算しようとしたとき、numが0だったら計算できないからだ（ある数を0で割ることはできない）。

--

ただHaskellはドキュメンテーションが弱いような気がするなぁ。Gaucheみたいにinfo形式のリファレンスマニュアルが欲しい。HTMLのマニュアルはあるみたいだけど、HTMLだとレスポンスが悪いし、Emacsとかから閲覧しにくいように思う。Gaucheはリファレンスマニュアルが素晴らしくて、コーディングしながらまったくストレスなくマニュアルを使える。

--

http://tabesugi.net/memo/2008/aa.html#042053

 Ventura「…世間じゃ民主党は共和党に反対するもんだと思われてるが、俺はそんなものは信じない。ちょうど、プロレスみたいなもんだと思ってる。大衆の前じゃ、どっちもお互いを敵視してるかのようにふるまっているが、楽屋じゃ仲良しクラブさ。どっちのサイドも実は『同じサイド』で、企業に奉仕してるんだ。利害は一致してる。ただそうじゃないように信じこませているだけだ。俺はいまの政治家がやっていることはそれだと思うね。…」 

ああ、そうなんだよなぁ。最近忘れてたけど。この人は賢いなぁ。

でもこういうのって、アジア的な考え方だよな。ぼくはここしばらく、「饅頭怖い」の話についてずっと考えてる。日本ではとくに、自分が好きなものややりたいことを口にすることが憚れる。それどころか逆のことを言ったり、思ってることを明かさないことが良いことだとされている。本音と建前というか。

一方で、たとえばアメリカでは、基本的に望むことを口にするのが良いことだとされているように思う。明示された言語によって議論するし、利害の反する（かもしれない）者どうしで自らの希望することをあっけらかんと口にする。

アメリカの若者は自分の思想信条にあった言葉が入ったTシャツを着たりするし、オバマを支持するとかFree Tibetと軒先に看板を付けたりとかする。でも日本の若者が着ているTシャツに書かれている言葉は、単なる模様であって主張では決してない。明示的な表現と本人の意思とは、ほとんどのケースで乖離している。

日本では、それぞれが望むこと、あるべき姿について、ほとんど口にしないし議論しない。これが理由かどうかは知らないが、本来やるべきことがどうもウヤムヤになっていて、大事なことが埋没されてしまっているように思う。「饅頭怖い」。ただこの価値観は、自然社会ではたぶん合理的なんだよな。んー。まとまらない。

--

まーいいや。適当。

Googleが試験公開しているフリーの日本語OCRソフトが、はてブでホットエントリーに入っててすごい人気。でも、そんなにみんなが期待するほど、OCRって使い物になるんだろうか？ 自分、大学では文字認識の研究をやってたんすけど。OCR技術は、郵便番号の認識みたいな「枠の中に数字のコードが必ず書いてある」みたいな状況ではすごく役に立つけど、汎用的なものにしようとすると、途端に価値が下がるように思う。

たとえば、文字が縦書きか横書きか、フォントサイズは一定か不変か、書いてある内容は自然文かそれとも電話番号のようなコードか、誤認識はうまくフォローできるのか（どれくらい誤認識が許されるのか）等によって価値が全然違ってくるだろう。

そして、OCRがビジネスや日常の道具として損益分岐点の上に行くようなスイートスポットは、残念ながらとても小さい。文字認識の研究をやられていた先生も、懇親会の席でこんなことをおっしゃっていた。「文字認識の市場規模は残念ながら小さい。似た技術を使っているのに、バーコードのほうがビジネスとして断然上を行っている」。10年以上前の話だが、状況はそう変わっていないだろう。

バーコードは、誤りの検出と訂正機能を備え、意味論の集合を事前に定義したうえで個々の意味を二次元の印刷物やディスプレイにコード化（読み書きが可逆的に可能な状態に）することで、有用性を確保できている。一方で文字認識は、文字認識技術それだけでは意味論の抽出が不可能なので、認識結果を機械に処理させたり、意味を抽出したりするためには、人間が密にサポートするか、事前の強いコード化が欠かせない。

フリーのOCRソフトやライブラリは、あればあったに越したことはないだろうけど。でも、それが「役に立つ」といえるレベルに持っていくのは難しいだろうなぁと思う。やるとすれば、コードの意味論をかなり限定的に定められる分野か、たくさんのデータを処理できるようなスケールメリットのある分野に適用するといった使い方だろう。ぱっと思い付くところでは、学力テストをマーク式から手書きにできるとか、本をスキャンしてその内容をテキストデータで提供できるとかそういう使い方。

そういう意味では、使い道はあるにはあるんだけど。ただ、そういう場合は大きな案件で使うことになるし、大きな案件ならばアカデミックな研究成果の盛り込まれた商用のOCRライブラリを使うという選択肢もある。普通の人がこんなにたくさんはてブにメモするほど身近なライブラリには、（少なくともあと3～5年ぐらいは）ならないんじゃないかと思う。