メッセージ。 - diary

パナソニックとサンヨーが合併するらしい。テレビで、企業の合併が進んでいるということを報じていた。パナソニックもサンヨーもメーカーだけど、メーカーにかかわらず、このところ企業の合併が進んでいるらしい。たとえば、家電量販店とかスーパーとか。で、ドラッグストアなんかはまだ群雄割拠の時代で、マツキヨでさえ市場シェアが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")としている。

最近、拙いながらもだんだん、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シャツに書かれている言葉は、単なる模様であって主張では決してない。明示的な表現と本人の意思とは、ほとんどのケースで乖離している。

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

--

まーいいや。適当。