いけがみを召喚するには、出現予定を参考にしてください。三週間前までにメールをくだされば、日程を追加するなどしてスケジュールに組み込むことができるかもしれません。勉強会や個人的な会合、中途採用面接などに応じます。日記に書かないことはこちら。
職場でも居室でも論文は読むのだが、分量が違いすぎる。職場で読むほうが圧倒的に多いのである。一日あたりをいうと、少ないときは０本（ここは笑う場面です）、多いときはこれは例外的でちょうど７０本読んだ。
７０ってのはおかしすぎで、実際読んだだけで一日を終えた。これは、詳しくはいえないが、「対象についていけがみがよくわかっていない論文」の査読を依頼されたときである。しかし、著者の主張の解決策は理解できたし、私が詳細に確かめるのも悪くはないかと感じたのだった。そこで、編集者に「私、その対象については、門外漢ですが、査読にあたって最大の努力はしますよ、それで不都合があれば査読者を下ろしてください」というようなやりとりがなされたあとで、査読した（実際、差読者は複数いて、対象の専門の方も査読をなさるということだった）。
で、査読論文の1次参考文献、2次参考文献(1次が引用しているもの、以下同様)、3次参考文献全部と、いわゆる "Introduction to ..." で始まるものをいくつか集めてみた。この段階では集めただけで読んでない。ていうか、何件あるか忘れたくらいたくさんあった。
査読論文の Introduction に書いている情報と、これらの収集物から、私が知らなかった「対象」が何であるかを理解するのにさほど時間はかからなかった。そういう意味で、編集者が私を選んだのは適任だったといえる。しかし、論文誌に権威があるため、推薦するためには「新規性」と「重要性」の二つを言わねばならない。どこかに、同じ手で解決してしまっている論文はないか、あるいは、もっと強い結果を出してしまっている論文はないか、これはある意味 悪魔の証明 である。まあでも、掲載されたあとで、それダサいとか言われると、いくら匿名とはいえ悶え苦しむはめになるので７０本という数字がでてくるわけである。この査読は締め切りを守った。
査読は匿名のボランティアであって、給料はでない。給料の出る仕事に対する論文読みはどうかというと、最近の傾向は、だいたい一日平均で５から１０本である。これは職業的研究者としては究極的に少ない本数であるが、いけがみはマッドなので、それでよいとされている。大変ありがたい職場である。代わりに、させられていることは…おっと職場の機密はここまでだ(という、契約を結んでいる)。
職場でどんな論文を読んでいるか、興味をお持ちの方もおられるかもしれないが、そういう方は我々の書いた論文・テクニカルレポートの参考文献を参照していただきたい。職業的研究者はブログなどで論文について何か述べる暇があったら、自分の論文を書くことに専念しているはずである（そして、ウェブサーフィンなどもしないので、このページも決して見ない）。
2008 論文ファイブとか見て、いいなーと思ったのだけど、上記の大人の事情で書けないことが判明した。内容が仕事と関連すると、あとで呼び出されるから（なんで読んでるんだよ、おかしいね）、Haskell に限定する。気に入った論文を読めばいいと思うよ。リンクは、各著者のページとなっている。
Haskell 98 策定者の一人。しかし、彼の興味は Haskell にとどまらないので(Java とか)、Haskell 以外の人も Wadler の論文を読めばいいと思う。しかし、論文も Wadler's Blog も相当に辛口の英語を使う人である。会ったことはないのだが。あなたが初学者なら、彼の言い方だけは真似しないことをお勧めする。Wadler くらいすごい人になったら、こういう言い方も許されるのだと思われる。
二人の Simon の一人。unsafePerformIO を自由に使うことを許されているたった二人のうちの一人。GHC の中身を熟知しているだけでなく、サポートツール Haddock, Happy, Alex, Cabal にも関与している。この人について言いたいことはいろいろあるのだが、余人におまかせする。最新の GHC の仕組みをしりたかったら、彼の論文を読むべき。
二人の Simon のもう一人。unsafePerformIO を自由に使うことを許されているたった二人のうちの一人。この人に聞きたいことはいろいろあるのだが、私にはその機会はあまり残されていない。Haskell 98 策定者の一人。最新の GHC の仕組みをしりたかったら、彼の論文を読むべき。
Haskell 98 策定者の一人であり、Haskellの Pretty Printer Combinator や QuickCheck, そして「なぜ関数プログラミングは重要か」の著者でもある。上級のスキーヤーであり、ゼミや会議中に皆を笑わせるジョークが好き。必ず大きな腰袋を提げており(中には何が入っているのか教えたりはしない)、部屋は PC のダンボール箱であふれかえっている。John の論文は、なんというか、面白い英文だ。たしかにイギリスっぽい。Arrow に関しては、まず John の論文を読むべきである。が、上級を目指さない Haskell プログラマにとっては関係ない。著名な監督(Home Aloneなど)と同姓同名なのでぐぐるのが難しい。keyword に Haskell を足すこと。
John からは「リーダーとは何か」を学んだ。たとえば、彼がリーダーになるとき、各メンバーに Wiki 上で 「アポなし訪問して構わない曜日と時間を必ず書け」と命令し、実際にそれを行う。彼は、アポなし突撃で「今、あなたは何が問題だと考えているのか」「困っていることは何か」「解決するためのアイデアを簡単に説明してみよ」などとジョーク交じりで要求し、適切かつ知性を感じさせるアドバイスを授ける。熟練した John がこれらのことを行うためには、たったの15分しか必要ない。まさかと思うかもしれないが、想像してみて欲しい。あなたが生まれて初めてスーパーマリオをクリアしたいと思っているとする。しかし、初めてのことなのでまだ達成できない。これが問題だ。ははは。これに対するアドバイスを 15 分で行うことは可能である。そうだろ。John はとても親切で優しい(ただし、相手によるのは、もちろんのことである)。リーダーがチームのところに訪れてアドバイスを行うという行為を、僕は John から学んだ。もうひとつは、進捗状況を報告するミーティングのやり方である。彼は長い時間のミーティングを好まない。15 分で終わらせる。円卓に座り、隣から順番に、今週の進捗を簡潔に述べさせる。スーパーマリオの例をもう一度出せば、A : スタート地点のクリボーに激突 B: ワープできることを知った、こいつはすげえ C: ブロックにのめりこめることを見つけた、これはバグなのか? ... そして、これは強調したいのだが、 Z : nothing! この参加者を寛容にも許すことである。nothing というのはファミコンの電源すら入れていないことを意味する。が、これでもよい。ミーティングで、他者の進捗状況を知るので、それぞれ自然と競争原理が働くのである。糾弾することは簡単だが、それはチームの士気を下げるだけで、何のメリットもない。John は大好きな叔父のような人物なので、紹介に熱が入ってしまった。
Koen は John と一緒に QuickCheck を書いた、という意味で Haskell hacker なのだが、彼の研究の興味はこのリストに載せた人物からすこし外れている。というか、Haskell っぽくない研究と Haskell に関する研究の両方をバランスよく行っているという意味で、僕が見習いたいと感じる。論文リストを見ると、どのようにしてそのバランスをとっているかがわかる。いつぞやのスキー旅行では、リーダーとして見本を見せてくれた。「ありがとう」を相手の国の言葉で言うことにしている、という彼の態度を私はいたく気に入っている。Tack.
品の良い Haskell 入門書を書いた人。それについては、過去にさんざんここで書いた。論文リストに、Haskell プログラマが上級になるために読むべき論文がいくつもある。上級を目指さない人はどうでもいい。
Conor McBride はとても特別な人だ。論文も面白いが、国際会議での発表を見る機会があれば、ぜひ見ることをお勧めする。k.inaba さんはひとつだけ挙げていたが、上級を目指す Haskell プログラマは、Conor の論文を全部読むべき。上級を目指さない人は Conor にとっても関係ない人だろう。
以上、駆け足での紹介になり、５人ではおさまらなかったので有名すぎるほど有名な７人にしてみたが、本当に紹介したい人はまだまだたくさんいる(Conal Elliottとか、Peng Liとか...)。上級初級問わず、Haskell プログラマは The Haskell Sequence | News about Haskell を購読するべきである。
RSS feed を再開しました。RSS の思想を尊重するために全文配信はしません、あしからず。
