2011/11/15

Meisner intensive 3回目の2

スケジュールが押してる機能の実装に追われてたら、早朝に別案件でトラブルが発生し、 その対応にてんてこまいのうちに夜が明け、らむ太を学校に送ってちょい仮眠をとってたら 仕事の電話で起こされ、押してた機能のパッチをぎりぎりで送って らむ太をクラスに連れて行き、帰ってからさて明日はピアノのレッスンなのに ようやく少しさらえるわいと基礎錬を始めたところで、 マイズナーのクラスがあったことを思い出した！

少し遅刻したけどScottのクラスは最初軽い雑談から入るので助かった。今日はひたすらrepetition day。

• Repetitionの復習。Mechanical repetition、truthful repetition
• Three moments。Three moments -> repetition。
• 来週は各自independent activityを持ってくること。

Repetitionが、卓球のラリーをやってるみたいな感じになってきた。よく見る、よく聞く、だけではなく、間髪を入れずに反応することに、一種の心地よさがある。集中のレベルが日常から一段上がって、物理的時間が主観的時間に比べてゆっくり流れる感じだ。

Tag: 芝居

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