2011/08/25
点と点とナード
ちょっと新鮮だった。
chibicode - 点と点がつながると信じてたバカへ。元アップルのインターンが、ジョブズ引退の日に思ったこと。
ジョブスの「将来、点と点がつながることを信じよ」のスピーチに感化されて、つなげるための点を置くためにいろいろ手を出したけれど、そんなに無理することなかったんだ、どう置こうがつながる点はつながるんだし、というような話が出てくる。そこでほほうと思った。
ジョブスの本意がどうかはわからないけれど、私はあのスピーチをナードに向けたメッセージと読んでいた。つまり、世間的な常識や評価、あるいは自分の将来の得失とかを考えると、どうもこういうことをやってて良いのか不安になるんだけれど、でもどうしても今これをやらずにはおれないんだ、という人に対して、「今それをやっておくことは将来必ず何かにつながるから、心配せずに好きなだけ入れ込みなさい」と言っているのかと。
だから、つなげるための点を置こうとする、という発想自体が新鮮に感じたわけ。
別にそれが悪いことってわけじゃなくて、ただ違うなあと。
Paul Grahamのエッセイなんかも、私感ではかなりナード向けに特化したメッセージが多いと思う。感想を見ていると、その対象にspot onした人とそうでない人で反応が違うなあと思うこともあるけれど、どちらが正解というわけでもない。それに、大事なのは言葉そのものではなく、それを聞いた人がどういう行動を起こすかってことだしね。
★ ★ ★
(追記2011/08/27 00:48:13 UTC): 以前書いた、関連するようなしないような話。
あくまで個人的な印象だけど、Paul Grahamのメッセージは実は非常に限られた種類の人間をターゲットにしてて、そこにメッセージを届けるためならそれ以外の人々に誤解されても構わないと割り切ってるふしがある。だから、彼の書いたものを読んでそれは自分向けではない、あるいはみんながみんなそう考えたら困るじゃないか、と思ったとしても、それは正しい。もともと万人に向けて書かれているわけじゃないから。 (ただ、ある人が対象でないということは、その人が「ふるい落とされている」ということにはならない。単に対象でないっていうだけ。)
そうやってブロードキャストしたメッセージが埋没している潜在的なハッカーに届いて、そのハッカーの背中を押すことができれば、社会が結果的に(ハッカー以外の人にとっても)より良い場所になると彼は思ってるのでは。
たぶんあの頃の年代は、上の世代からハッパをかけられると、それが正しくても何か素直に従いたくないものがあるんだと思う。自分でやりたいから、先回りされてやることを言われるのが面白くないのだ。背中を押されるよりも、それで良い、という確認の方が素直に受け取れるんだろう。 (「あまり苦労をかけさせるなよ」と笑いながら、「やりたいならおやんなさい」と言ってくれた劇部の顧問の先生を思い出す。)
Tags: Career, PaulGraham
2011/08/24
ピアノレッスン11回目
バンクーバーから帰ってすぐに予想外に忙しくなってしまったので、 あまりちゃんとさらう時間が無かった。 それなりに継続してやってきた貯金が効いてる感じではあるが。
- スケール、アルペジオ MM=138 (アルペジオが追いついた)。 時々左右がばらけるのに注意。
- モーツァルトのイ短調ソナタK310全楽章通し。集中して弾けた。 時々左手が必要以上に大きくなるのと、早い箇所のトリルに改善の余地あり。あとはOK。
K310の2,3楽章はずっとやりたかったけど独力ではモチベーションが保てなくて 挫折してたんで、レッスンをきっかけに弾けてよかった。
次はラヴェルのソナチネに取りかかるが、来週までだとほとんど進まないだろうなあ。 うんと昔に譜読みはしてるから何となく覚えてはいるんだけど。
Tag: Piano
2011/08/18
Vancouver + Harrison Hot Springs
今年のSIGGRAPHはVancouver。せっかくなので家族で行って、 会議の後は車を借りてちょっとだけ内陸の方を旅してきた。 Vancouverは15年ぶりだけど、 綺麗な街だなあと思った印象はそのままだった。前回は4月で、山には雪が かなり残っててスキーも出来たんだけど、今回はさすがに遠くに霞んで見える 山肌の谷間に少し白いものが見えるくらい。
- 陽が昇る日中は結構暑いけれど、朝は結構寒い。曇ってると日中も寒い。 (ハワイ基準の「寒い」とは気温20度以下。) でもこのくらいなら、夏の間は暮らし良いかも。冬のことは考えたくないが。 在住の知人は雨ばっかりと言っていたなあ。
- SIGGRAPHで一番面白かったのは "Metropolis Procedural Modeling"。 Grammar basedなprocedural modelingを望む形に導くように制御するって 話はこれまで色々あったけど、どれも個別のテクニック (「スケッチ」に合わせて「木」を生やす」とか) だった。このペーパーでは、 確率的文脈自由文法で生成できるモデルなら何であれ制御できる。 問題を綺麗に抽象化してるのがカッコいい。 この人は他にもいろいろおもしろい研究をしてるなあ。 http://graphics.stanford.edu/~jtalton/research.php
- Vancouver近辺では、Capilano Suspension Bridge、水族館、Science Worldに行った。 らむ太は日本科学未来館では丸1日いて飽きないのでScience Worldが良いんじゃないかと 思ったんだけど、期待してたほどじゃなかったなあ。改装中で展示が縮小されてたせいもあるけれど、 パズル系の展示物などはまだらむ太には早すぎた感じ。結局KidSpaceで時間を費やしたが ああいうのならハワイにもあるしなあ。水族館とCapilanoのつり橋は良かった。
- SIGGRAPH後は、Vancouverから車で2時間程Fraser Riverを遡って Harrison LakeのほとりにあるHarrison Hot Springsへ。 名前のとおり温泉が出てるんだけど、 プールにするのはまあ文化の違いとして許せるが消毒の塩素がものすごくきつくて閉口した。 でも子供には受けが良くて結局ずーっとプールで遊びっぱなし。 周辺の山をハイクできるかと期待してたけど、これももうちょい大きくなってからかもなあ。ドライブしてても、普段見ない景色に興味を持つのは最初の10分で、後は早くホテルに戻って遊びたいとか言い出すし。
- 最終日。Vancouver国際空港から米国内へ飛ぶ時は入国審査を出発前にやっちゃうってのを すっかり忘れてて、入国審査の列でずいぶん待たされたおかげで空港内を走るハメに。 空港内は綺麗で子供が遊べるスペースも見えたんで、もっと余裕持って行けばよかった。
らむ太にとっては日本・ホノルル以外で初めての大きな旅行だったけど、 まだ違いを楽しむっていうふうではないなあ。 自分のいる環境についてある程度の知識と理解が無ければ、 違う環境に行っても何が違うかわからないわけで。 そうなるにはまだ3年くらいかかるかもなあ。
(追記2011/08/21 07:29:08 UTC): 大事な事を書き忘れてた。Vancouverはメシが旨い。 そこらへんの普通の店に入っても旨い。 USでは旨い店を選ばない限り旨くはないので、この違いは圧倒的で、 USから訪れた人々は皆一様に感心していたものだった。 (なお、日本も「そこらへんの普通の店が旨い」という点では素晴らしい国である…というかUSが駄目なだけか。) マーケットで買ったブルーベリーも素晴らしかったなあ。
Tags: Conference, 旅
2011/08/03
演者のエナジー (ピアノレッスン10回目)
今日もコンサートグランドでちょっと弾かせてもらう機会があり、 ラフマニノフの前奏曲Op23-5とカプースチンの練習曲Op40-2をリベンジ。 前回よりはかなり落ち着いて弾けたけど、まだ浮わついててミスが多い。
環境の違い、特に音の違いで集中力が削がれる、というのが大きいと感じた。 pでの音の出方がだいぶ違って、カプースチンの2番は冒頭からしばらく pで速いフレーズが続くものだから、調整しようとすると曲の方がすぽんと抜ける。 ラフマニノフの方はpで初めてもすぐ盛り上がるんで調整が楽。だけど中間部の 左手のアルペジオで同じような困難が。
「上がる」ことについて先生が面白い表現をしていた。 演奏のエネルギーが弱いと、環境に影響されて上がりやすい、というのだ。 これは芝居の経験からも、なかなか的を射た表現だと思った。
核になる表現がしっかりと根付いていればいるほど、外乱に対して 動揺しないし、また環境の変化に追従する余裕も産まれる。
たぶんエネルギーにも種類があって、どこで弾いても確実に同じように弾ける強くて固い エネルギー、観客の微妙な反応とうまくインタラクトして毎回違う演奏/演技を 見せられるしなやかな強さのエネルギー、などがあるんだろう。後者を目指したい ところだが、今はとりあえず少々のことで動揺しないだけの基礎体力をつけないと だめだな。
で、そういうのを鍛えるには、strangerに聴いてもらう機会を たくさん作るしかないとのことだ。 やっぱそうだよなあ、芝居も観客がいてナンボだからなあ。 先生の知人には、家の前を通りかかった見知らぬ人を呼び込んで 聴かせてたって強者もいるらしい。
演者のエネルギーという点では、芝居のノウハウを流用できるかもしれない、 という気がしている。マイズナーテクニックを学んでから、演奏にも 似たような手法が使えるかもしれないと思ってきた。マイズナー言う所の "text is a canoe" と同じように "notes are canoe" と言えるのではないか。
あと基礎練習はスケールが138のまま、アルペジオは132まで上がった。 重三度スケールはMM=48でE♭minorまで練習してるけど、(53)-(31)で小指を 越えるところがきつい。特に5が黒鍵で次の3と1が白鍵の時。
(追記 2011/08/05 11:46:35 UTC): 考えてみれば受かる当てが薄くても継続的に オーディション受けてるのは「見られる感覚」を忘れないようにするためで、 ピアノについても同じ姿勢でいる必要があるというのは当然かもしれん。 あと、スタニスラフスキーの "Public Solitude" がピアノでの 上がり防止/集中維持にも使えるだろうか。演奏は観客に向けてaddress されねばならないとするとちょっと違うか。考えてみる。
Tag: Piano
2011/07/19
動的型のメリットは「決断の遅延」かもしれない
Togetter - 「動的型言語のふわふわ感」 読んでて思ったんだけど。
静的型付けと動的型付けで何が一番違うかって考えてくと、「実行前に済んでること」と「実行時」とをどのくらい分けるか、というところに帰着するかもしれない、と思った。
静的型付けは実行しないでも型エラーをコンパイラが見つけてくれる、というのは、つまり実行する前にプログラムが出来上がっているってことを前提にしているわけだな。程度問題ではあるけれど、実行前のどこかの時点で線を引いて、その時点で分かっている情報の整合性を型という枠組みで保証しましょ、ってわけだから。
「実行する前にプログラムが出来上がっている」なんて当然じゃないか、と思うかもしれないけれど、本当にそうだろうか。
上のtogetterで、「Rubyでは 1 + "hoge" が実行時エラーになるけれど、それは型エラーなんだから実行前に捕まえられた方がいいでしょ」という議論があった。でも、それは型エラーじゃないかもしれない。単に、そういうケースへの対応を実行前にはまだ決めていなかっただけかもしれない。
cl-user(1): (defmethod plus ((x number) (y number)) (+ x y))
#<standard-method plus (number number)>
cl-user(2): (plus 2 3)
5
cl-user(3): (plus 1 "hoge")
Error: No methods applicable for generic function
#<standard-generic-function plus> with args (1 "hoge") of
classes (fixnum string)
[condition type: program-error]
Restart actions (select using :continue):
0: Try calling it again
1: Return to Top Level (an "abort" restart).
2: Abort entirely from this (lisp) process.
[1c] cl-user(4): (defmethod plus ((x number) (y string)) (format nil "~a~a" x y))
#<standard-method plus (number string)>
[1c] cl-user(5): :continue 0
"1hoge"
(Lispに詳しくない人向けの説明: (plus 1 "hoge") というメソッドは未定義なので実行時エラーで止まったけど、そのエラープロンプトから適切なメソッドを追加して実行を再開したので、ちゃんと呼び出し元に答えが返ってくる。)
もちろんこれは極端な例だ。何でもかんでも、実行エラーが出たらその場で直せばいいじゃん、というわけにはいかない。とりわけ、プログラムの作成者とユーザが別々であることが普通になった現代では。
けれども、「プログラムは実行前に完成しているべきである」という前提を疑ってみるのは無益ではないと思う。
例えばユーザによりカスタマイズ可能なプログラム。ユーザが入手した時点でプログラムは完結しておらず、ユーザの手によって使われながら(そのユーザにとっての)完成形へと徐々に進化してゆく、とみなすこともできる。もちろん、プログラム本体とユーザによるカスタマイズ部分を完全に分けて、前者はコンパイル時にがちがちに検査をかけ、後者を実行時に解釈する、という実装は可能だ。でもその分離は本質的なものだろうか? 単に「コンパイル時と実行時の間に線を引かなければならない」という実装上の都合でそうなっているだけかもしれない。
止まること無く走りつづけて、その時その時の状況に合わせてふるまいを変えてゆく必要があるプログラム、というのもある。これも極端な例としては実行中のサーバにランタイムパッチを当てるなんていうケースがあるが、そこまでアドホックな話でないにせよ、あらかじめ変更を見越して後から開発されてくるモジュールを柔軟に読んだり削除したりするようなアーキテクチャというのは考えられる。オンラインゲームで機能を追加してゆくとか ←実際の現場ではさすがに本番系のモジュールを実行中に入れ替えなんてやってないだろうけれど、それも単に今のプログラムというのがそのような実行時の動的変化を安定して扱えないだけだから、かもしれない。ゲームで言えば、プレイしながら振る舞いを調整したいってのもあるね。これも今は振る舞い部分だけ動的スクリプトにしたりするけど、それも本質的な分離ではなく、実装上の都合かもしれない。
思考の道具として、あるいは実行可能なアイディアとしてプログラムを見ることもできる。黒板にメモして、あちこち書き換えながらアイディアを発展させてゆくように、プログラムをあちこち書き換えながらアイディアを詰めてゆく。黒板との違いは、そのプログラムは動かせるということだ。そして、動かしている最中に新しいアイディアを得て、その場で書き換えて(最初から再実行するのではなく)実行を続行したい、というケースは十分考えられる。シミュレーションのように抱える状態が大きいものであれば特にそうだろう。もちろん、ポータブルな形で状態をダンプできるようにしといて、停止→ダンプ→書き換え、再コンパイル→リストア→続行、というワークフローをとることはできる。が、それはやっぱり実装の都合だ。
これらの例をもって、だから静的型付けはだめだ、と主張するつもりはない。現代のプログラムの圧倒的多数は、実行前にプログラムが閉じて完成していることを要請されているだろうし。上に挙げた例でもいちいち注記したように、アーキテクチャを工夫することでフェーズを分離し、静的型付け言語で実装することは可能だ。もちろん、可能だからといってそうすべきであるということにはならない。
動的型付けを好むプログラマが一定数いるのは、プログラマが触っている「開発途中のプログラム」というのがまさに「完成前に実行したい」ものだから、なのかもしれない。とりわけ、「何を、どう作るべきか」がまだ見えない状態でとりあえずデータをいじりながら発想を得たい、なんて時には。
Haskellerと話しているとまず型から考えるみたいで、ある意味「こうあるべき/こうあって欲しい」というイデアから演繹的にコードを導き出してるようにも見える。勝手な思い込みだけど。一方、手元にぐにゃぐにゃした不定形のデータがあってそいつをこね回したいって時には、最初に手をつける時に構造や意味を決めすぎないようにしないと話が進まない。動的型付けは、「この操作はこういう意味を持つ」と定義する決断を先延ばしにしていると言えるかもしれない。先に構造と意味を決めてからコードを書くのではなく、動くコードを書いてからその意味を考えて構造をいじる。こう書くとエンジニアリングとしてはかなり危なっかしい感じがするけれど、一般的に「なにかをつくる過程」だと思えばそれほど不自然な話ではない。
とはいえ、Lispプログラムだって実行前にわかってることはたくさんあるんで、わかってる範囲ではコンパイラに働いて欲しいんだな。動かしてこねこねしているうちに形が定まってきたら、そこでアノテーションを入れて静的検査を強化できたらなあと思うことはよくある。
Tags: Programming, Lisp, Haskell
Comments (0)