2011/11/15

歳を取ると時間が速く過ぎるのは、新しいことに挑戦しないから?

「子供の頃、1年があんなに長く感じられていたのは、全てが新鮮な体験だったから。 大人になって1年が飛ぶように過ぎてゆくのは、繰り返しで新しい情報が少ないから。」 というようなことは良く言われる。 そこから、「常に新しいことを体験していれば、時間は速く経たない」という主張がある。

私も昔はそう思っていたんだけど、最近はその説に疑問を抱いている。正確には、 「繰り返しの日常で新鮮な体験が少なければ、年月の過ぎるのが速い」というのは正しいが、 年月が過ぎるのが速く感じる要因が他にもいくつかあって、それぞれ無視できない影響力があるので、 「常に新しいことを体験していれば、時間は速く経たない」とは言えない、と思っている。

実際、この歳になると、時間の経つ速さは恐ろしい程だ。 今年がもう残り1ヶ月半なんて信じられないし、 子供が産まれてから今まで一瞬だったような気がするし、 アメリカで暮らし始めた時のことは昨日のように思い出せる。

けれども、じゃあその一瞬のうちに何もしていなかったかというとそんなわけはなくて、 一つのトピックのことだけを考えると、逆に一ヶ月前、一年前が遠くに感じられるのだ。 ピアノレッスンをとり始めたのはほんの半年前だけど、 もっとずっと昔に思える。 アメリカで芝居を再開してから今までのことを考えても長い時間を感じる---初めてオーディションに受かった時の思い出は、 アメリカに引っ越してきてがらんとしたアパートメントに寝袋で寝ていた思い出よりも前の記憶のようだ。 Gaucheの開発だって、もう10年になるけれど、ずいぶん遠くへきたもんだ、と思う。

長く感じる時間軸の共通点は、ずっと続けていて、変化し続けていることだ。 おそらくその連続する記憶が、変化を目盛とした物差しの役割を果たすことで、 そのトピックに関する出来事を適切な遠近法で配置できるからなのだろう。

一方、現在と連続しない出来事や、繰り返しの中に位置づけられる出来事は、 適切な距離感を持てない。すると、特定の出来事を思い出せば、いわゆる「望遠鏡効果」 によってその出来事がひどく近くに感じられ、 間の時間が瞬く間に過ぎ去ったような錯覚を覚えるのだろう。

月日の経つのは夢のうち、と感じる時は、その間に自分が為した膨大なものごとについて忘れてるわけだ。

子供時代は、自分の身体の成長だとか、学校という存在が、かなり強固な物差しの役割を 果たすため、人生のイベントを一次元の目盛に並べやすいのだろう。 大人は自分の生活を細分化してたくさんのことを並行して進めるから、 物差しがひとつで無くなるわけだ。それぞれの物差しの中で充実した時間を 過ごすことはできるけれど、ふと物差しを手放した時に、月日が一瞬で過ぎ去ってしまったように感じることだけは、いかんともしがたい。

もっとも、この物差し理論では、毎日見てる自分の子供の成長が一瞬に感じられる説明はつかないなあ。 これはどっちかというと、子供の成長が速すぎてこちらの感覚がついていかない、ってことかもしれん。

★ ★ ★

茂木健一郎（@kenichiromogi）さんの「新しいことに挑戦すると、それだけ濃密な時間を過ごすことができる というtogetterを見て、書こうと思ってたネタを思い出したんで、書いてみた。

もちろん、主観的な時の経過の説明はこれだけではなく、様々な要因が混じり合っている。 そのものずばり、『なぜ年をとると時間の経つのが速くなるのか』という本があって、 色々な要因が紹介されている。もっともこの本、「あれもある、これもある」って 感じでひたすら要因が列挙されてるだけで、スパッとした答えが出るわけじゃないので あまり強い印象は残らなかったんだけど、読み返してみたら上で書いたようなことは ちゃんと検討されてた。

Tag: 生活

2011/11/14

釣りくさいけど

https://twitter.com/YANA1945/status/136027550081220608

今日の面接。「もし給料が支払われなかったらどうする？」私が必ず訊く質問だ。目をキラキラさせて「構いません！」と叫ぶ人は合格。少しでも戸惑う奴。そんな奴とはプライベートでも口を聞きたくない！さっさと立ち去れ！

「払う意志が無いんですか?」かなあ。「もし私が求められる成果を出せなかったらどうしますか?」でもいいや。

給料を払うのは雇用者の契約上の義務なので、被雇用者があれこれ考えるべきことではない。契約前交渉の場で「私がこの契約を破ったらどうします?」って聞いてるようなもん。まあ聞いてもいいけど、普通は契約を守る意志のある者同士が契約に臨むんだから、契約を破る前提の話って矛盾してるよね。「やる気あるの?」って思われる質問だわな。

やる気を見たいなら、「あなたの満足する給料は出せないかもしれないけれど、どうする?」と聞けばいいんじゃないかな。これは、それでも約束しますか、という話だから。約束した後に破ったらどうする、って話とは全然違う。

あるいは、会社の口座がすっからかんになってもついてきて欲しいというなら、会社のシェアを分けて共同経営にすればいい。

(追記2011/11/15 00:11:12 UTC): なんと、この人は「面接代行業」なのか！「面接代行」が依頼主雇用者の「代理」ではなく、「仲介」なのだとしたら、この質問は矛盾してないぞ。つまり、「仲介業の俺が言うのもなんだが、あんたが契約しようとしてる企業は約束を反故にするかもしれん、それでもいいのか?」と聞いてるわけだ。それにyesと答えた人間だけを仲介するというのはあまり褒められる話ではないが、整合性はある。

Tag: Career

2011/11/13

言語の比較

「関数型言語はなぜ流行らないのか」ってネタがまた流行ってるようで、 それについては特にコメントは無いのだけれど、 「関数型言語のメリットが(オブジェクト指向言語に比べて)わからない」って 言っているエントリがあって、その思考ステップが、 ちょっと引っかかりやすい落とし穴かもしれないと思った。

機能単位で「できること」を比べても意味がない

あなたが良く知っている言語をαとしよう。そして、比較したい言語をωとする。 一部の信者はωを最強言語だと奉っているようだ。良く知らないで批評するのは アンフェアなので、あなたもωを使ってみて、ひととおり書けるようになった。 それでもなお、信者の主張するωの利点というのがピンと来ない。なぜなら、

1. 「ωで出来るすごいこと」は「αでもできる」か、「αでも頑張ればできる」
2. 「αで簡単にできること」が「ωでは簡単でないように見える」

1から、ωの採用にはメリットが無く、2からωの採用にはデメリットがあることが言える。 従ってωを使う意味はない。

理屈は通っているように見えるけど、実際の言語の進化史と比べてみると、 妙な齟齬がある。というのは、より良い後発の言語が、先行する言語に出来たことを わざと「出来なくしている」ケースがよくあるのだ。

手続き型言語ではほとんどの場合、手続きの入り口は一つだけ、戻り値も 一つのものが多い。アセンブリ言語では入り口がいくつもあったり、 複数の戻り値を持つ手続きを書けるし、それは便利に使えてた。 似たようなことを例えばCでやろうとすると不格好でオーバヘッドも大きくなる。

構造化プログラミングはgotoを排除すべしと言った。gotoで簡単に出来たことが、 純粋な構造化プログラミングではひどく不格好になる。

純粋関数型言語では状態の変更を禁じているため、状態変化を表現しようとすると モナドだの何だのと面倒くさい手段を取らないとならない。

なぜ、後発のパラダイムが「出来ること」を少なくしようとするのだろう。 少なくとも歴史の前半について、多くのプログラマは答えを何となく知っているだろう。 とすれば、その理由を外挿して考えられないか。出来ないことは、 別の見方をすればメリットなのかもしれない。単に「より良い方法」があるだけかもしれない。(e.g. gotoは、クロージャとTCOがある言語なら、関数呼び出しでより安全に、効率を落とさず実現できる。)

そして1については、結局チューリング完全な言語同士なら 「頑張れば」の程度問題になってしまうのだ。 少しだけ冗長になるけどαでも書ける。ライブラリを使えば簡単に書ける。 プリプロセッサを使えば、IDEを使えば… 等々。

もちろん高級言語で10万行のプログラムをアセンブリ言語で書こうと言い出せば、 「そりゃ頑張ればできるかもしれんけど、頑張る意味あるの?」ってことになるから、 どっかに閾値はあるはずだ。その閾値は何で決まるんだろう。

不満を比べてみたらどうか

私はLispがベストだと思っているけれど、その「ベスト」には特定のニュアンスがある。 私が言うのは、"Lisp is the language that sucks least." ということだ。 どんな言語にも使ってて「クソだこの仕様」と思うことはある。 Lispにだって山ほどある。そこらじゅうクソだらけでいつも文句たらたら使っている。 けれども他と比べた時、最も「クソの度合い」が少ないのが、私にとってはLispなのだ。

地上に出ている輝く山の高さを比べたら、どの言語もどんぐりの背比べなんである。 得意分野によって山の場所が違うだけだ。 けれど、山以外の場所の沼の深さを比べてみたらどうだろうか。

沼が無い言語なんて存在しない。100年後はどうなっているかわからないけれど、 今ある言語なんてどれもぐちゃぐちゃの沼だらけ、良く知られた山を離れたとたん ずぶずぶと足がめり込む湿地帯が広がっている。

これは多分に主観だ。だから、あなたが今使っている言語で全く不満を感じていないなら、 多分それがあなたにとってベストな言語なんだろう。どんな素晴らしい言語を持ってきても、 あなたを説得することは不可能だ。だってωに出来ることは (1)αでもちょっとだけ頑張れば できるか (2)αでうんと頑張ればできるけど、そもそもそんなに頑張ってやる必要性を感じない、 わけだし (後者のポイントで必要性を感じていたなら、あなたはαに既に不満を持っているはずだ)。 一方で、αで簡単にできたのにωでは出来なくなっている機能がきっとある。

だから、「αよりωが良い」と言えるのは、 「αに感じている具体的な不満がωでは解消されていて、それが「出来なくなったこと」を補って余りある」と感じられた時だ。

あなたが言語に感じる不満は、「あなたがプログラミングで実現したい世界」と 「その言語で容易に表現できる世界」とのギャップだ。不満を感じていないということは、 言語がものすごくパワフルでどんな世界も容易に表現できてしまうってことかもしれないけれど、 あるいは「あなたが、その言語で容易に表現できる世界しか見ていない」ということかもしれない。

それに、二つの世界の間に多少ギャップがあっても、慣れるにつれ沼の位置がわかってきて 無意識のうちに避けて通るようになる。その沼をうんと遠回りして迂回することが 当然に思えて、もしそこに橋がかかっていたらどれだけ楽になるかってことに なかなか気づけない。

現在の業界を見渡して、「今業界で扱ってる問題については、言語αで十分だよ」と 言うことはできるだろうけれど、「業界は、言語αで十分対応できるような問題しか扱っていない」 とも言える。だって扱い切れないような問題は、コストが見合わないからね。

もちろん、言語αで十分な解くべき問題というのはたくさんあるから、 それを解くことにも大いに意義がある。今、言語αでは沼が深すぎて届かないような 問題というのは、ごく特殊な領域の前線だけの話かもしれない。けれども、今の前線基地は、 10年後か20年後には立派な高速道路が通る大きな街になるかもしれない。

だから、言語ωのメリットを考えるには、今の主流のパラダイムでは 限界を越えてしまうような問題を考えてみる、ってのも一つの方法だ。

次の世代が手にする道具

沼の回避方法を熟知したベテランプログラマなら、ちょいと野心を出せば、 うまく湿地帯を回避しながら前線まで進むことはできるだろう。 これまでもプログラミングは「そういうもの」であったわけだし。

けれど、今まさにコンピュータにさわり始めた若い世代は、多分沼だらけの 湿地帯を泥にまみれて進むのはまっぴらだと思うだろう。 少しでもより整備されて、前線に速く到達できる道具があれば、そっちを選ぶだろう。

より良い言語を使いたいという欲求は、不満の大きさに比例するはずだ。

どこに不満を感じるかは、何を対象としているかで違ってくるだろうから、 そこで「自分の推す言語」はそれぞれ違ってくると思う。 けれど、今使っている言語にさほど不満を感じてないなら、 言語の優劣を議論することは多分できないんじゃないかな。

昔は皆アセンブリ言語で書いていたけれど、今全てアセンブリ言語で書けと言われたら 不満だらけでやってられないだろう。もっと書きやすい方法を知っているし、 扱う問題も規模もはるかに大きくなっている。 ならば、将来の世代は、言語αで書けと言われたら「やってられないよ」と言うだろうと 考えるのが自然だ。もちろん、その時彼らはωも不満だらけで使ってないかもしれない。 けれども、将来彼らが使うかもしれない言語Xから 逆算してみることで、 今ある言語のメリットを比較することもできるだろう。

Tags: Programmin, Lisp

2011/11/13

shiro.dreamhost.com停止

Practical Scheme は、独自ドメインを取るまでは http://shiro.dreamhost.com/scheme というURLで、ドメインを取ってからも旧URLからredirectするようにしてたんだけど、dreamhostがサブドメインをユーザに開放するのをやめるという通知が来たので、shiro.dreamhost.comを停止した。

検索すると旧URLを参照しているところもまだあるみたいなんで、ここ見てたら s@shiro.dreamhost.com/scheme@practical-scheme.net@g してもらえるとありがたいです。実際、Practical Schemeの中も検索したらぽろぽろ出てきたんでさっき大急ぎで直したところ。

実はこの際なので、サーバ自体も完全にLinodeに引っ越した。dreamhostのdedicated serverはメモリ4G載ってたので、価格比としては悪く無かったんだけど、どうもネットワークインフラでのトラブルがここ数年多かったんでもういいや。既に仕事のサーバはLinodeに移してて、dreamhostの方はガラ空きでもったいなかったのだ。今はLinodeの1Gで運用している。

(「もう潮時かなあ」なんて書いてたのが1年以上前か！ 我ながら腰の重さにあきれるな。)

(追記2011/11/14 04:42:25 UTC): ぎゃー、WiLiKi内にも大量に参照が残ってるー。やっぱり URLは永続的であるべきだなあ。プロバイダに依存する部分が入ってるURLは、そのプロバイダと命運をともにしてしまうので、安全ではない。独自ドメインを取ってずーっと自分で管理し続けるしかないかなあ。

だがそれも、更新忘れたり、ドメイン管理してる主体が消滅したりした場合には永続性が保てない。そう考えると、むしろ全てのドキュメントにUUIDをつけて、検索で発見する方がいいのかもしれない。どのドキュメントがどのUUIDだったかを人が覚えておくのは無理だから、普段の検索時に「ある時点でこのurlはこのuuidだった」っていうのを記録しといて、そのurlを見に行ったら無かった場合に自動的にurl->uuidのディレクトリに問い合わせしてuuidで検索かけるとか。uuidの生成はコンテンツ作成者任せになるから完璧ではないが、現状ではurlよりも永続性はあるような気がする。(まあDOIとかは永続的なIDを付与できるけど、積極的に登録に行かないとならないのはハードルだなあ)。

Tag: Hosting

2011/11/12

医療保険つづき

昨日の混合診療と皆保険は疑問点を絞るだけだったので、もうちょい調べてみた。

結局、こういういろんな当事者の利害が相反する話っていうのは、当事者が頭付き合わせてせてその「間」に落としどころを決めてくしかない。で、それをする現場はどうやら厚生労働相の諮問機関である中央社会保険医療協議会であるようだ。

ここの当事者は、現在は

• 医療を受けて医療費を支払う立場7人 (支払側代表)
• 医療サービスを提供し報酬を受け取る立場7人 (診療側代表)
• 公益の代表として6人

という具合らしい。それぞれの利害だけど、単純に考えてみる。

• 支払側：保険料、医療費の自己負担分は少なく。保険診療の範囲は大きく。
• 診療側：診療報酬は高く。診療の範囲は(混合診療禁止のもとでは)多い方がいい。
• 公益側：国庫補助は少なく。保険診療範囲は安全性の確認された範囲で。

って感じかと思う。公益については微妙だけど、財政が逼迫してる状況での政府の利害を代表する立場はここに入るしかないんじゃないか。 診療側の診療の範囲については、混合診療禁止縛りがある前提では、なるべく保険適用になってもらった方が良いので範囲を広げて欲しい。ただ、縛りが無くなれば、そこの要求は緩くなる。

で、おおまかには Σ診療報酬 = Σ保険料 + Σ自己負担 + Σ国庫補助 が成り立つ。

公益側の戦略として国庫補助を下げるのが重要なら、(1)保険料を上げる、(2)自己負担分を上げる、(3)診療報酬を下げる、(4)保険診療範囲を減らす、というオプションがある。1,2は支払側とぶつかり、3は診療側とぶつかり、4は両方とぶつかる。しかし混合診療解禁にすれば、4でぶつかるのが支払い側だけになり、多少はやりやすくなる、とういことか。なるほど。

Tag: 生活