メッセージ。 - diary

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

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

だから、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というのはいったいなんなんだろうか。そういうことを考えている。

怒っている人を見る。でも、その怒りが正当なものなのか、よく分からない。先入観で判断して、分かったつもりになって、勝手に怒ってるように感じる。世の中には、「自分は分かっている」、「自分は正しい」と思っている人が多すぎる。弱い人間を見たとき、その人が弱いからといって責めてどうなる？ 弱い人間が、どうして弱いのかを理解しようとしなければ、何も変わりはしない。そうじゃないかな？ ……少なくとも、相手のことをよく分かっていない状況で、でも自分がなにかをしたくて仕方なくなったのならば、相手のことを知ることから始めるべきで、そこをすっ飛ばして怒ったって仕方がない。と思う。だからさぁ、ちょっと冷静になって、優しい言葉で尋ねてみることから始めたらどうかなぁ？

--

アメリカを旅行中、なんかいかスターバックスに入った。日本では、スターバックスは高いし、ぼくはコーヒーを飲まない人間なので、「スターバックスはあまり好きじゃないなぁ」と思っていた。でもアメリカのスターバックスは安かった。レモネードのスムージーみたいなのが150円ぐらい。安い。それに、スターバックスはけっこういろんなところにあって、暑くってまいってるときなんかに助かる。アメリカの人がスターバックスを贔屓にするのは分かる気がするなぁ。大袈裟かもしれないけど、アメリカ人からすれば、スターバックスは砂漠のオアシスみたいに感じられるのかもしれない。

--

アメリカを旅行中、マクドナルドに一度だけ入った。ビッグマックは日本とほぼ同じ大きさで、味も同じ。値段も同じぐらいでセットが650円ぐらいかなぁ。これじゃあアメリカの人はお腹いっぱいにならないと思った。あと、100円マックみたいなのもないので、余計にお腹いっぱいにならないだろうなぁ。ほかのファーストフードに比べると割高な感じ。

--

アメリカ旅行でいろいろ感じたことや、知ったことがあって、なにかメモに残したい。でも、どういう形でメモにすればいいのかなぁ。ここで日記という形で、思い出したときに書けばよいかしら。

--

そうそう。アメリカを旅行しているとき、外出中はけっこう気を遣って疲れたのだった。アメリカでは、「ストリートは危ない場所」という感じがあって、ストリートより一段安全な場所は「お店など私有の建物の中」。一番安全で、唯一気が抜けるのは、「ホテルの自分の部屋の中」という感じだった。ほかの人がどう感じているのかは分からないけど、ガイドブックを読んだり、街を歩いたりしている限りは、そういう感覚で合っているのかなぁと。で、もしそうだとしたら、スターバックスみたいなお店の価値は一層高まると思うんだな。なにしろ道ばたで休むわけにはいかないのだから、安くて休憩できるお店があるのは有り難い。

--

予定調和がつまらないなぁと思う。どうして市場には、こんなに予定調和したモノばっかりが溢れかえっているのだろうか。天然に存在するはずのリアリティをほぼ完全に消臭して、予定調和だけを形にすることに、どういう意味があるんだろう？ 個人的には、そういった予定調和モノはまったく面白く感じないのだけど、逆に市場には予定調和モノしか存在しないという現実。全然意味が分からない。市場にはリアルは存在できないということなのかなぁ？ それはまぁそのとおりというか、「市場とリアルは相反する」（消費されるものと消費されざるもの）という理屈はぼくが長年考えて辿り着いた仮説ではあるけど。でもそれにしたって、リアルの存在感が薄すぎる。リアルが遠すぎて、もうほとんど手の届かないところにあるかのように感じる。疑問なのは、ぼく以外の人は、この状況になにも感じないのだろうかということ。誰も彼もが、今ほどに予定調和を欲しがっているのだろうか。よく分からない。ぼくは間違った場所を探しているんだろうか。まぁそうなんだろうな。

ああ、もう朝晩は涼しいなぁ。風が気持ちいい。夏ってこんな風に終わっていくんだったっけ。

数日前に、渡辺京二さんの『日本近世の起源―戦国乱世から徳川の平和へ』という本を読んだ。面白かった。それで、直接はこの本と関係ないのだけど、ちょっと思ったこと。

# 『日本近世の起源―戦国乱世から徳川の平和へ』
# http://www.amazon.co.jp/exec/obidos/ASIN/4862482643/

ある時期から、日本人のコミュニケーションには「徳」というベースがあるんじゃないかなぁ。ここでいう「徳」は、Win-Winのことを指してる。

日本人にとっては、双方が満足するコミュニケーション（取引）が「良いコミュニケーション（取引）」であって、しかも「誰もがそれを目指すべきである」という価値観を持っているように思う。

たとえば上記の本の中で、豊臣や徳川といった幕府と民衆の間には、ゆるやかな契約関係のようなものがあったと述べられている。彼らの関係は、もちろん支配―被支配の構図にはなっているけれども、それは必ずしも暴力による強制的なものではなかった。

本によると、豊臣・徳川幕府が成立する直前は、悲惨な状況だったらしい。朝廷や室町幕府の力が弱まるにつれ暴力が横行し、法も秩序もなく、世間は貧困と殺人と戦争と人身売買にまみれていたとのこと。そういった状況を克服し、平和をもたらしたのが豊臣・徳川幕府だった。

暴力が支配する世界は、そもそもアナーキー（無政府状態）が原因で起こったものだった。村々はめいめい土地と水と道と山の権利を主張し、有効な調停者がいないことで実質暴力によって問題は解決された。農民たちは村ごとに武装し暴力に対抗したが、戦いにあけくれる日々は、そもそもの農業生産に疲弊をもたらした。ながいあいだ、平和は農民をはじめとする国民の願いであっただろう。

だから、平和をもたらしてくれるような幕府が成立することを国民は歓迎したし、また幕府を作ろうとした人たちも、そもそも人民に平和をもたらすことを目的に活動していた。これはつまり、孔子が言うところの徳政だ。君子には人民を統べるだけの徳が求められるし、またそのような徳のある君子に対して、人民は誇りをもって臣民となる。

現代で言えば、Win-Winの関係だ。こういった関係は、支配者―被支配者の間で「あるべき形」として考えられたし、商売における販売者―消費者の関係にといても、また個人対個人の関係においても「あるべき形」とされたのではないか。そして現代にいたるまで、そういったWin-Winの関係、もっというと「徳」の考え方が、日本人のコミュニケーション観には息衝いているのではないかと思う。

一方で過去の歴史に目を向けると、イギリスやアメリカなどと日本の外交において、彼我の間のコミュニケーションはしばしばコンフリクトを起こしている。先方の外交手法は、当方を敵と見なす形でとられ、「双方が各々自国の利益を最大化することが当然（自国以外が不利益を被ろうと知らない）」という立場だ。しかし日本は外交手法においても、「双方の利益を最大化するべき」という「徳」の立場に立った。それゆえ齟齬が起こった。

ぼくが企業システムにおける「組合」に違和感を覚えるのも、そこに「徳」という概念が抜け落ちているからだ。組合という考え方は、経営者と雇用者が絶対的に対立することを想定している。しかし、そもそも日本においては、経営者と雇用者はそれほど険悪に対立していない。もちろん、経営者によっては悪徳経営に傾く企業もあるだろうけど、基本的に経営者は徳による経営を行うことが求められている（経営者側も雇用者側も、そのような経営を望んでいる）。悪徳経営が支配するときには、雇用者は一揆を行うこともあるだろうし、社会として悪徳経営を嫌う思想性がある。組合のように、「経営者はつねに搾取を試みている」いう想定のもとのシステムは、徳に対して牙を向くもので、日本の企業風土にそぐわないと思うのだ。

Schemeにおける継続の概念が、少し前にようやく理解できた気がした。そのように感じたきっかけは、自分でScheme処理系のオモチャを作ったことにある。ただ、継続というものがプログラミング言語にとって本質的なものなのかどうかが今でも分からない。ぼくのボンヤリした頭ではなかなか本質というものが理解できないのだけど、ふと思い出したときにはそのことについて考え楽しんでいる。

それともう1つ考えていることは、「どうして以前の自分は継続について理解できなかったのだろうか」ということ。なんとなく思い当たることの1つは、Schemeの仕様書がプログラミングの静的記述方法と解釈系だけではなく、実行インスタンスであるバーチャルマシンを実装するよう書かれていることを理解できなかったからではないかという気がする（この解釈であってますかね？ ちゃんとR5RSを読んだことがないので間違ってる可能性あり）。

つまり以前のぼくは、C言語やPerlやPHPのようなバーチャルマシンなしで実行するプログラミングパラダイムの範疇内でSchemeを理解しようと試みていた。えーと、ここで「バーチャルマシン」と言っているのは、スタックマシンというか、Schemeレベルでの変数テーブルと実行スタックを意識した実装の方式という感じなのだけど。C言語やPerlやPHPでは、各々の言語レベルで変数テーブルやスタックを意識しなくてよいですよね？

それらの言語では、プログラマが記述したコードが、どのようにマシン語に落とされて実行されるかだけ意識しておけばよい。つまり、実マシンのスタックやメモリ状態だけを意識するというか。Schemeでも、継続を使わないプログラムであれば、C言語やPerlやPHPと同じように考えればよいけど、継続を使うコードとなるとどうしてもScheme処理系が自前でスタックを管理しているイメージ抜きには、動きを理解できた気になれないように思う。

で、そのへんの「自前でスタックを管理しているイメージ」ってのがさっぱり頭の中になくて、C言語とかのパラダイムでSchemeの継続を理解しようとしていたから、先へ進めなかったのかなぁ、と。どうなんでしょ。なんとなく思ったのでメモ。あ、それと途中で思ったけど、「実行インスタンスであるバーチャルマシン」という表現は、間違ってるかなぁ。「自前のスタックマシン」というぐらいの表現が近いかも。うーん、よく分からん。ぼくの知識では雲をつかむような話になってしまう。

なんかおいら、空気読めてない…(´・_・｀)…？

わーい。宇彩さん（winternoteさん）が帰ってきましたよー。昨日気付きましたー。

http://winternote.com/

書くまいと思っていたのだけど書く。個人的には、女の子に好かれたければ、笑えばいいと思うよ。

笑って自分の人生を楽しんでいる人を見れば、楽しくなるから。男に限らず、女の人でも、笑っている人は魅力的だ。

まぁ、それだけで好かれるかというと、例外もあるんだろうけどね。でも個人的には、笑うことが大事だと思う。

基本的には、次の3つのルールを守ることかなぁと思う。(1)できるだけ嘘をつかない、(2)定期的に情報を出してみる、(3)回答者の名前を明示する。

(1)の「できるだけ嘘をつかない」というのは、ちょっとでも嘘をつくと、後で情報を追加しなければいけなくなったときに嘘の上塗りをしなければいけなくなってしまうから。なにか問題があったときに「今回はこれこれこういうことがあったことにしておこう」みたいなストーリーを作って発表してしまうと、後で綻びが出たときに辻褄合わせをしなければいけなくなる。そうすると、辻褄合わせのためにまた新しい嘘が必要になる。これでは雪だるま式にリスクが増えてしまうし、全体のストーリが曖昧模糊となって信用してもらいにくくなる。嘘をつきとおすのはとても難しいので、できるだけ最初から嘘をつかないほうがよい。

# インターネットがない時代には、企業やメディアがちょっとぐらい嘘をついてもそれを指摘する声が世間に伝播しにくかった。企業やマスメディアが発信する情報の正確性や意図について、大衆が検証したり注意喚起したりすることが難しかった。でもインターネット時代になって情報の双方向流通が増え、またWebが主に活字による情報流通の場であったことによって、企業やメディアの発信する情報の正確性と意図について、大衆は以前より検証がしやすくなった。インターネット以前ならばちょっとした嘘も大きな問題にならなかったが、インターネット以降は嘘が雪だるま式に問題化するリスクが高まっていると考える。

(2)の「定期的に情報を出してみる」というのは、そうすることによって「嘘をついていない」と主張しやすくなるから。普段情報を出していない企業やメディアが、問題が起こったときになって「あのときはああだった、このときはこう対処した」と言っても、なかなか信用してもらえない。そのときの思い付きで作った作り話かもしれないから。普段は情報をセーブしておいて、問題が起こったときにドカッと発表するようなやり方は、その発表の中で辻褄を合わせやすいので、ちょっと情報リテラシのある人からは信用されない。逆に、定期的にある程度の情報を出していると、時系列をまたがって辻褄を合わせるのは難しいので、情報リテラシの高い人から「信頼に値する」と思ってもらえる（なお、一度発表した情報をバックデートしたり、都合の悪いコメントを消して「なかったこと」にするのが炎上や大問題につながりやすいのは、それが時系列を壊そうとする行為にほかならず、情報の信憑性や信頼関係を根底から覆す行為だからだ）。

(3)の「回答者の名前を明示する」というのは、そのほうが情報の守備一貫性を保てるから。責任の所在を明らかにできるからといってもいい。回答者（情報を発表する人）が明示されていれば、何回かの情報発表の中でその人が何をどのように考えているかを、受け手が理解しやすくなる。そうなれば、無用な誤解が避けられる可能性は高まるし、もし企業やメディアの中に複数の担当者がおり発表内容に齟齬があった場合でも、問題を回復しやすい。

もちろん、原則としては企業がユーザーに回答する内容には一貫性を持たせたほうがよく、担当者ごとに回答内容が違うというのは避けたほうがよい。しかし、個々の問い合わせに対して、すべての担当者がまったく同一の意思をもって回答するというのは、はっきり言って不可能だ。機械ではないのだから、すべての担当者は個別の問い合わせに対してそれぞれなりの解釈をもって回答を行ってしまうことは避けられない。またユーザーも機械ではないので、木で鼻をくくったような対応はむしろ望まれていない。

つまり、ユーザーからの問い合わせであれ、マスメディアからの取材であれ、外部との情報のやりとりはすべて人間対人間の双方向コミュニケーションであると考えるべきだ。そういった双方向のコミュニケーションを行える人材を確保するのは、企業にとって重荷であるだろうし、数をこなしにくくなるだろうし、難しい問題もあるだろう。ただ、だからといって木で鼻をくくる型のメディア・リスク対応に戻すよりは、良いのではないかと思う。「回答者の名前を明示する」ということ自体はそれほど難しくないので、ここからスタートしてみるのは1つの方法だろう。

--

基本的にはこんなところかなぁと思う。どれも当たり前のことだけど、当たり前のことをやるのが案外難しいのだな。「言わないでも分かるだろう」と思って言わないでいると、後になって伝わっていないということも多いので、こうやって当たり前のことを書いてみることにも価値があるのではないかと思う。（ただし、経験上ここに書いたことが全然当たり前じゃない可能性もあり）（なにを書いているのか分からなくなってきたぞ）
--

総じて思うのは、「都合の悪いことでも正直に話してしまえ」ということだ。人間も企業もミスをするのだから、1つ1つのミスをいつまでたっても責め続け、あげつらう人（ユーザー）はいない。ミスをしたことを認め、状況を説明し、なにが原因だったかをきちんと把握して改善に務めれば、それはユーザーの利益にもなるしサプライヤー（企業やメディア）の利益にもなる。