Shiro:log:2004前半

Shiro:log:2004前半

Shiro


(2004/06/28 20:55:52 PDT)

引越しにつき、しばしオフラインになります。

(2004/06/26 14:20:05 PDT)

ちょっと古いけど、 Eric Naggum's rant on C++。むしろすがすがしい程の毒舌ぶり。 Perl版も。

でも、C++もPerlもちゃんと使おうと思えば使えてしまうから、 邪悪性はそんなに高くない。プログラムすることが拷問に等しい、 真に邪悪な言語というものが存在する。 3DオーサリングソフトウェアMayaのスクリプト言語MELがその実例だ。

最近仕事でMayaをまた少し触る羽目になって、忘れていたMELの嫌さを再び 味わうことになった。 前の会社でもMayaを使っていたんだが、思い返せばMaya 1.0betaの頃に MELの仕様に辟易して、 Schemeを代わりに使えるプラグインを開発してそれを使っていたので 汚染されずに済んでいたんだった。

MELという言語、変数が型つきであること以外は、 REPLがあってインタラクティブに評価できるし、 一見良くあるスクリプト言語に見える。

どんな言語にも(Schemeにさえも) 嫌なところ、使っててひっかかるところ はある。MELの「嫌さ」も、最初はそういうものの集積にすぎない、 と思われるかもしれない。 それが言語そのものの質的な欠陥であり、ちょっとした構文や意味の 汚さの問題ではない、というのに気づくのには、しばらくかかる。

最近、その欠陥を表現する一文を思いついた。 MELは、「プログラマによるあらゆる抽象化の試みを拒否する」のだ。

例えば、aggregate typeが基本型(整数、浮動小数点数、文字列)の配列 しかなくて、最初はそれが問題なんじゃないかと感じる。 でも、そのこと自体は、プログラマが自力で構造を配列に エンコードすれば醜くても解決できる。例えば、文字列をデータに持つ ツリーは、整数の配列と文字列の配列をペアで持てばいい。

真の問題は、それを抽象化する手段が無いことだ。ユーザ定義関数は 型つきでなければならず、多相型とかvariantみたいな型が無いため、 「任意のデータを持つ、エンコードされたツリー」を扱う関数が 書けない。高階関数が無いことも、抽象化手段を著しく狭めている。 おかげで似たような関数を目的に合わせて何度も何度も何度も何度も 書く羽目になる。

驚くべきことに、MELはevalを持っているのだ。「万能関数」evalが あれば、大抵の抽象化トリックが実装できそうなものだ。 ところがである。恐ろしいことに、MELではevalの返り値を特定の 型の変数で受けなければならない。つまり、evalの直接のcallerが 「evalが何を返すか」を知っていなければならない。これでは、 他から式を受け取ってそれにevalを適用するような関数を書きようがない。

こういう言語は、何が言語にとって一番重要かを教えてくれる 反面教師にはなる。

(2004/06/20 02:16:41 PDT)

sasadaさんとこ経由で、 一生を棒に振る、この年収の差。ピアスと茶髪

高校生の頃にこれを読んでたらかなり反発してただろうし、大学生の頃なら 笑ってただろう。今は、まあ、そうなんじゃない、と思う。

生活してゆく上では社会的になんとなく形成されてる合意ってもんを くぐり抜けてゆかなくちゃならないわけで、それに沿わないとその社会では 不利な立場に置かれるよ、ってのが話の核心でしょうな。 (自分だったら、その後に「だから、破ってもいいけどat your own riskでね」、 と付け加えると思うけど)。ピアスとか茶髪とかいう具体的な 事象は、「現代日本の特定地域」というコンテキストでの例であって、 コンテキストが違えばそういう具体例は当てはまらないけど、 そこに反発してもこの話の根本的な意味は変わらない。 「私はそんなところで判断するような企業には行かない」という人はそもそも このコンテキストの対象外ってことで。そうだとしても、その人の向かう ところのコンテキストにはやっぱり社会的ルールがあって、それに沿うかどうかを 自分の責任で決めなくちゃならないことは変わらない。

…と、今の自分が高校の頃の自分に説明するとしたらこんなふうに 説明するだろうかね。

まあ、そもそもフリーターがどうのって議論を見て真っ先に思うのは、 日本はとっても平和で豊かな国なんだなあってことだが。

(2004/06/05 04:33:43 PDT)

Gdk+Pango on Fedora Core 1 のフォントではまりまくり。 sansのフォントを差し替えたいんだが、 fonts.conf系をいくらいじっても反映されない。

Xftはクライアント側でレンダリングするんだと思っていたが、lsofで オープンしてるファイルを見てみると、*.ttfファイル自体はクライアントでは オープンされておらず、Xfsの方でオープンしている。 クライアント側はfontconfigでマッチングをかけるだけで、

結果として得られたフォント名だけをサーバに渡してるんかな。 Xfsはfonts.confは見てないしな。

いやそんなことはないか。メトリックは読まないとlayoutできないよなあ。 なんでクライアント側でオープンしてないんだろう?

ああなるほど。クライアント側はXftFontOpenとかを使って サーバのラスタライザからフォント情報を得てるのか。

(2004/05/31 03:12:40 PDT)

北の浜で2晩キャンプして、カメと泳いで来た。

帰ったらメールが来てて、締め切りをひとつ忘れてたのに気づく。すんません…

(2004/05/21 03:04:51 PDT) キワノ

昨日かみさんとスーパーに買いものにいってうろうろしてたら、 フルーツのコーナーに、なんか鮮やかなオレンジ色でとげとげしている、 とても好奇心をそそられる果物があったんすよ。 Horned Melonと書いてある。 ちょうど黄色いコリアンメロンと同じくらいの大きさで、 トゲじゃないところは押してみるとかすかにへこむくらいの硬さ。 うちの家訓は「モノは試し」なので、試しに一個買ってみたんですわ。 で、さっきデザートにでも食うべと思って切ってみたんですわ。

うーん。何と言うか、だまされた気分でいっぱいです。

ネットで調べたら、似たような経験をした人多数の模様。

果物ってよりはキュウリの仲間だと思ってたほうが良さげ。

nakamura: 私も食べたことあるんですが(笑), メチャ食べにくくなかったですか? 食べたとき種の比率が妙に高いような気がしました...モノによっては種ごと食べれるのかな...

(2004/05/11 02:33:38 PDT) ピアノ

http://homepage3.nifty.com/mogami/diary/d0405.html#10t4

普通に弾く速さでは一打ずつ構成していると意識の速度がまにあわない。イメージはチャンクを使って構成する必要がある。…簡単に出来ても次に進まずこのようなチャンクのレパートリーを増やしておくのがいいのだろう。慣れるときっと小節くらいが一つの「単語」になるんじゃないかと思う。

これから両手に挑むわけだけど、あれって、和音としてチャンクするものなのだろうか。それともそれぞれ別に作った片手の動きを同期させる感じでやるのだろうか。

自分の場合、言葉で説明するのは難しいのだけれど、 だいたい「一気に」弾くひとかたまり---分散和音ひとつのこともあれば、 数小節から10数小節に渡るフレーズ全体のこともあるが---くらいの感覚で、 ある「構造を掴む感覚」がある。

その感覚は、例えば、イントレみたいな足場を作るのにいろんな部品を うまい具合に組み合わせて、かちっとはまったところで、個々の部品は細いのに 構造的にとても頑丈なものが出来た時に感じるものとも似ているし、

持ちにくい、変な形のものを持ち上げるために色々な場所に手をかけてみて ふと、余分な力を入れずとも楽に持ち上げられるポジションをみつけた、みたいな 感覚でもあるし、

ロッククライミングをやったことはないのだけれど、微妙な岩のでっぱりを 見つけて体重をかけても大丈夫なくらいがっちりとグリップを得た時って こんな感じがするのだろうなと想像できるような感覚でもあるし、

特に最後の、部分と全体が同時に見えている感覚が、日常生活で相当するものが ないので形容し難い。空間だけでなく時間も同時に存在していて、 あるフレーズの全てが同時にそこにある。でもそれを人に伝えるためには、 演奏という形に落とすしかなくて、そうすると時間軸方向にも解きほぐされた 形にならざるを得ない。

かように言葉にするとつかみどころがないのだが、その感覚自体は自分にとっては とても具体的で間違いようのないものだ。 記憶力も落ちてるし、練習時間もあまり取れないしで、最近はいかに効率良く 弾けるようなるかを考えているのだけれど、新しい曲をさらいはじめる時には 積極的にその感覚を求めるようにしている。

たまに、練習をしていると、普段掴んでいるそういう固まりよりずっと 大きな単位での構造物が、ちらりと見えることがある。今日もそれがあった。 「あ、この曲は、つまり、そういうことだったのか」と思う。 そこに見えた構造物に沿って指をあててゆけば理想的なものができそうな気がする。 けれど、残念ながらそういうヴィジョンは長続きせず、 指もついてこない。うまい人っていうのは、 きっとそれがあたりまえのように見えてて、 さらにそれを現実化できる体力を備えているってことなんじゃないかなとか思う。

(2004/05/11 00:11:25 PDT)

The spirit of resistance to government is so valuable on certain occasions, that I wish it always to be kept alive.

Thomas Jeffersonの言葉だそうだ。 Paul Grahamはこの言葉を引いて、ハッキングの本質とはunrulinessであり、 それが実はイノベーションの原動力であるとしている。 (シリコンバレーが米国に現れたのは、まさにそのthe right sort of unrulinessを 好む空気のためであるとも)。

法に触れちゃいかんが、 法「だけ」で技術が押さえられるものでもない。特に情報関係は。 抑圧ではなく、協調するしかないと思うんだがな。

(2004/05/08 06:04:35 PDT)

AOPについて。http://www02.so-net.ne.jp/~greentea/pre.html

Lisp (別にElispでもいいんですけど) をちょっとかじったことがあるなら、 adviceの存在は知ってますよね。AOPというのは、そのadviceに (ワイルドカー ド付きの) 型システムを持ち込んだものというのが第一印象です。

その印象は本質を突いているかと。 Gregor Kiczales氏のやってきたことに注目すれば、 CLOSのメソッドコンビネーションからAOPへはごく自然な流れに見える。

Kiczales氏とはILC2003でちょっと話した。 「AOPのポイントカット指定方法はSchemeみたいなanonymousなfirst class object中心の言語だと困りませんか」 と聞いたら、「そうだねえ、困るねえ」って、あんまり気にしてないみたい。 彼の印象は、体力系超絶技巧派。理屈の綺麗さは脇に置いといて、 その技巧を駆使して動くものをわしわしっと作ってしまう感じ。

(2004/04/30 21:59:23 PDT)

すげぇ→一輪セグウェイ。 この人は前にも(2輪の)自作セグウェイを作っている。 Paul Graham、Robert Morrisと一緒にViawebのプログラム書いてた人でもある。

(2004/04/25 01:49:35 PDT)

Lispで一番クリティカルな部分を速度で最適化する場合、 (optimize (speed 3) (safety 0)) とかにして、 型宣言をつけまくるわけだが、関数を編集して再定義したら インタラクティブに(disassemble 'foo) してどういう アセンブリコードが出てるかを調べる、というのをよくやる。 首尾良くCで書くのと同等のコードが出たらニンマリ。 もちろん(safety 0)だとミスればSEGVるところまでCと同等になるんだけど。

結局そのへんの泥臭さってのは、Cで書いててもLispで書いてても 似たようなもので、Lispプログラマも必要に応じて 「コードがどういうアセンブリに落ちるか」を意識する。 というか、80年代からLispやってた人達ってのは性能に関する議論を はじめるとだいたいそのレベルで考えるみたいで、 すぐに「こっちの方が1インストラクション少なくて済む」とか 「メモリロードが少なくなる」とかそういう話になる。 (MLerもコンパイル後のコードにセンシティブなような 印象があるんだけど、あんまり話したことないから知らない)。

そういう「低レベル(=アセンブラに近い)プログラミング」を している場合でも、Lispだとマクロを使ってがんがん定型処理を 自動化してくから、Cで書くのに比べてはるかに楽ではあるんだが。

このへんの感覚は、90年代以降に登場した高級言語とちょっと違う ような気がする。処理系そのものにタッチしている人を除いては、 その言語をかなり使ってる人でも、コンパイラの吐くコードがどうかって 考えながら書く人ってあんまりいなさそう。 それをしなくていいのが高級言語のいいところ、ってのはそうなんだけど、 クリティカルな部分でunder the hoodのどろどろしたところを いじりたいっていう要求もあるわけで。

効率は欲しいけどそういうどろどろは嫌、って人がstatically typedな 関数型言語に流れるんかな。コンパイラを賢くして全部やらせようっていう。

まあ、Lispっつっても処理系はいろいろあるわけで、 バイトコード処理系だとそこまでこだわりはないしな。 Gaucheだってネイティブコードにコンパイルしての最適化までやる気はないし。 VMレベルではもっと速くしたいけど。

いやまてよ。新しめの言語に比べて、そもそもLispは処理系に興味がある人くらいしか 触ってないって可能性があるか。

(2004/04/22 04:50:21 PDT)

http://homepage3.nifty.com/mogami/diary/d0404.html#21t5

実は液晶というのは単位面積あたりのドット数を増やしても歩留まり (つまりコスト)が変わらないらしい。そういうことなら今すぐにでも ドット数を倍増させてなめらかな文字を表示できるようにするべきだと 思うのだがなぜどこのメーカもやらないのだろうか。 OSが対応しなければならないと言うのはあるのだけれど。

ドット数が4倍になると、ディスプレイへの転送バンド幅も4倍、 フレームバッファも4倍、GPUのフィルレートも4倍、 フォント等ベクトルデータのラスタライジングの計算量も4倍になる、 ってあたりがネックなような気がする。 フレームバッファの量は最近のGPUなら問題なさそうだけど。

映像信号までは既存のままで、LCD素子側でフィルタかけちゃうとか いう手はありかもしれないが、せっかくの解像度があんまり嬉しくないような。

3年くらい前に200dpi, 3800x2400くらいのLCDを展示会で見たが、 もの凄く綺麗だった。理想的には300dpi、30inchくらいのディスプレイで 作業したい。そしたら、机の上に紙を広げてる感じに近くなるんではないか。 解像度でいうとIMAXくらい? そう遠くない話だと思う。

あと、ダイナミックレンジもね。昨年のSIGGRAPHでhigh dinamic range なディスプレイが展示されてたけど、あれを見たら普通のディスプレイが くすんで見える。ただ、長時間見つめていて目にいいかどうかはわからんけど。

(2004/04/16 02:11:26 PDT)

http://www.onweb.to/palestine/siryo/jo-fallujah-en.html (邦訳)

大義の無い戦争だろうと、始まってしまったらあとはどうやって 最小限の被害で終わらせるかを考えるしかない。その大前提は、 「共通の敵=テロリスト&フセイン残党」という図式を保つことだった (それが正しいか否かは別の話)。 それを現地で恨み買うような真似してどうなるのさ。

「共通の敵=米国」と認識されたら、もう手の出しようがないじゃん。 真実がどうであれ、「そう思わせない」ことが、最低限の戦略、 何をおいても守るべき一線だったんじゃないか。

米国はもう手を引くようにとの請願: http://www.moveon.org/unauthority/

すぐに国連が何もかもやるのは無理だろうし、拒否権に阻まれて 動きが取れないかもしれないが、 米国の戦略は下手すぎる。

(2004/04/14 19:22:54 PDT) Lispセミナー

6/11にFranzのセミナーで ちょいと喋ります。見どころは黒田さんとの正規表現バトルです。なんてね。

Shiro: うーん、とりあえず、特にスクリプト言語界隈では 正規表現が使われ過ぎているという現状はあるでしょうね。 ワンライナーならともかく、ちょっと込み入った文法を ちゃんとパーズするなら、簡単なトーカナイザ+手書きパーザの方が 書きやすさもメンテナンス性もずっと高いと思います。ツリーの処理に大げさな 足場が必要な言語だとそれへの敷居が高いでしょうが、Lisp/Schemeなら S式で扱えるので。

一方、Lisp/Schemeでパーザを書くのは非常に簡単ですが、 「効率の良い」パーザを書くのはそれほど自明な問題ではないですね。 そういう点では、特定のドメインに最適化されたサブ言語が提供されてることは 意味があると思います。matchなんかと同じレベルですね。

二つの立場は一見相反するようですがそうでもなくて、結局 最適化っていうのは適用範囲を決めないと出来ないわけで。

って戦略がLispらしいのかなあと。後者が出来ないプラットフォームでは、 つい何でも前者を使って解決しようとしてしまうんじゃないか (ハンマーを持つと何でも釘に見えるってやつですね)、と思います。

Shiro: さんへ: えーっと、 いくつかの問題意識(と、用語)がこんがらがってるみたいで、 コメントがつけづらいっす。正規表現エンジンは 正規文法のパーサーですが、「パーサー作るのが得意な言語なら、 正規表現と同じ戦闘力を持つ何かを作るのもまた得意」って? 「字句解析→文法解析」っていうパイプラインの話と、 各種文法とそのオートマトンの話がごっちゃになってませんか。

後半は、なんとなく言いたいポイントはわからんでもないです。

文字列の正規表現エンジンってのは、ランタイムに与えられる正規文法に 対してそれのパーザを生成するものなんで、文法のクラスの違いを 除けば、LALR文法からパーザを生成するyacc, bisonやらLL(k)からのANTLRやらと 同類であるってことは言えるでしょうね。

で、パーザジェネレータは確かにそのクラスの文法に対してパーザーを 自動生成してくれます。しかし、汎用性の裏にはトレードオフがある。 例えば正規文法をDFAに展開するやつだと生成された表がやたらに大きくなるとか。 文法が既知で簡単なら、べたにオートマトンを書き下しちゃったほうが わかりやすい場合もある。また、正規文法ならあまりそういうことはないけど、 CFGの場合は考えてる文法をLALRやLLに落とすところが面倒である場合もある。 結局、べたに地の言語で書く手間と、外部ツールを導入するオーバヘッドを 天秤にかけてケースバイケースで扱っているってことでしょうね。

その閾値が、言語組み込みのデータ型のサポートなんかで違って来るんじゃ なかろうか。S式使えると楽だよね。って話なんじゃないかなあ。

あと、Rubyの(文字列の)正規表現エンジンがCなのは効率の問題だと思ってますが (Gaucheはそうです)。これは単に、Cだとバイトアレイをスキャンする効率良い コードが書けるからです。文字列でないもの、例えばXMLツリーを パーズする正規表現エンジンだったら、必ずしもCが有利だとは 限らないっすね。

(2004/03/26 00:02:25 PST) プログラミングと体力

ハッキングには体力が重要だ。ただし、ここで言う体力とは、 納期前に連続で徹夜できる体力のことではなく(それも重要ではあるが)、 抽象的なアイディアを具体的に動くものにまで持ってゆく力のことである。

効率的なフォームで走ることを思い浮かべることができても、 実際にそのフォームでフルマラソンを走るためには、 アイディアを実現するに耐える肉体が無ければならない。 美しい映像を思い浮かべることができても、 それをキャンバスに写し取るには、手が理念についてきてくれなければならない。 それらは、訓練と経験によって培われる、広い意味での基礎体力とでも 呼べるものだと思う。

分野を問わず、必要とされているのは、内なる理念と、表現するデバイスとを 繋げることだ。そして、基礎体力は両者を繋ぐチャネルのバンド幅である。 抽象的なアルゴリズムを、実際の現場のコンテキストで動作するプログラムへと 具体化する過程にも、似たようなチャネルがあるように思える。

プログラミングにおける基礎体力は、こんな形で現れる。 アイディアを思いついた時に、そのアイディアを核としてとりあえず 動くものをでっちあげてしまう。多くの場合、できあがったコードのうち、 アイディアそのものを具現している部分はほんの一部にすぎず、 残りの多くはそのアイディアを地面に固定させるための仮の骨組みや足場に すぎない。仮の骨組みや足場を作るのは、面白味のない単純作業だが、 それが無いと大事なアイディアを試すことが出来ない。 この時、そういう骨組みや足場をえいやっと素早く作ってしまえる能力が、 基礎体力だ。

重要なのは、そこにかかる時間である。そういう足場を作れるか作れないか で言えば、多少なりともプログラミングの心得のある人なら作れることが 多いだろう(結局のところ、そういう足場には新しいことは必要ないのだから)。 だが、そこで時間を喰っていると、肝心のアイディアがどんどん古びていってしまう。 アイディアはナマ物だから、捕まえたら十分に素早く料理しなければならない。 下拵えだの出汁を取るだののためだけに料理の本をひっくりかえして もたもたやってたら、アイディアは腐ってしまう。

この基礎体力の恐ろしさは、それが指数的に効いて来ることだ。

この指数的なカーブのどこかに、クリティカルな基礎体力の閾値というのが あるような気がする。多少幅はあるにせよ、それ以下の体力の場合、 有用な結果が得られるまでにあまりに時間がかかるため、 本人の気力が萎えてしまったり、時間切れになるなどして、 結果が出せずに終わってしまうということだ。

いろんなものをつくり出す力、創造性のようなものは、人によって あったりなかったりすると思われているふしもあるが、 頭の中でアイディアを生み出す力に差が無かったとしても、 体力が閾値を越えているか否かで、出力にall or nothingの差が現れる。

プログラミングにおける生産性は人によって桁違いの差が出ると 言われることもあるが、それは、プログラミングが 肉体の物理的な限界というものにあまり左右されないために、 この指数的効果がそのまま観測されるからではなかろうか。

なかなか結果が出せないと焦るものである。 知識が足りないからだと本を買い込んで例題を解いてみたりとか 能力が無いと諦めたりとか。 だが、その理由が、基礎体力が閾値以下であるせいだとしたら、 基礎体力をつけること以外に逆転はあり得ない。 そして、基礎体力をつけるには、自分の頭の中の考えを 形にしてみる、という訓練を重ねるしかないのだ。 (既に閾値を越えている人が行き詰まって悩む場合はまた別で、 そこにはシリアスな問題が横たわっていたりするんだが、 どうも、体力不足の人も自分の問題をシリアスにとらえがちのような 気がする。)

(ここで 述べられている、日本と欧米のCSの大学院生の差なんかも、体力の差のような 気がする。話をしてみると日本の学生にもすごい人は多く、頭の切れという 点ではそれほど差はないと思うのだが、出てくるものの量では 差をつけられているのではないか。あくまで印象論だが。)

(ここで言っている体力は違うようでいて微妙に重なるようでもある、 「体力と知力」も おもしろい。)

(2004/03/21 17:50:36 PST)

Paulの記事"The Other Road Ahead"を 翻訳した。 記事としては"Beating the Averages"と同時期で、ずっと前に訳しかけて 放ってあったのだ。しかし、改めて読んでみると、Webベースソフトウェアが ごく普通になった今でも、頷けるところが多く、多分参考になる人は多いんじゃ なかろうかと思う。個人的には、サーバベースソフトの開発と運用の くだりに、個人的な体験と重なるものが多く、思わず力が入った。

今回訳していて、自分にとって英語の原文を読むことと翻訳することは、 音楽を聞くことと演奏することみたいなものだと思った。 情報を得ることだけが目的なら、翻訳によって得られることは あまり無い。同じく、CDで他人の演奏を聴くだけでどんな曲かはわかる。 でも、その曲を咀嚼し、消化したいと望むと、やっぱり楽譜を入手して、 一通り弾いてみたくなる。たとえ完全には弾けないとしても。 その過程で、CDを聞き流すだけでは気づかなかった微妙な仕掛けや、 さまざまな解釈の可能性について知ることが出来る。 翻訳も同じく、英文を読み流すだけでは気づかなかった細かいところ を調べて感心したり(Paulの文にはいろいろな分野からの引用があり、 調べていて楽しい)、自分ならどう表現するだろうかを考えるところに 楽しみがある。

(2004/03/18 02:22:03 PST)

SchemeでHaskellしたい人達がいるような: SRFI-53: Syntactic computations with computation-rules

ちょっと最近人の書いたCommon Lispコードを触っているが、 こりゃSchemeとは別の言語だなぁやっぱり。 setfやdeclareやreturn-fromがばりばり使ってあったりすると、 わしにはどっちかっていうとCコードに近いものに見えるよ。

(2004/03/13 01:16:22 PST)

なんということだ。
マウイはオアフより寒かった。
ひさしぶりの休暇を、わざわざ寒いところで過ごすことになるとは…

でも、海はとっても澄んでいたのだ。

(2004/03/06 00:59:58 PST)

今年初泳ぎ。昼の陽射しはもう夏のようだ。

(2004/03/04 03:33:40 PST)

Joel on Lisp: flame war寸前のところで、わりといい意見があったりする。

HREF Considered Harmful: Seasideを書いた人のblog。webアプリでのセッション管理について。 Kahuaはpure functionalに書く場合は自動的に "snapshot everything" アプローチだな。というか、functional programmingというのは 本来全てのsnapshotが残るものだ(使われなければGCされる)。 Kahuaでもプログラマが明示的に状態を変更することでその原則を破ることはできる。 あと、persistent dataへの出し入れはmonadicで後戻りがきかない。

(2004/03/01 20:38:18 PST): BGM

深く考える時は音楽は無い方がよい(というか、流していても聴こえなくなる) のだけれど、だいたいやることが決まって手を動かす段になったら 何か流しながら作業するのもいい。

昔はBachの平均律あたりもよく聴いてたけど、〆切前には もっと気力を奮い立たせるようなのがいい。 禁欲的かつ悲壮感ただようAlkanなんかは最適である。

Hamelinの弾くAlkanをがんがんかけていたら、 かみさんが「たまにはこんなのもいいんじゃない?」と ハワイアンのCDを持ってきた。 凄い効果。ほゎ〜んと脳味噌がとろけて仕事どころではなくなる。 一瞬で封印。

(2004/02/26 19:37:43 PST)

Zuさんの いい感じにカスタマイズされたWiLiKi

(2004/02/18 22:56:06 PST): ハワイのくらし

Kahuaセミナー後の雑談や懇親会で、 ハワイのくらしってのがどんなものなのかを聞かれたのだけれど、 特に何に言及するべきか咄嗟に思いつかなかった。 それが「日常」になってしまうと気づくのが難しい。

時々東京に帰って感じるのは、日本、特に東京は、入って来る 情報量がすごく多い街だなってことだ。普通に暮らしていても、 駅や電車内の車内広告、商店街のアナウンスや音楽、周囲の人々の会話等、 膨大な情報が押し寄せて来る。

暮らし方にもよるけれど、ハワイの生活は至って単純だ。 人によってはそれは退屈で不便と感じられるだろう。 私は、むしろこちらの方が集中できる。 ものを買うのにたまに不便を感じることはあるけれど。

(2004/02/03 14:26:33 PST):

lambda on Mars (c.l.sより)

(2004/02/02 01:49:50 PST):

20年近く前の、11ぴきのねこの話を読んだら、 いろいろな思い出が甦ってきた。 11ぴきのねこの歌がぐるぐる頭を回ってる。

元の戯曲にある歌詞に、自分と、先輩の OさんTさんで分担して曲をつけたんだった。 機材が揃っていたOさん宅に何日も泊り込んでカラオケをレコーディングして、 本番の後で今度はキャスト総出でコーラスも入れたサウンドトラックを作った。 古いテープをいちいち引っ張り出さなくても、 結局最後までちゃんと弾けなかったフレーズとか、 ソロで音をはずしたところとか、細かいところまで覚えている。

どんな作品も、一度きりしか作れない。 作り終わったら、それを手放して、 また新しいものを一から作り始めなくちゃならない。 でも、その一度きりの時間は、永遠だ。 時間は遡れないから、二度と手にすることはできないけれど、 その時間があったということは永遠だ。 そして、その時間を誰かと共有したということも。

ものつくりが、ものつくりの孤独を受け入れられるのは、 心の中にそういう永遠をたくさん持っているからだと思う。 外套を脱ぎ捨てるように気楽に終わった作品を手放して、 新しい一歩を始められるのは、 永遠の時間を失うことは決して無いことを知っているからだろう。

(2004/01/31 00:35:59 PST):

昔、ものを作るのは本質的に孤独な行為だと書いたことがある。

創造は、一回こっきりの出来事だ。 欲しくて止まない「それ」は「その時」にしか存在しない。 ひかり輝く「それ」を遠くから見ている時には、何としても手に入れたいと思う。 手を伸ばしてそれを掴んだ瞬間に、それは消えてしまう。

みんなでがんばって、一緒に手を伸ばしても、掴むのは一人一人。 みんながそれぞれ、自分独りだけで、自分にとっての「それ」と対面する。 時間と空間を共有していても、認識は共有できない。成長も共有できない。 手にしたものをそれぞれの心に仕舞って、それぞれの道へと進んでゆくだけだ。

それでもものを作るのは、「それ」を掴んだ瞬間に、 越えられない壁が越えられるような気がするからだ。 真っ暗な空間へと吸い込まれていった音が、 届かないはずの距離を越えて、 自分には認識できない別の世界で、 何かに共鳴する。

何年も何年も経ってから、 そういった共鳴の反響に出会うとき、 孤独の向こう側を信じることができる。

(2004/01/29 22:38:08 PST):

ぼちぼち税務申告の準備。毎年、ぎりぎり(4/15日)まで引き延ばして きたが、今年はひとあじ違う。 GnuCashを導入したからだ。

昔からずぼらで、記録の類をきちんと書くのは苦手。 特に、家計簿、小遣い帳の類は、決して残高が合うことがないため すぐに嫌になって、続いたためしがなかった。 会社を作った頃、"Accounting for the new business"なる本を買ってきて 読んでみたのだが、さっぱり分からなかった。 用語が全然わからないから、用語の組合せも全然わからない。

しかしこういうのもプログラミングと同じ、習うより慣れろ、が効くようだ。 わからなかったらやり直せばいいやって感じでGnuCashにちくちく入れていったら 基本的なところがわかってきた。だいたい、基本的なケースでは ひとつのtransactionに関係するaccountはふたつだけだし、 GnuCashはaccount画面に直接入力できるので、複式であることを 意する必要がほとんどない。金の行き先はどこか、もしくは 出どころはどこかを考えておけば済む。

複式簿記は本を読む限りではめんどくさそうだったが、 ツールのサポートがあれば、単式よりもずぼらな人間に向いていると思う。 単式だと金額があわなくなることがしょっちゅうなんで嫌になるが、 複式だとエントリ毎に基本的に帳尻が合ってくれるし。

会社の会計だけGnuCashでやっていたのだが、税理士に持ってゆく書類を 用意してる時に、ついでだからと家計の方も別ファイルに入れ始めたら はまって徹夜してしまった。会社はもちろんだが、基本的に個人の方も 小切手とカードが中心で現金決裁があまりないので、 その点では帳簿付けは楽である。

More ...