2010/01/30

Common LispとScheme

Common Lispリハビリ中。

CLとSchemeを渡り歩く時にひっかかるのは、関数名や構文名が微妙に 違うことととかLisp-1 vs Lisp-2とかじゃなくて、 もっと漠然とした、しかし根本的な「文化」のようなものである気がする。

CLってわりと何でもLispの中で解決しちゃう傾向が強くて、 ビルドシステムもユニットテストもデバッガも全部Lispで、 REPLからAPIをキックすることで何でもできる。基本、REPLを離れる必要が無い。 一応オートメーションのためにMakefileはあるけど、 中では単にlisp本体を起動してビルドスクリプトを 読ませてるだけとかね。 OSから全てLispだった時代を引き継いでいる文化なので、 むしろLispの外に出ることの方が特例なのだろう。

大規模ソフトウェアだと、このLispで書かれたベースのシステムの上に そのプロジェクト特有のコンフィグファイルを読ませたり テスト時のサーバプロセス起動を自動化したり…といったレイヤがやっぱり Lispで書かれて載っかってる。

また、大きめのプロジェクトだとソースファイルがいろんなサブディレクトリに 分散してるけれど、一度asdfなどのビルドスクリプトをちゃんと作っちゃえば 後はソースの位置を意識する必要がほとんどない。関数定義を追っかけるのは Emacsから直接飛べるから。

Schemeの場合、といってもScheme界も一枚岩ではないのだけれど、 もともとの言語仕様が小さいのと、Unix族の上で発展した 処理系が多いためだろうか、言語機能の外の話、つまりビルドや各種テスト、 コンフィグレーション、配布パッケージ作成などは、 積極的に言語の外のツールを使おうという傾向があると思う。

すると、あるプロジェクトに参加してとりあえず全体の構成を把握したり ビルドやテストのプロセスを知ろうとした場合、Schemeのプロジェクトだと そのへんは言語よりもUnix一般の知識を使って見て行くことになる。 GNU以降のオープンソースな処理系だとだいたいそのへんは共通してたりするので 処理系毎の細かい違いに足をとられる前に全体を把握できる。外から中へ 見て行く感じだ。

全部Lispで完結するCL上のプロジェクトの場合、逆にとりあえず REPL起動してasdfでビルド/ロードして、aproposやタグジャンプを使って Lispの「中から」全体を把握してゆく方向になる。 ここで「外から中」を混ぜるとうまくいかない。ファイルシステム上で Makefileや*.asdを覗きながらビルドの依存関係を追っていくのは、 規模が大きいとかなり辛い。特にビルドが何段階にもなってたり、 途中コンフィグファイルが自動生成されたりしてると。 プロジェクト独自のレイヤがLisp上に載っかってる場合は、 とにかくREPLからそういうレイヤを突っつけるAPIを見つけ出して 慣れることが早道だ。

けれども私自身はUnixで育ったので、どうもファイルを基本に 考えちゃうところがあるんだなぁ。何がどのファイルにあるかの マップが頭の中に無いと迷う感じ。タグジャンプしまくってると 迷路を彷徨ってる気がしてくる。

まあ、ファイルの位置とソースの構成との紐つけが緩いのは 最近のIDEとかでもそうなんで、むしろファイル構成と ソース構成を対応させたいって意識の方がUnixべったりすぎるのかもしれない。

Tags: Programming, Lisp, Scheme

2010/01/27

瞬間最大風速

記念撮影 :-)。1/26 10:47HST。

Amazonに書影がなかなか来ないのはなんでだろう。

Tag: Publication

2010/01/25

『プログラミングClojure』のできるまで (訳者サイド)

2009年の5月下旬、まだ原書がベータ版の頃だが、オーム社の 森田さんより企画の話を聞く。当初は「誰か訳せる人に心当たりはないか」 という問い合わせだった。 あいにくClojure使いで翻訳に時間の取れそうな人、というのは 思いあたらなかったのだけれど、

• 2008年のDLSでRich Hickeyの講演を聞いて、私自身Clojureに興味を持っていたこと (ちなみにGauche 0.9に入っているutil.sparseはClojureのデータ構造を参考に している。immutableではないけれど)。
• 夏に出張が続くことがわかっていたので、断片的な時間が翻訳に当てられそうなこと
• 原書のpdfに目を通してみて、文体のリズムが自分に合っていそうなこと

から、原書刊行直後の6月中旬に正式に引き受ける返事をした。

作業は森田さんの作ったシステムで行った。XMLマークアップされた 原稿がパラグラフごとに重複しており、一方に言語タグenが、もう一方に jaがついている。そのjaの部分を翻訳で置き換えてゆくという形式だ。 原稿はsubversionで管理されており、こちらで訳してコミットすると 向こうのバックエンドでja部分だけ抜き出して組版してpdfにしてくれる。 バックエンドの組版システムはたぶんIdeoTypeの 後継にあたるものだと思うのだけれど、直接触ってはいないのでわからない。 Gaucheも一部に使って頂いているようだ。

実際の翻訳作業の多くは、飛行機の中や出張中の空き時間で行った。 細切れの時間はコーディングには向かないけれど、2時間くらいの単位があると 翻訳は進められる。私のスタイルは、一度読んで理解したらパラグラフ単位で 頭からがしがし訳してゆき(pass1)、全部訳した後で呼応関係を考慮して修正(pass2)、 その後細かい直しをする。pass2は、前の方で出てくる要素が後の章での話題の 前フリになっていたりする場合に、訳語の選び方を間違えると前フリが成立 しなかったりするので、そこを調整するのに必要。なので全部訳してからでないとできない。

本書の場合、原文も簡潔・直接的で訳しやすく、たぶんpass1は一章あたり 実質3-6時間くらいだったと思う(ただし、これには「頭の中で熟成させる」時間は含まない)。 出張ラッシュが終わる9月頭には全9章中8章が終わっていた。

ところがここで全部終わらせなかったのが計算違いで、その後本業が一気に忙しく なってしまい、2ヶ月ほど眠らせることに。レビューアの方々も9月には 揃っていたのだけれどお待たせしてしまって申し訳ないことをした。 もうちょいがんばってたら、私が忙しくなる時に平行してレビューすることで レビュー期間をもっとたっぷりとれたと思う。結局、1月中に刊行するには これがぎりぎりの日程、というところになって尻に火がついてpass2まで 終わらせ、1ヶ月弱のレビューを経て発行となった。

レビューは、レビューアの方々にpdfを読んで問題点をtracにイシュー登録してもらい、 私の方で時間が取れる時にバッチで修正する形で行った。 チケットをもりもり解決してゆくのは気持ちよかったけれど、 pdf-チケット-原稿XML間のリンクを自動化するなどできると もっと使いやすくなるかもしれない。

訳語や送り仮名の統一、レイアウト調整だけでなく、 日本語版索引の作成(原書でも索引は本文中にマークアップが入っているのを 自動抽出しているが、日本語にする場合は見出し語の一貫性やソート順などを 考慮しないとならないのでかなり面倒)などの作業は 森田さんやトップスタジオの金子氏など編集の方々の手によるものである。 他にも、名前の出ないたくさんの人の手がかかって一冊の本が完成する。 訳者の仕事は一部にすぎない。

もっとも、名前が出るということは責任を引き受けるということで、 おかしな訳があれば私の責である。さっそくいくつか見つかっちゃってるようだが、 適宜サポートページ http://practical-scheme.net/wiliki/wiliki.cgi/Shiro:ProgrammingClojure にて正誤表をアップデートしてゆくのでよろしく。

Clojureの翻訳本を出すことをドイツ人の友人に話したら、 「いいなあ、ドイツではCS関連書のドイツ語翻訳というのは需要が少なすぎて出せないなあ」 と言われた。専門書の翻訳書が出せる市場がある、という点では日本はわりと貴重な 存在なのではなかろうか。そりゃ原書をすらすら読める方が情報網は広がるだろうけれど、 人のアジェンダは人それぞれ、 皆が皆、母国語と同じくらい英語を読めるようになるだけ時間をかけられるわけじゃない。 本書でLisp系言語へのとっかかりが増えてくれたら嬉しい限りである。

そしてもちろん、最終目標はLisp族によるJavaエンタープライズの乗っ取りである。ふはははは。

(追記2010/02/10 00:45:28 UTC) 編集者の森田さんからのふりかえり： 『プログラミングClojure』のできるまで（編集者サイド）

Tag: Publication

2010/01/24

『Just after sunset』 - A Joy of Recreation

I didn't want to write about answers, I wanted to write about questions.

一昨年に出たスティーヴン・キングの短編集。 往復11時間のフライトの友にと空港のスタンドで買って、一気に読んでしまった。

前にも書いたけれど、『The Dark Tower』シリーズ完結後の キングは、何かに「書かされている」という、 せきたてられる、あるいは憑かれている感じが無くなった、ように思える。 同時に、新しいことへチャレンジするむきだしの野心も影を潜めた。 本書でもいくつも新しい試みはなされているようだけれど、 そこに気負いはあまり感じられない。何より、キングはもう 「自分自身の二番煎じ」を全く恐れていないように思える。

何かを創る者にとってのひとつの障害 (もしかすると最大の障害) は、 成功した過去の自分の作品ではないだろうか。 あの時は創造の神が降りてきた。後から振り返ってもなぜ自分があれを書けたか わからない。けれども創作者でありつづけるには、それを越えるものを 創らなければならない。これはかなりおっかないことだ。 ついつい過去の成功パターンを踏襲したくなるけれど、 マンネリズムに陥ってジリ貧になるのもまたおそろしい。

本書に納められた短篇からは、キングの過去のいくつもの作品の エコーが聞こえる。ファンならばおそらく各短篇について、 類似ネタを使い同じような帰結をたどる、 過去のキングの作品の名前を挙げられるはずだ。

でも面白いのだ。 書いていて楽しんでいるのが伝わってくるような気がするからかもしれない。 また、ストーリーテリングの技術が円熟しているからかもしれない 読者を驚かせるような技術ではないけれど、安定していて、 全く障害なく読者をストーリーの流れに載せてくれる。

人生観を変えるような尖った作品はないので、キングを初めて読む人には あまり向いてないかもしれない。読みやすいけれど、「キングってこんなもんなの?」 と思っちゃうかも。でもキングの長年のファン、Constant Readerなら 間違いなく楽しめる。

個々の作品について言うと、"N." が素晴らしい出来だった。 これも、モチーフや形式はキングの過去の作品のいくつかと共通しているけれど、 ナラティブの強さはキングの最盛期を思わせ、 それでいて余分な贅肉を持たない勢いは若い頃の短篇のようだ。

RecreationはRe+Creationでもある。 つくることは、苦しいばかりじゃない。

Tag: 本

2010/01/23

Berkeley

昨夜は別の友人とBerkeleyにて夕食。 美味そうなレストランがたくさんあって良さげな街だなあ。 サンフランシスコに比べると道幅も行き交う人もゆったりしてる。 友人曰く、Berkeleyのドライバーは運転がとても寛容だそうな (ホノルルよりも!)。 今回のプロジェクトでまた来ることがあったらこっちに泊まろう。 OaklandまでBARTで数駅だし。

Tag: 旅