メッセージ。 - diary

最近、拙いながらもだんだん、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年ぐらいは）ならないんじゃないかと思う。

「プログラミング言語」という言葉を初めて聞いたときに違和感があって、いまもその違和感のことは忘れていない。つまり、「言語ってなんですか？」と。ぼくにとっては、言語というのはあくまで自然言語のように捉えられている。うまく言えないけど、人間（知的主体）が人間（知的主体）とコミュニケーションするための手段が言語だと感じる。

逆に言うと、いま我々が使っている「プログラミング言語」というものは、単なる「オペレーションセット」（操作盤）であって「言語」ではないとぼくは考える。それはたとえば、車を運転するためのハンドルやアクセルやエアコンの操作パネルなどのような、要はスイッチ群だ。それらのスイッチを時系列・順列に、あるいは並列に組み合わせて、あくまで客体的な機械を意図するとおりに動かす。それがいまの「プログラミング言語」だと思う。

だから、100年後のプログラミング言語がどうなっているかというと、計算機が客体的なままであれば（またはチューリング機械であれば）、プログラミング言語もまた「オペレーションセット」のままその本質は変わらないだろう。

ただし、たしかまつもとゆきひろさんがおっしゃっていたように、現在でもほとんどの人々はコンピュータでプログラミングをしていない（にもかかわらず満足してコンピュータを使っている）。GoogleやYahoo!にアクセスしたりクエリを投げかけたりすることが、彼らにとっての「プログラミング」だという指摘は、納得できるものがある。

そしてまた、こうも思う。そのような「プログラミング」環境を考えたとき、はたして計算機は未だ客体的であるだろうか？と。それらの計算機（群）は常に内部データをアップデートし、また期待しない型の値を返してくる（こちらが質問を投げたら、計算機が質問を返してくるような）。

よく分からないのだけど、そういった計算機は、チューリング機械と言えるのだろうか？ 科学が反証可能性を備えていなければならないように、チューリング機械もまた反証可能性を備えていなければならないのではないかとぼくは考える。つまり、「ある入力Aを与えたとき出力Bが得られる」という実行結果に対して、別のいつかほかの誰かがが再試験したとして、必ず同じ結果が得られることが「機械」であると。

LL Futureに行った。そのときに感じたことと、その後いくつかの関連ブログ記事を読んだりして考えたことを一つ。

LL FutureでLarry Wallさんの講演を聞きながら、Perlのことを漠然と考え、少し見直した。というのも、ここ数年、ぼくはPerlのことを「全然アカデミックじゃないチョイダメ言語の1つ」だと見なしていた。分かりやすく言えば、「素人の作った言語」と言ってもいい。つまり、数学的基礎（王家の血統）をほとんど持たない蛮族の言語として。「正規表現？ それでたとえば、S式はパースできるのかい？」

でも、ぼくは歳を取ったのか、Larryさんの顔を見ていると、ぼんやりとその考えが緩んできた。Larryさんといえば、patchコマンドの開発者でもある。そしてぼくは、patchコマンドが好きだ。

patchコマンドは、テキストの差分情報をもとに、複数のテキストの更新を同期させるソフトウェア。たとえば、太郎さんと花子さんの2人が結婚の挨拶状を作っているとしよう。普通は2人で膝を付き合わせて文章を練るのが一番だが、忙しくてそうできない場合もある。2人はテキストをそれぞれ自分のパソコンにファイルとして保存し、少しずつ修正する。2つのバージョンができるわけだ。それらのバージョンのファイルを機械的に統合して、1つの完成した文章を作る機能を、patchコマンドは提供する。

普通は、1つの文章が複数のバージョンに分かれてしまうと、人間の力でそれらの差分を把握して統合するのは困難だ。単純に2つの文章を付き合わせるだけでも、2つの文章を1字ずつ追い掛けて差分を把握する必要がある。挨拶状ぐらいの短い文章ならいいが、論文や契約書のような長い文章になると途端に難しくなる。そして、差分の把握と統合といった作業は、「文章を読む」というよりは「文字や文字のつながりを見る」ことに近い。だから本来、それは機械でもできる仕事なのだ。patchコマンドは実際にそれを機械にやらせるために作られた。

ぼくがpatchコマンドを好きなのは、それが「機械にやらせるべき仕事と、人間がやるべき仕事」を明確に意識しているところにある。大量のデータを一律にチェックするとか、加工するとか、1分1秒も休むことなく何かを待ち続けるとか、機械はそういう仕事が得意だ。しかも間違わない（逆に人間はそれが苦手だ）。だから、機械にやらせるべき仕事は、機械にやらせたほうが断然良い。ただ難しいのは、どの仕事が機械にやらせるべき仕事で、またどの程度人間との連絡を取らせるべきかを判断するのが困難なことだ。そこのバランスが崩れると、「せっかく機械にやらせるようにしたのに案外メリットがなかった」という結果になる。

patchコマンドは、そういった問題を、文章の編集という誰にも身近なレベルで経験できるようにした。以前どこかで読んだのだけど、「ビジネスとは結局のところ文書を作ることだ」という考え方がある。極端な考え方で異論もあるけど、確かに「一切紙も文字も数字も介在しないビジネス」というのは存在しない。物々交換のときをすぎ、貨幣経済の中に生きるということは、文書とともに暮らすということだ。だから文章の編集に対して、機械を適用するという解決策を提案したpatchコマンドを、ぼくは面白いと思う。ただ、実際のところ、patchコマンドはいわゆる普通の人にはなかなか取っ付きにくく、「バランスの問題」というハードルは依然立ち塞がっているのだけど。

さて、Perlについて。Perlもたぶん、「機械にやらせるべき仕事と、人間がやるべき仕事」を意識して作られたんだと思うんだよね。だから、できるだけ簡単に（書かなきゃいけないプログラムが短かくなるように）、ちょっとの入力（労力と時間）で大きな出力（仕事の結果）を引き出せるように、Perlの仕様は作られたのだろう。Perlを使えば、ちょっとした文章を加工するとか、たくさんのファイルを一括処理するとかいった、カオティックで雑多で短いターンアラウンドが適した（数学的でない）問題を容易に解決できる。逆にPerlは、数学的な構造や再帰的問題や強固なビルディングブロックを要する問題を解決するのが、あまり得意ではない。

要するに右脳的というか。Larryさんは「Artistic License」というラインセンスを作って、それをPerlにも採用しているけど、いったいどうして「artistic」なんて名前を付けるんだろう？と思う。不思議な感じ。ただ、確かにPerlはArtistic（芸術家的）なんだろうな。芸術と数学は、ときに鋭い一致を見せるけど、ときにまったく反目したりもする。artというのはいったいなんなんだろうか。そういうことを考えている。