2010/12/05

影響を受けた本

すっかり話題に乗り遅れたんだけど。

If you could go back in time and tell yourself to read a specific book at the beginning of your career as a developer, which book would it be?

元ネタはStack Overflowの What is the single most influential book every programmer should read?。 ときどきの雑記帖から話題を振られたのでぼんやり考えてた。

影響っていうのはどういう状態 (背景知識とか、環境とか) でそれを読んだかに 大きく左右されるから、今良いと思う本でも昔読んで影響を受けたかどうかっていうと よくわからないところがある。では自分が実際に影響を受けた本となると、これまた あんまり多くない。思いつくのは2冊くらい。

Kernighan/Pike: The UNIX Programming Environment

学生の頃、知人に紹介されたバイト先で、 「今忙しいから適当に自習してて、マシン自由に使っていいから」とか言われて 手に取ったのがこの本だった。2週間くらいかけてちくちく打ち込んでいるうちに シェルスクリプティングからシステムコールプログラミング、 yacc/lexを使ったパーザ開発、man pageの作成までひととおり出来るようになった。

この本の何が良かったかというと、 プログラマ向けにUnixの使い方というhowを教える本でありながら、 なぜそういう設計になっているのかというwhyの部分がメタメッセージとして 込められているところ。 単なるUnixの知識というのではなく、 システムの設計のやり方についての根っ子をこれで学んだような気がする。 取り上げられる例の選び方も巧みで、 私も、本を書くなら、いつかこういう本を書きたいなあと思う。

今でも本質的な部分は有効だと思うけど、 いかんせん例が古くなってしまっているので、 これから学習しようという人に勧めづらいのが残念 (今更edやtroffの使い方知ってもねえ)。

ブレヒト：『ガリレイの生涯』

技術書ではないけれど。 旧来の価値観が揺らぐ新時代の幕開けにおいて、 新しい時代を支える知識や技術を持つものはどうあるべきか、を考えさせる作品。 単なるガリレイの伝記ではない。

ブレヒトがこれを書いたのは第二次世界大戦の時期で、 彼の頭にあったのは科学者や知識人と戦争との関わりだったわけだけれど。 コンピュータと情報を扱う技術が速いペースで世界を変えてゆく現代にあって、 それらの技術を使いこなす者のあり方を考える、という読みも出来る。

劇の序盤、口八丁手八丁で目新しい技術を売り込み、 自分の知識欲と好奇心の赴くまま活動するガリレイ。 彼の中に、人々を出し抜く頭の良さと、ナイーブとも言える楽天性が同居している様は、 技術ベンチャーを起こすハッカーに重なるものがある。 そしてそういう人物に人々の過剰な期待が集まることにも。

作られたものは、それが強いものであれば、作り手の思惑に関わらず、作り手を越えてゆく。 作り手を徒に英雄視したり、逆に貶めたりしても意味はない。 作り手には作り手の責務があり、 一方で、作られたものをどう扱うべきかは、 それに関わる全ての人間が考えることだ。

(追記2010/12/06 20:01:06 UTC): あと、 「誰が作るかは重要ではない、誰かが作ることが重要なのだ」 ということも読み取ったな。 「作り手とその取り巻きだけが楽しんでる間は本物じゃない。 その中身が理解できない人々の生活を変えてこそ本物だ」とか。 直接そういうせりふがあるわけじゃないけれども。

(もっと追記2010/12/07 22:01:33 UTC): 紛らわしかったかもしれないので補足。 上の「追記」は作品からの引用ではないので誤解なきよう。 前者は主として14幕のガリレイの「一人の人間にしか書けない書物などない」近辺、 後者は主として3幕と14幕のガリレイとヴァージニアの「夜はどう」「明るい」 近辺のやりとりの、私の解釈ってこと。

Tags: Programming, ものつくり, 本

2010/12/05

git rebase

gitのワークフローやgitメモを書いた頃はgit rebaseの使い方がいまいちわからなかったのだが、最近はupstreamからの取り込みにmergeではなく専らrebaseを使うようになった。

ひとつの理由は、パッチ統合のスピードアップのために、テストが完全に済んでいないけれど取り込み予定のパッチを先行して含んだunstableブランチがupstreamに作られたこと。パッチの正式取り込みは機能テストだけでなく性能テストを通る必要があり、それには日単位の時間がかかる。masterのHEADで通るパッチを提出しても、その時点でテストキューにあったパッチがmasterにマージされた後に自分のパッチが処理されるので、そこでconflictを起こしてrejectされる、ということが頻発した。なので基本的な機能テストを通ったものが先行してunstableブランチにマージされ、特にリリース近くなってキューが詰まりがちな時はunstableに対してパッチを作って提出する、という流れになった。

ところが、unstableのパッチはその後のテスト結果によってrejectされることがある。unstableから手元にmergeしてしまうと、rejectされたものを後で取り除くのがかなり面倒になる。というわけで、masterとのsyncにはrebase、ってことになった。

rebaseの動作はgitのマニュアルに図入りで説明されているとおりで、この原理はすぐにわかる。でも原理がわかっても実際の応用がうまく掴めなかった。特に、conflictが起きた時にどう解消すべきか、というところ。

手元のtopic branchは細かくコミットしているので、同じ箇所をいくつものコミットでいじってる場合がある。そういう場所でnon trivialなconflictが起きた場合、topic branchの最終形に引きずられて直してしまうと、rebaseを続行した時に同じところで何度もconflictを起こしてわけわからなくなることがあった。

  --o--o--O--o--o--X        <- master
           \
            a--b--c--d--e   <- topic branch

こんな形からtopic branchでgit rebase masterしたとする。c, d, eは同じ箇所をいじってるコミット。で、rebase中にcでconflictが起きたとする。

この時考えるべきは、「もし自分がXから作業を開始していたとしたら、cでどのような変更をしただろうか」ということ。これを頭に置いておくと間違えない。元々のcでの変更は実はbuggyで、それをdやeで直したかもしれないけれど、この時点でのconflict解決には、cで持ち込んだバグをそのまま残す。一旦過去の自分に戻って自分の作業をトレースする感じ。

rebaseは履歴が書き換わるから安全ではない、というけれど、自分の過去の作業を、出発点を変えてやり直す作業だと思えば、その性質も納得できる。

Tags: Programming, git

2010/12/01

近頃のらむ太

らむ太の発想1

• ら:「よるはどうしてくらくなるの?」
• 私:「地球が回ってるからだよ。ほら、(地球儀を出して説明) らむ太はここにいるだろ、こっちを向いてる時は明るいけど、こっちになったら暗くなっちゃう。」
• ら:「ちきゅうはどうしてまわってるの?」
• 私: 「それは… (慣性をどう説明しよう)」
• ピコーン、らむ太の頭上に電球が灯った!
• ら:「あ、うちゅうじんがろけっとでひっぱってるんじゃない」

らむ太の発想2

• ら:「ひげはどこからでてくるの?」
• 私:「皮膚の中にひげの根っこがあって、そこで作ってるんだよ。髪の毛もおんなじ。」
• ら:「かみのけはどうしてあるの?」
• 私:「それはね…」
• ピコーン、らむ太の頭上に電球が灯った!
• ら:「あ、かみのけがないと、あたまが『はずかしー』ってなるからだ」

いやいやらむ太、父さんの友達に頭剃ってる人いるでしょうが。格好良いでしょうが。

らむ太の時制

以前は、過去の出来事を話す時何でも「らむ太が赤ちゃんの時」だったのだが、 最近さすがに近い過去について「赤ちゃんの時」はおかしいと気づいたようで、 「きのう」という言葉を使い始めた。

だけど、近い過去はすべて「きのう」なので話が通じないことがよくある。

未来についてもまだ「あした」「あさって」などは理解していない様子。 ただ、数日なら「よるなって、あさなって、またよるなって、またあさなったらいく〜」 という具合に数えることが出来る。

Tag: 生活

2010/11/28

applyの引数リストの長さの制限

http://twitter.com/cddddr/status/8982330207117312

タイプ数削減が目的で (fold-left f acc xs) を (apply f xs) と書くとリストが長すぎる場合怒られる事があるので xargs みたいな要領の xapply を書こうかなと思ったけど面倒なので fold-left で良いやという結論に落ち着いた

処理系の制限で短く書けないというのは癪に障る。 昔はGaucheでもapplyの引数リストに長いリストを渡せなくていらついたものだった。 十分いらついたので、今はこの通り。

gosh> (apply + (make-list 10000000 1))
10000000

引数の長さの制限は依然として存在するんだけど、 それが問題になることがほぼ無くなった。

VMの引数渡しは原則スタック経由、つまりcallerが引数を順にスタックに積んで、 caller側はスタックポインタ相対で引数にアクセスするようになってる。 Gauche VMはスタックが溢れるとヒープに移すようになってるけど、 スタックフレーム単位の処理なので、ひとつのスタックフレームの大きさが VMのスタックエリアを越えるような事態は想定してない。

以前のapplyは引数リストを分解してスタックに積んでた。 なので上のような式だとスタックが足りなくなる。

けれど、長大な引数リストを取るような関数ってのは、まず確実に、 不定長引数を取るような関数なんだよね。で、不定長の残余引数は calleeからはリストに見える。 つまり以前のapplyでは、わざわざリストで渡ってきた引数を 一回ばらしてスタックに積んで、それをcallee側でまたリストに直してた。

今は、callerが不定長の引数リストをリストのままスタックに 積めるようになってて、callee側の必須引数の数に合わせて VMが必要な分だけスタックに展開するようにしてる。 + は必須引数が0なので、上の式だとリストは一切展開されない。

ただ、Schemeの規格上、残余引数リストはfreshなリストでなければならない (calleeが残余引数リストを破壊することが許されている)ので、 リストをコピーして渡さないとならない。CLだとコピーはcallee側の責任なんだけど。 このへんはまだ工夫の余地あり。

今のVMで引数の数の制限に引っかかるのは、 caller側が実際に10000個くらいの引数を列挙するか、 callee側が10000個くらいの仮引数を持っている場合。

前者はまあ、マクロ展開の結果として生じる可能性はあるけれど、 後者のケースでない限りはapply使えば回避できるんで、 実用上は問題ないかと。

今書いてて思いついたんだが、後者のケースでも処理系がコンパイル時に 一定数以上の仮引数は残余引数リストで受け取るようにしてlist-refで 参照する、とか変換かけちゃえばいいんだな。

Tags: Gauche, Lisp, Scheme, Programming

2010/11/26

S式の呪縛

• http://www.dwheeler.com/readable/sweet-expressions.html やっぱS式suck! 頭の固いロートルLisperどもよ、俺がLispの美しい代替構文を考えてやったぜ。完全S式コンパチだが中置式もインデントも使えるぜ。ヨロシク。
• http://chrisdone.com/posts/2010-11-25-lisk-lisp-haskell.html Haskellクール! だけど構文がsuck! インデントセンシティブで綺麗になるのはサンプルコードだけさ。実世界のコードはどうせぐちゃぐちゃになるんだし。S式にすれば曖昧さ無くなるしマクロも使えるし良いことずくめだね! 中身はHaskell、構文はS式、これ最強!

Tags: Programming, Lisp, Haskell