中里一日記

ピタゴラ装置ができるまで

　最近Gitを多少理解した。
　Gitを理解することは、ソフトウェアの設計について深く考えさせられる体験である。おそらく、SCMになんの関心もない人にとっても、Gitを理解することは有益だ。理解した結果ではなく、理解する過程が有益となる。
　Gitを理解した結果は、Gitを理解する過程に比べると、些細なものだ。tarballとパッチによるワークフローの、賢く素早いが面倒な自動化――「そうそう、コンピュータってこういうものなんだよ」と改めて思い出させてくれる。賢く素早いが、面倒。
　インターネットが普及し始めてから20年以上が過ぎた。コンピュータによる自動化が容易な分野は、掘り尽くされつつある。今後新しく登場する種類のソフトウェアの多くは、Gitと似た問題を抱えるだろう。
　Gitを理解するうえでの困難について書き留めておく。

]]> 　
・用語の混乱と不統一
　まず、名詞のcommitと動詞のcommitがある。
　名詞のcommitとはなにか。tarballに属性がついたものだ。この属性を使って、Gitはすべての操作を自動化する。動詞のcommitは、名詞のcommitを作成する操作だ。
　次に、index。あまりにも一般的な名前のためか、「ステージングエリア」という言い換えがよくなされる。
　そしてcheckout。ソースコードを持ってくる操作のように見える名前だが、同時にブランチも操作する。そして、ソースコードを持ってこずにbranchだけを新規作成するときにも、checkoutが使われる。
　どれも「あるある」的な混乱と不統一だが、多くの場合、Gitほどの困難を生み出さずに済んでいる。なぜGitではまずいのかというと、
　
・核となる概念が消去されている
　Gitの核は実は簡単で、tarballとパッチ、それだけだ。tarballはソースコードを固めたもの、パッチはソースコード間の差分を集めたもの。なにも難しいことはない。
　が、Gitは賢い自動化のために、パッチを直接の操作対象として扱わせない。そのため、名詞のcommit、履歴（≒名詞のcommit間の家系）、branchなどの概念を同時に理解する必要が生じる。
　
　自動化は大なり小なりピタゴラ装置だが、tarballとパッチを自動化するだけで、これほどのピタゴラ装置が生み出される。ソフトウェアの設計について考えるうえで、Gitのケーススタディには大きな意義があるだろう。

政治としてのテスト・バグ・仕様

　『ビューティフルテスティング――ソフトウェアテストの美しい実践』をざっと読んだ。
　感想――絶望。

]]> 　
　「完全な仕様書」なるものを考えよう。そのまま実行できるか、少なくとも完全なテストスイートを生成できる仕様書だ。「完全なテストスイート」とは、それをパスすれば必ず仕様を満たしていると言えるテストスイートだ。ただし、これらはあくまで思考実験上の存在である。現実的な時間内に実行を終えられるかどうかは問わないし、実在できなくてもかまわない。
　1913年、ホワイトヘッドとラッセルは、算術の完全な仕様書を書いた。タイトルを『Principia Mathematica』という。算術、つまり、1+1=2や4x4=16といった操作が、この仕様書には定義されている。
　ウィトゲンシュタインはこの仕様書を次のように批判した。
　「足し算引き算割り算掛け算は、世界中の人間が毎日やっている。全世界の全歴史のどこでも1+1=2だし、4x4=16だ。もしこういう操作で意見の不一致を生じたら大問題になるだろうが、深刻な不一致はどうやら今まで一度も起きていないらしい。
　さて、『Principia Mathematica』を徹底的に検討したところ、バグが見つかったとしよう。世界中の人間が一致して出すはずの答えと、『Principia Mathematica』の導く答えが食い違うケースを発見したとしよう。
　そのバグがどんなものであろうと、
　『つまり、これまで全世界の人間がやっていた算術にはバグがあるんだよ！』
　『な、なんだってー！！』
　……ということにはならない。バグっているのは『Principia Mathematica』のほう、ということになる。
　こういう事態が生じる可能性をゼロにすることはできない。完全な仕様書なのにバグっている可能性があるとは、いかがなものか」
　ウィトゲンシュタインによる批判を、実践的に表現すると、本書216-217ページのようになる――

　最近では、特定のアサーションのみをチェックすることが一般的になっています。このため、テストの自動化では以下のような点が確認できなくなります。
・アイコンの背景色が透明ではない
・[Submit]の実行後、演算子のドロップダウンリストがデフォルトの[Plus]（加算）になるため、「4+4=16」のように表示してしまう。
・2番目の値の入力後、キャンセルボタンを無効化してしまう
・[Answer]（解答）が無効化されるべき（グレーアウトされるべき）ときに編集可能となる。
・演算の完了に8秒もかかる。
・生成した新規ページには正しい答えを表示しているが、入力した最初の値として0を表示している。このため、「0+4=8」と表示してしまう。
　人間のテスターは思考することができるため、瞬時にこれらの問題に気づきます。

　「人間のテスターは思考することができるため、瞬時にこれらの問題に気づきます」とは、「バグっているのは『Principia Mathematica』のほう」というのと同じことだ。上で引用したような問題が報告されて、「仕様ではその動作は不定だから問題ない」と言い放つ勇気はなかなか持てない。「バグっているのはこれまでの全世界の人間のほう」よりはまだ言いやすいが。
　つまり、そこにあるのは政治であり、権力だ。習慣という旗印のもとに味方を集められると踏んだテスターや、習慣と争っても勝負にならないと踏んだウィトゲンシュタインは、権力の大小にもとづく政治的な判断を下している。
　テストやバグや仕様について考えるには、これらが政治的問題であることをまず認識しなければならない。が、本書のなかには、そうした認識は見つけられなかった（私が見落とした部分にはあるのかもしれないが）。政治的問題を無視してテストを論じる本書は、私の目には、無様なナンセンスと映る。そのナンセンスに気づきもしない著者たちの鈍感さは、私を絶望させた。

公営ギャンブルは持続可能か

　私の実家の近くには競輪場がある。控えめに言っても小汚い、有り体に言えば大汚い老人が電車に乗ってきて、競輪場の最寄り駅で降りる光景をよく見かけた。私の子供時代にはまだ競輪場は人の集まるところで、「こんなにカモを集めたらさぞ儲かるだろうな。いつか競輪を開催して儲けたい」と子供心に思っていた。
　子供心に――まったく子供らしい話だ。現在の競輪はといえば、マイナス成長を続けて20年、開催自治体の多くを赤字で苦しめている。この世に永遠のものはない。幼い私にはそんな簡単なこともわからなかった。

]]> 　
　幼い私には難しすぎた事実は、ほかにもいくつかある。
　ひとつは、あの大汚い老人たちは、カモであると同時に恐ろしく賢い、ということだ。
　金を損しに集まる人々が恐ろしく賢い、などということがどうしてありうるのか。「賢い」を「高性能」と言い換えれば、わかりやすいかもしれない。あの大汚い老人たちは、高性能な競輪予想マシーンだ。
　「あんなジジイたちの予想が大したものであるわけがない」とお考えだろうか。では競輪を今から勉強して、大汚い老人たちを出し抜いて稼げばいい。「控除率が高すぎる」？　三連単の選択肢は十分に広い。見下せるほど無能な相手なら、25%のハンデくらいは覆せるはずだ。
　……などと私がいくら書きつらねても、「ではあのジジイたちをカモってやるか」と決心して競輪の勉強を始める人間は、おそらくこの地上に一人もいない。また逆に、「あんなジジイたちの予想が大したものであるわけがない」という信念を捨てる人も、やはりおそらく一人もいない。どんなに間抜けな人も、こういうことに関しては恐ろしく賢い。あの大汚い老人たちも同じように賢いわけだ。
　金を損しに集まる人々でありながら、恐ろしく賢い。
　そういう人々のことを、無能だと決め付けながら、実は恐ろしく賢いと認めている。
　どちらの事実も、幼い私には難しすぎた。
　
　あの高性能な競輪予想マシーンを相手に回せば、競輪予想の初心者や中級者はただひたすらカモにされる。それがわかっているから、「あのジジイたちをカモってやるか」と決心して競輪の勉強を始める人間は稀だ。
　ではその老人たちは、かつて競輪を始めたときには、高性能な競輪予想マシーンを相手に怯むことなく蛮勇を奮い起こして競輪場に飛び込んだのかといえば、おそらくそうではない。
　競輪の客が高性能な競輪予想マシーンばかりではなく、初心者・中級者がうようよしていた時代――競輪の勃興期に競輪を始めた人々がほとんどなのではないか。競輪場に初心者・中級者がうようよしているのを見て、「こいつらならカモにできる」と判断して自分もその初心者の一人になった人々の数十年後が、あの老人たちなのではないか。
　つまり、初心者・中級者の割合が多いほど、新規参入者が増えるのではないか。初心者・中級者の割合がゼロに近づくと、新規参入者もゼロに近づくのではないか。
　
　ほとんどの競輪場は、競輪というものが誕生してからほんの数年のうちに建てられている。これは「初心者・中級者の割合が多いほど、新規参入者が増える」という仮説と整合する。客の全員が初心者のとき、新規参入者は一番多くなる。その増加の勢いを見れば、いくつ競輪場があっても足りないと思えただろう。
　
　「初心者・中級者の割合が多いほど、新規参入者が増える」という仮説がもし正しいとすると、客の能力が問われるギャンブルほど持続可能性が低い。
　客の能力が一切問われない公営のギャンブルは、宝くじしかない。この記事の、公営競技と宝くじの売上額グラフを比較してみると、どちらのほうが持続可能性が高そうか、一目瞭然だ。
　現在のカジノの主なゲームはどれも、能力のたぐいを働かせる余地がない。これは偶然や運営の都合ではなく、公営ギャンブルよりもはるかに長い歴史から生み出された知恵かもしれない。

僕はSQLができない

　C.J.Date『データベース実践講義』を読んだ。
　私はSQLが死ぬほど苦手で、少しでも複雑なクエリを書くたびに参考になるものを探す。さっぱり理解できない要素も山ほどある。たとえばIN。主にぐぐれないせいだが。
　なぜ私はこうもSQLが苦手なのか、この本を読んでよくわかった。SQLが糞だからだ。

]]> 　どう糞なのか。
・値と変数を分けて扱うことができない。たとえばSQLの「テーブル」とは値なのか変数なのか
・テーブルの値は行の集合、つまり（Javaでいうところの）Setであるべきなのに、Listになっている。シンプルなSetのかわりに、妙なものがゴチャゴチャついたListを使わされるのがSQL
・SQLの型サポートは貧弱で、意味的にありえないクエリがエラーにならない。品物の個数とID番号がどちらも整数型というだけで比較できてしまう
　
　上記の問題点をご覧になって、なにかお気づきにならないだろうか。
　これらはそっくりそのまま、過去30年にわたって耳にタコができるほどさんざん批判されつづけながら、今もなお再生産されつづけている問題にほかならない――汎用プログラミング言語の世界で。
　
　たとえば.NET Frameworkには、JavaのSetに相当するコレクションがない。Dictionaryのvalueを使わないことで代用するものらしい。
　こういう「代用」は空恐ろしいほど日常的に行われている。JavaのSetが必要十分のところで配列やリストを代用することは完全に習慣になっており、問題意識を喚起するのも難しいほどだ。（Array Considered Harmful あるいは、なぜC言語のポインタは難しいのか）
　必要十分をはるかに超えたコレクションで代用することのなにが悪いのか？　『Array Considered Harmful』では理解の難しさを挙げたが、SQLはこの害悪の巨大な実例だ。
　
　Webプログラミングの世界には、「サニタイズ」という狂気の言葉がある。「SQLインジェクションを防ぐサニタイズ」という具合に使われる。これは根本的には、「品物の個数とID番号がどちらも整数型というだけで比較できてしまう」という事態を気にしないのと同じ問題だ。
　彼らの頭の中はこうなっている――
・整数型に格納できるデータは整数であり、文字列型に格納できるデータは文字列である
・だから個数とID番号が比較できてもいいし、SQLのクエリを文字列結合で組み立ててもいい
・個数とID番号を比較するのはバグであり、プログラマが「気をつけて」防ぐ
・SQLのクエリを文字列結合で組み立てるときには「サニタイズ」する
　「整数型に格納できるデータは整数」という習慣は、「JavaのSetが必要十分のところで配列を代用する」という習慣とそっくりだ。
　
　以上2点に頷いてくださった向きも、汎用プログラミング言語が「値と変数を分けて扱うことができない」という点は意味不明かもしれない。
　では、クラスのインスタンスを値として、つまり整数の値と同じように扱える機能を備えた、オブジェクト指向の汎用プログラミング言語を挙げてみていただきたい。
　そのインスタンスは当然immutableでなければならない。整数の値10の「中身」をいじって、見かけは10のまま「中身」を11にする方法が存在してはならない。そうした変更をプログラマが「気をつけて」防ぐという回答は禁止する。さて、どうか。主流といえる言語はひとつも挙げられないはずだ。
　言語がそうした機能を備えることを妨げるものは何もない。ただプログラマがそうした機能を欲しないだけだ。プログラマは、少なくとも現在の主流を構成する（ということは必然的に糞な）プログラマは、値と変数の区別を欲していない。
　SQLの「値と変数を分けて扱うことができない」という性質は、こうしたプログラマの習性によく適応している。
　
　著者は「今から数百年後にもリレーショナルモデルが使われていることが容易に想像できる」と書く。そうかもしれない。だが著者が本書で述べているような、まともなリレーショナルモデルの実装が主流になることはないだろう。
　私は、今から数百年後にも、SQLが使われているのではないかと想像する。SQLは、キーボードのQWERTY配列がそうであるのと似た意味で、最後の言語かもしれない。SQLより学習しやすく、生産性が高く、リスクが小さい言語がありうることは容易に想像できる。しかし、大多数の（＝平均的な＝糞な）プログラマの習性に適応するという仕事をSQL以上にうまくやってのける言語は、おそらく現れない。

ロードバイクで3万キロ走ってわかったこと（ただし走ったのは主に室内）

　サイコンの距離計が3万キロに達したので、記念にとりとめもないことを書きとめておく。

]]> 　
環境編：
　
・外は走らない
　事故に遭ううえに時間の無駄。室内で固定ローラーが一番。
　
・外を走りたければ、いいところに住む
　東京なら荒川の近く。
　
・とはいえやっぱり外を走る
　そして事故に遭う。私は荒川に出現したというアザラシを見物しに行った（でも結局見られなかった）帰りに事故に遭った。
　
　
設備編：
　
・固定ローラーは可能なかぎり大きく重いものを選ぶ
　私はKurt KineticのRoad Machineを使っている。ちなみにこれは水平が出ていないので、脚の下に板を挟んで水平を出す必要がある。
　
・固定ローラーに使う工場扇は可能なかぎり大きなものを選ぶ
　工場扇の巨大さには怯む。私も最初はへぼいサーキュレーターを買った。しかし工場扇は絶対に必要であるばかりか、標準的な45cmサイズでは夏には足りない。60cmのものを強くお勧めする。
　
・固定ローラーに使うイヤホンはEtymotic Research製がいい
　固定ローラーでは遮音性の高いカナル型イヤホンが必須となる。遮音性でEtymotic Research製に勝るものは見当たらない。使用環境が過酷なためか1年ほどで壊れるので、安いものを選ぶ。
　
・自転車は床に置かない
　床に置くと邪魔だし蹴飛ばす。私はミノウラのバイクタワーを使っている。
　
　
機材編：
　
・初物には手を出さない
　79デュラの右レバーには、一操作で2段シフトする機能がある。しかし私が発売間もない頃に79デュラを買ったら、6→8や7→9は問題なく動作するのに、8→10はまともに動作しなかった。レバーを押しているあいだは10にとどまるのだが、そこからさらにレバーを非常に強く押し込まないと、9に戻ってしまう。シマノにクレームをつけて送り返して交換しても、やはり同じだった。
　ところが先日、事故の修理で右レバーを交換したところ、8→10が動作するようになっていた。
　
・パワーメーターは必要
　テレビのない固定ローラーは考えられるが、パワーメーターのない固定ローラーは考えられない。
　
・Sidiのシューズはダメ
　重い。ソールが狭く分厚く、妙な形状をしている。この妙な形状が合う人にとっては最高のシューズなのだろうとは想像がつくが、おそらく大部分の人はそうではない。
　
・タイヤを新しくしたときには、表面の離型剤を落とす
　消しゴムでこすると落ちる。ショップではウレタンスポンジを勧められた。表面の離型剤は猛烈に滑る。私はこれで一回こけた。
　
・複数の自転車を使う場合、部品の規格を揃える
　たとえばハンドルの直径。私は26mmに統一した。オーバーサイズも1年ほど使ったが、なんのメリットもなかった。
　
・サングラスはフレームレスがいい
　最近のメガネは細長いのが流行りで、スポーツサングラスもその影響を受けてか細長いものばかりになっている。だからフレームのあるサングラスだと、自転車の前傾姿勢では視界をフレームに遮られる。自転車用として売り込まれているサングラスでも、だ。
　AssosのZeghoは、フレームレスのうえに細長の流行に逆らったデザインで、非常に注目しているが、なにしろ高すぎて手が出せない。
　ちなみにフレームレスに限らず逆ナイロールでもいいとは思うが、逆ナイロールのスポーツサングラスはまだ見たことがない。
　
・一番重要な部品はブレーキシュー
　ブレーキシューは制動力を決める最大の要因であり、しかも製品による差が大きい。ブレーキキャリパーの差はシューの差には遠く及ばない。
　以前、雨の中を走っていたら、「ブレーキシューがもう全然ない」と悲鳴を上げている集団を見かけた。カーボンホイールで長距離を走るのなら、ブレーキシューの予備をサドルバッグに入れておきたい。
　
　
整備編：
　
・チェーンを外して洗うのは空しい
　私はKMCのミッシングリンクを使っていることもあり、昔はよくチェーンを外して徹底的に洗っていた。しかし、WAKO'Sのフィルタークリーナーを塗ってブラシでこすって水で流すと、わざわざ外さなくても見た目は十分きれいになる。このことを知ってからは、これだけで済ませている。
　ちなみに私はなぜミッシングリンクを使うのかというと、コネクティングピン方式が信用できないからだ。
　
・説明書はよく読む
　ショップは部品の説明書をくれないことが多いので、その場合はメーカーの公式サイトに頼る。
　何気ない部品でも、説明書には意外なことが書いてある。たとえばKalloy ASA-105（ステム）の説明書は、ボルトを締める順番を指定している。
　
・カップアンドコーンのベアリングはいじらない
　よく「玉当たり調整」や「グリースアップ」の記事を見かけるが、やらないほうがいい。特にペダル。いじる前よりよくなることは珍しく、かえって悪くするリスクが大きすぎる。
　だからカップアンドコーンはカートリッジベアリングよりも実質的な寿命が短い、というのが私の意見である。「メンテナンスできるから長寿命」というのは、いじれることがもたらす幻想にすぎない。人は自分の関与を過大評価する生き物である。
　ちなみにベアリングについてはずいぶん調べた。たとえばグリースのチャーニングとチャネリングについてはご存じだろうか。「グリースが硬すぎて抵抗が大きいから柔らかいものに変えたらよく回るようになった」という体験談をネット上でよく見るが、これは人がいかにオカルトに騙されやすいかの例証といえる。こういう人がカップアンドコーンを「メンテナンスできるから長寿命」と主張するわけだ。
　
　
情報編：
　
・ネットにある日本語の情報はオカルトばかり
　たとえばホイールについての情報はひどいの一語に尽きる。体験ばかりで測定がない。以下にまともな情報源を挙げておく。
　Wheel Stiffness Test
　このページでの実験結果も示すとおり、スポークテンションは一定の下限を下回らないかぎりホイールの剛性とは無関係。
　A note on spoke count
　A note on spoke shape
　ちなみに現在気になっているが情報がないのは、スポークのentanglement（綾）と剛性の関係。
　
　
ポジション編：
　
・ハンドルは高く遠いのが苦しく、低く近いのが楽
　近いほうが楽なのは直感どおりだが、低いほうが楽なのは直感に反する。しかし事実である。
　プロ選手のハンドルは総じて低く遠い。ママチャリ姿勢（極端に高く近い）を見慣れた目には非常に苦しそうに見えるが、実はそうでもない。遠いぶん低いからだ。
　
　
商品開発の謎編：
　
・なぜライトやベルはタイラップ（インシュロック）を使わないのか
　ライトやベルには、大きく重く醜い留め具（バンド等）が必ずついている。必ずだ。タイラップで留めるライトやベルをずいぶん探したが、いまだに見たことがない。大型のライトをタイラップで留めるのは無理としても、ベルや小型のライトならタイラップがふさわしい。
　
・なぜステムの角度は6度付近に集中しているのか
　ハンドルの高さは、主にステムの角度で調整し、コラムスペーサーで微調整するのがいい。これで重量と空気抵抗は最小になり、見た目もすっきりする。しかし現実には、ステムの角度を変えるという発想はないらしい。コラムスペーサーを山盛りにした自転車が巷に溢れている。ステムはまるでパソコンのキーボードのようにメーカーと種類ばかり多く、角度は画一的だ。
　
　
買い物編：
　
・自転車業界の人間は全員イタリア人と思え
　ショップの店員はアジア風の容貌で日本語をしゃべるが、騙されてはいけない。中身はイタリア人だ。
　だから「イタリア製」にこだわる人の気持ちが私にはわからない。なにを買ってもイタリア製ではないか。もちろん、マニアックな商品ほどイタリア濃度は高まる。納期が2年遅れてしかも3日で壊れた、という目にあっても「さすがイタリア製」と感心するくらいでいたい。しかし私には無理なので、変なものは買わないことにしている。
　
・工具の優先順位は高い
　残念ながら、映画『OVERCOMING』の冒頭のモノローグにもあるとおり、壊さないと整備は学べない。だが自分で整備しなければ、自転車を知ることはできない。それでも、まともな工具はそう簡単には壊れないので、工具への投資は比較的手堅い。
　
・高級品を買うのは、安物を十分壊してから
　もちろん壊さずに整備できれば、それに越したことはない。しかし、そうなるはずだと最初から決め込むのは無理がある。私はかなり機械をいじるほうだが、ペダルを壊した。
　
・ステムに高級品は無駄
　どうせすぐにポジションが変わる。ただし粗悪なものだと、フォークコラムの入る穴の精度が悪くて取り付けられないことがある。

人は案外『エリートヤンキー三郎』に近い

　『心理学が描くリスクの世界』を読んだ。心理学におけるリスクと不確実性を紹介した本である。
　内容的には行動経済学と重なる点が多い。行動経済学を紹介した本には、『予想どおりに不合理』という傑作があり、たいていの非専門的な読者には先にこちらを読むことをお勧めする。
　さて本題。以下の問題に取り組んでいただきたい。制限時間は1分間。
　
　ある男が馬を$60で買い、$70で売った。それから彼は$80でそれを買い戻し、再び$90で売った。彼は馬の売り買いでいくら儲けたのか？（215ページより）
　
　1952年、アメリカかどこかの大学生にこの問題を解かせたときの正解率は、44〜46%だったという。
　読者諸氏はこの数字をどう思われただろうか。私にとっては衝撃的な値だった。この問題に半分も正解できないような集団など、現実はおろかフィクションの世界でさえ、『エリートヤンキー三郎』の舞台の底辺高校くらいしか思いつけない。
　衝撃はさらに続く。被験者にこの問題を（一人で）解かせてから、5〜6人の集団で8分間議論させたあとに集団が出した解答の正解率は、72〜84%だった。
　いったい彼らは8分間なにをしていたのか。これまた『エリートヤンキー三郎』の世界のほかに私はなにひとつ思い描けない。
　
　日本の学生とインドネシアの学生を比較した研究も、違った角度から衝撃的であり、『エリートヤンキー三郎』的だ。
　
　アメリカ合衆国において、飛行機の機体の一部の落下による死亡と、サメによる死亡とでは、どちらの方がより多いと思いますか。（236ページより）
　
　2001年の調査では、日本の学生はちょうど半々に分かれ、インドネシアの学生は228対72で「飛行機の機体の一部の落下による死亡」が多かった。（79ページ）
　この差自体は、インドネシアと日本の学生のあいだの「アメリカ」についての情報量の差によるものだろうが、その差が桁違いなものとは思えない。インドネシアの大学進学率を考えれば、バイタリティや頭の冴えではインドネシア学生のほうが優っている可能性が高い。
　だが、情報が多少乏しいだけで、これほど圧倒的な偏見が生じる。バイタリティと頭の冴えと学力と社会的ステータスをすべて備えたエリートが、『エリートヤンキー三郎』になってしまう。
　
　『予想どおりに不合理』は傑作だが、甘口だった。本書は辛口だ。本書を読むと、世の人々がみな『エリートヤンキー三郎』の登場人物に重なって見えるようになる。もちろん自分自身も含めて。

dynabook AZでUbuntu

　dynabook AZにUbuntu 12.04 Beta 1を入れた。
・ハードウェアのせいかどうか知らないが不安定。mozcをコンパイルしていたら2度フリーズした。
・画面を閉じてもスリープしていない気がする。設定の問題か。
・mozcがないのでコンパイルした。物はこちら。

紅茶ボタン終わりました

　本日の配信をもって紅茶ボタンは完結です。長らくご愛読ありがとうございました。次回作にご期待ください。

バレンタインデー

　『君が僕を』のイラストを描いてくださった山田あこさんから年賀状で素敵なイラストをいただきましたので、お礼にガトーショコラを焼きました。
　

　
　ただし焼いたところでお礼は完了で、差し上げるわけではありません。悪しからず。

キャラの性別はどんな根拠があれば確定するのか

　TVアニメの『ギルティクラウン』を毎週楽しく見ている。
　このアニメのいいところはなんといっても、「これは本来なら百合であるべきだ」と憤らずに済むところだ。
　最近では少なくなったが昔は、「誰がどう考えてもこれは百合展開になるに決まってんだろうが！　それがなんでこんな超展開になるんだよこの糞ヘテロセクシスト！」と怒鳴りつけながら監督の首を絞め上げてやりたいような、ひどい作品が多かった（たとえばこれはアニメではなく原作の問題だが、『ラブひな』の瀬田先輩は誰がどう考えても女であるべきだった）。今でもその危険を感じると身構えてしまう。そういう気苦労なしに見られるのは嬉しい。
　また百合に限らず、「これは本来なら××であるべきだ」と憤ることがほとんどない。今週のいのりの殺しっぷりや、嘘界の「処世術だ」には痺れた。そう、フィクションはこうでなくては。
　「これは本来なら百合であるべきだ」というのは、さきほどの例がそうだったように、「このキャラは女であるべきだ」というパターンが多い。逆に腐女子諸氏にとっては「このキャラは男であるべきだ」なのだろうと思う。この観点から『ギルティクラウン』を見ると、いのりは男であるべきだったようにも見える。

]]> 　さて本題。
　いのりは男であるべきだったようにも見える、と思った瞬間、私は気づいた――いのりの性別はまだ確定していない。女装かもしれない。
　普段から女装キャラを警戒するあまりの思い過ごしだろうか。しかし、女装キャラが「男の娘」などともてはやされる昨今なら、1クールやそころ引っ張ってから女装とバラすくらいのことはありそうではないか。
　こうして疑い始めてみると、そもそも、キャラの性別はどこまでいけば確定するのか。いったいどんな根拠があれば、女装ではないと考えていいのか。
　とりあえず、ギャグやSFでない世界では、
・妊娠出産
　SFなら、
・宇宙人
・ロボット
　これらは性別があってないようなものだから、女装も意味がないのでやらない、と考えていい。
　上の3つほど確度は高くないが、
・真正面からのフルヌード
・セックス
・脇役との連れション的なつきあい
　さらに確度の下がるものとして、
・幼少のころのエピソードでもちゃんと女
・ナイーブな「男って」「男だからって」発言
・「男勝り」的な勝気さの発露
　くらいが思いつく。
　そして私が思いつくかぎり、かなり確度の低いものを含めても、いのりが女装でないとする根拠はまだ出ていない。逆に「お色気」や「芸能」や「友達づきあいがない」や「家族が未登場」などの危険要素はたっぷり持っている。
　もしこれが百合なら、ヘルメットとプロテクターを着用して身構えるところだが、幸い百合ではないので楽しく見られる。

ステマ工作員募集

　西在家香織派は紅茶ボタンをステルスマーケティングしてくださる工作員を募集します。
iPhoneアプリの電子書籍はサクラレビューによるステルスマーケティングだらけ
　応募はApp Store / Android Marketの紅茶ボタンのレビュー欄にて受け付けます。素敵なサクラレビューで募集担当者のハートを見事キャッチしてくださったかたを最大0名採用します。お気軽にご応募ください。

Array Considered Harmful あるいは、なぜC言語のポインタは難しいのか

　大昔、子供向けのBASIC入門の本を読んだら、「配列でつまづく人が多い」と書いてあったのを覚えている。
　今でも配列――今ではたいてい「リスト」という格好いい名前がついている――を使うときには、「これこそプログラミングの味！」とでも言うべき不自然さを感じて、抵抗を覚える。
　たとえばループ変数の名前、i。なぜいつも同じ名前、つまり意味のない名前なのか。よい名前がつけられないということは、なにかがうまくいっていないということだ。
　この点で、関数オブジェクトとmapは文句なく正しい。が、それで配列まで正しくなるのか。

]]> 　
　配列とは値の集合であり、少なくとも以下の3つの性質がある。
1. 重複を許す（多重集合）
2. 要素間には前後の順序がある（全順序）
3. 配列の各要素は連続した整数と1対1対応する（インデックス）
　「プログラムでなにをしたいか」という観点から考えた場合、多重集合の性質しか使わない場合が多い。全順序は使うこともあるが、インデックスまで使うことは皆無に近い。使われない性質は余計なものであり、人を混乱させる以外なにもしていない。
　
　たとえば、財布に硬貨が総額いくら入っているか調べることを考えてみよう。
　硬貨を一枚ずつ取り出して額面を加算してゆく、というアルゴリズムを考えられないような大学生はおそらくいない。このとき財布は硬貨の多重集合であり、硬貨同士のあいだに順序はない。
　が、もし配列しかデータ構造がなければ、どうなるか。全順序でインデックスつきの奇妙な財布が出現してしまう。
　さらに、mapのない言語では、インデックスをプログラム上で使うことになる。アルゴリズム上では、硬貨を取り出す順序は偶発的なものであり、財布に備わっているものではない。ところが、もし配列しかデータ構造がなければ、硬貨を取り出す順序ばかりか、それが何番目かという数字までデータ構造に焼き込むことになる。おかしな話だ。
　
　硬貨のかわりに紙幣ではどうか。
　財布のなかの紙幣はたいてい重ねてあるので、順序がある。これならデータ構造が順序を持っていても別におかしな話ではない。重ねてある順序で紙幣を取り出すのも、必要なことではないが自然だ。しかし今度もインデックスはいらない。たとえば配列ではなくスタックでも表現できるし、そのほうが自然だ。
　
　データ構造にインデックスが必要になるのは、配列の要素が他のところから参照される場合だけだ。
　要素のIDとして考えると、インデックスの多くの性質は不要になる。連続した整数である必要はないし、そもそも整数である必要もない。だから実際、IDとしての役割はポインタや「参照」に取って代わられ、インデックスで参照するデータ構造など今ではバイナリファイルでしかお目にかかれない。
　
　配列とはおかしなものであり、高級言語の扱うべきデータ構造としては箸にも棒にもかからない欠陥品である。
　この欠陥品を、少し便利で死ぬほど厄介にしたのがC言語のポインタである。こんなものがわかるのは、配列脳の持ち主だけだろう。

インタプリタがコンパイラになる話

　4半世紀前に「BASICコンパイラ」に憧れた皆様こんにちは。
　当時、インタプリタとコンパイラは格が違う存在だった。
・ホビイストはインタプリタ、プロはコンパイラ
・無料でパソコンについてくるのがインタプリタ、何万円も出して買うのがコンパイラ
・起動してすぐに使えるのがインタプリタ、段取りが多くて敷居が高いのがコンパイラ
　そしてなにより、
・遅いのがインタプリタ、速いのがコンパイラ
　パソコン雑誌の広告等で「コンパイラ」を見て憧れを募らせていた私は、Javaや.NETのJITコンパイラに騙されているような気が今でも少しする。インタプリタなのかコンパイラなのかどっちなんだ、と詰め寄りたくなる。
　もちろん、（昔の）インタプリタと（昔の）コンパイラのどちらと比較しても優れているのがJITコンパイラだということは知っている。それでも、あの絶対的な格の違い、越えられない壁はいったいどうなってしまったんだ、という気持ちにかられる。
　
　そして今度は、インタプリタがJITコンパイラになるという。
PyPy を使ってインタプリタを書く
　これを見て私の脳内には、BASICインタプリタに魔法をかけるとBASICコンパイラに変身する、という夢のような光景が展開された。ちなみにPythonではベンチマークが3倍速になるという。
　（といっても既存のコードがそのまま3倍速になるわけではない。多くのソフトウェアはI/Oのために内部表現と外部表現を変換するところがボトルネックになっており（JavaのJNIが遅いのはこれ。「速度が必要なところはCで書けば～」という議論が成り立たない最大の理由）、PyPyはその変換に余計な手間がかかるので、I/Oの多いソフトウェアではかえって遅くなる）

]]> 　
　格や夢のことはさておき現実問題としては、メリットは速度だけなので、実のところほとんどどうでもいい。が、「書きやすさ」や「開発のしやすさ」と違って速度は定量的に比較できるので、比較してみたくなる。こう書くとまるで経済学者と街灯の話だが、まさにそのものだ。
　「Pythonでは3倍速」といっても、比較対象は別に速度自慢でもないPythonにすぎない。相手がJava VMではどうか。では試してみるか、と思って、上にリンクした紹介を真に受けた私はJava VMのサブセット（マイクロベンチマークが取れる程度のもの）を書こうとして、クラスファイルのパーサを書いたところで心が折れた。
　
　PyPyでインタプリタを書くのに使う言語はRPythonといい、Pythonのサブセットということになっている。……と書くと、書きやすい言語のように聞こえるかもしれない。上の紹介でも「これらはそれほど難しくはありませんよね？」などと愛想のいいことが書いてある。
　真っ赤な嘘だ。
　RPythonは、
・型に厳密
　ひとつのリストや辞書には同じ型のオブジェクトしか入れられない。しかし型を宣言しないPythonでどうやって型に厳密にするのかというと、
・型を推論し、暗黙の型宣言をつける
　C#のvarのような型推論なら便利なものだが、暗黙の型宣言となるとあまり穏やかでない。とはいえ、これだけならまだ大した問題ではないが、
・ジェネリックプログラミングができない
　なにしろPythonは型の緩い言語なので、テンプレートも総称型もない。すべてのメソッドには唯一の暗黙の厳密な型宣言をつけられるように書かなければならず、そのため同じ中身のメソッドを引数の型ごとに書かなければならない。重要な組み込み関数でも、唯一の暗黙の型宣言がつけられないものは削られている。たとえばmap()は削られている。
　ここまでならまだ乗り越えられない壁でもない。が、この上さらに、
・Hello, worldのコンパイルに60秒かかる
　「コンパイルしない方法もあってそれだともっと早くできる」という情報もあるが、型チェックが手薄なのかどうかで役に立たなかった。
　
　疑問――なぜPyPyの作者はRPythonなどという世にも使いにくい言語を作る必要があったのか？
　魔法の都合上、型に厳密な言語が必要なのはわかる。が、それならML系の言語ではなぜいけなかったのか。まるで見当がつかない。
　もし、最初から型に厳密な言語として設計された既存の言語でインタプリタを書けるようになったら、JITコンパイラの恩恵も世に広まるだろう。それまでは無理だ。
　
　一応そのパーサを載せておく。RPythonの恐怖をまだ知らない向きは、私の遺志を継いで、Java VM（のベンチマーク用サブセット）に挑戦されたい。

Coders at Work まとめおまけ

　『Coders at Work』まとめ Part 3の続き。
　おまけと言いつつ、今度こそ本当にまとめる。と言いつつ感想を書く。
　
・C++は明らかにダメ
・デザインパターンには問題がある
・メモリ共有型のマルチスレッドは明らかにダメ
・トランザクショナルメモリは今ホットだが疑問。ちなみにMicrosoft Researchの研究者はダメと結論づけた
・何層ものレイヤを重ねることには不安がある。その上さらにレイヤがブラックボックスなのは明らかにダメ
・プログラミング言語が格納域を扱うことには問題がある
・Prologはもっと注目されるべき
・純粋関数型言語は注目はされているが、うまくいってはいない
・ソフトウェアの再利用はうまくいっていない
・コンピュータにはこの数十年間、見るべき進歩がない

]]> 　
　私見：
　先日、fingertreeというデータ構造を知った。私の感想――「これは早すぎる最適化だ」。
　Fran Allenいわく、「ある計算には良いことが別の計算にはよくないということも出てくるでしょう。ある整理方法が、マトリックスのようなシンプルなものでさえ、違ったやり方でアクセスした場合にはまずいものになり得ます。だからアクセスの順序と場所の組み合わせによるのです」。
　どんなデータ構造が最適かは、実行してみるまでわからない。もちろん理論上は、実行前に予測することも不可能ではない。が、そういう予測はほぼ常に、惨憺たる結果に終わる。たとえコードを書いた瞬間には予測が当たっていても、そのうち外れる。プログラムは変化してゆくものであり、「アクセスの順序と場所の組み合わせ」も変化してゆくからだ。
　何種類かのデータ構造をあらかじめ用意しておき、実行時にVMがプロファイリングにもとづいて最適なデータ構造を選択する？　それが未来だとは思えないし、現状から移行するほどの価値があるとも思えない。
　ではどうすればいいのか。
　最適なデータ構造を選択するプログラムではなく、作り出すプログラムを作り出すべきだ。
　それも、たとえばJavaのjava.util.Mapがインターフェイスでjava.util.HashMapが実装、といったレベルの抽象化では足りない。そもそもmutableなデータ構造は格納域を扱っている。immutableなら格納域の問題はないが、それが実際に機能しうる解決策なのかどうかわからない。少なくとも私は、「クリス・オカサキの本、"Purely Functional Data Structures"」を見て首をかしげた。
　もしかすると、「データ構造」という概念そのものに問題があるのではないか。配列――たぶん最初のデータ構造――が現れたときから、私たちはずっと道を誤っているのではないか。
　おそらく、まだ誰の夢想にも現れていないアイディア、「一夜にして様相を変えるようなもの」が必要とされている。私の生きているうちにそのアイディアが現れるかどうかわからないが、それは必ずある、と私の勘が告げている。

Coders at Work まとめ Part 3

　『Coders at Work』まとめ Part 2の続き。

]]> 　

第11章 L Peter Deutsch

・（巨大なソフトウェアについて）

アボガドロ数はご存じでしょう。10の23乗でしたか。だから世界にはものすごい数の小さなものが詰まっていて、同時にたくさんのことが起きています。私たちがそれで患わされることがないのは、たとえばこのテーブルを素粒子レベルで理解する必要がないからです。

　みんなソフトウェアでモジュール化構造を作ろうと試みており、時と共に技術水準は進歩していますが、それでも、私の意見では、周りを見回して10の23乗個の原子をもったものを目にしながら気後れさせられることのないものの世界の簡単さには、遠く及びません。

　ソフトウェアというのは詳細の学問で、それはソフトウェアにまつわる深くぞっとする根本的な問題です。すべての細かい部分同士がどうやり取りするのかいちいち考えずに済むようにできる、ソフトウェアを概念化し組織化する方法が分かるようになるまでは、物事はあまり良くはならないのです。そして私たちはそこから遠く離れたところにいます。

・（それは変えることができる？）

　始めからやり直す必要があるでしょう。ポインタの概念を持った言語をすべて捨てることです。現実の世界にはポインタのようなものはないのですから。情報というのは場所を取るものであり、時を経て存在し、特定の位置を占めるという事実を、把握できるようになる必要があります。

・私が「記号の世界」と呼んでいる場所は、私にはいつも非常に快適でした。記号とそのパターンというのは、私がいつもランチに食べているものでした。多くの人はそうではありません。私のパートナーでさえそうです。私たちはどちらも音楽家であり、どちらも作曲家であり、どちらも声楽家です。しかし私は音楽の世界に記号という視点でやってきたのです。私は作曲の多くを鉛筆と紙だけでやります。音符はそこにありますが、ピアノから拾い出すわけではありません。彼はそれを聞き、構想を得るのです。

　一方で彼は作曲の多くをギターでやります。彼はギターを弾き、いじり回し、あるいはピアノを少し鳴らし、再び弾き直します。

＃「パートナー」が「彼」であることに注目。これ自体は驚くに値しないが、あとで驚愕することになる。

・問題は、ビジネスの世界で古くからある言い回しですが、「早い、安い、良い。……どれでも2つ選んでください」というものです。早く構築するなら、安く作る方法はあったとしても、なおかつ良いものにはなりそうにありません。

・プログラミング言語については、この40年で質的には進歩していないと強く主張できます。今日使われているプログラミング言語で、Simula-67より質的に優れていると言えるものはありません。奇妙に聞こえるだろうことは分かっていますが、本当にそう思っています。JavaはSimula-67よりさして良くなっているとはいえません。

・（Smalltalkも？）

　SmalltalkはSimula-67よりいいとは思いますが、今日のSmalltalkは1976年にはすでにあったのです。今の言語が30年前にあった言語より良くないと言っているわけではありません。私が現在あらゆるプログラミングに使っているPythonは、30年前にあった何よりもずっと良いと思います。Smalltalkよりも好きです。

　私は「質的に」という言葉をとても注意して使っています。今日広く使われているプログラミング言語はすべて、ポインタの概念を持っています。それよりも質的に優れた基本概念に基づくソフトウェア構築方法というものを私は知りません。

・（PythonやJavaの参照もポインタ？）

　そうです。PythonやJavaで作られたプログラムであっても、ある小さなスケールを過ぎると、すべて同じ問題にぶつかります。CやC++におけるメモリ破損の問題はなかったとしても。

　問題の本質は、システムの情報共有や情報アクセスのパターンを理解し、記述し、制御し、推測する言語的なメカニズムがないということです。ポインタを渡すとか格納するというのはローカルな操作ですが、その帰結は暗黙にグラフを作るということです。マルチスレッドアプリケションの場合については触れないでおきましょう。シングルスレッドアプリケーションにおいてすら、プログラムの別な部分の間を流れるデータがあります。プログラムの違った部分に伝搬するリファレンスがあります。そして最高に良く設計されたプログラムでも、進行する2つとか3つとか4つの異なる複雑なパターンがあり、細かい部分で起きることを実際に制約するように、大きなユニットの性質を記述し推測し特徴づける方法はないのです。みんなこの問題でやられています。しかしこれに関してブレークスルーがあったとも、広く受け入れられ、広く使われている解決法があるとも見えません。

・（関数型言語は？）

　ええ、純粋関数型言語は異なる種類の問題を抱えているにしても、確かにこの難問にある答えを出していますね。

・私が言語設計の目論見に実際踏み出さなかった最大の理由はたぶん、共有のパターンやコミュニケーションのパターンを、十分高いレベルで、十分結合可能な仕方で記述する方法を見いだせるだけの洞察を、やってのけられるほど持ち合わせていると自分で思えないからです。しかしこれは今日のソフトウェア構築が30年前からわずかにしか良くなっていない理由だとも思います。

・（さまざまな種類のアサーションについて）意図したとおりに動くソフトウェアへの道は、アサーションではなく、帰納的アサーションでもなく、より良く、より強力で、より深い宣言的記法にあると思っています。

　私が好きなコンピュータにまつわる警句の作者のジム・モリスは、型チェッカーはネアンデルタール人の証明器だと言っています。もしブレークスルーが起こるとしたら、それはプログラムがどう構成され何をすると意図されているのかを宣言的に記述する、もっと強力な方法から来ると思います。

・もはやLispでプログラムを書かなくなったのは、あのシンタックスに我慢できなくなったからです。シンタックスが重要だというのは紛れもない人生の真実です。

・言語システムというのは3本脚の上に立っています。言語があり、ライブラリがあり、ツールがあります。言語の成功は、この3つの複雑な絡み合いに依存しているのです。Pythonには素晴らしい言語があり、素晴らしいライブラリがあり、そしてツールはほとんどありません。

・（Lispのシンタックスに我慢できなくなった理由について）平方インチ当たりの情報の密度は、中置記法の言語の方がLispよりも高いのです。

・（中置記法の利点について）中置記法の世界では、すべてのオペレータは2つのオペランドと隣り合っています。前置記法の世界ではそうなっていません。もう1つのオペランドを見るために余分な手間がかかるのです。そんなことはみんな小さなことだと思うでしょうけれど、私にとって最重要なのは平方インチ当たりの情報密度なのです。

＃思えばオブジェクト指向言語の文法は、関数名の中置記法。

・私はコーラスで何年も歌っていましたが、2003年の夏に、私たちはツアーでイタリアの古い教会で6回コンサートをしました。その旅行には妻も同行し、ヨーロッパにさらに2、3週間滞在することにしました。

＃「パートナー」は「彼」なのに、一緒に旅行するような「妻」がいる！？！？！？

・（ソフトウェア開発の仕事から手を引いたことについて）

　そして突然気づきました。私がワクワクするようなソフトウェアプロジェクトを見つけるのに苦労していたのは、プロジェクトを見つけるのが問題なのではなく、ソフトウェア自体にもはやワクワクしないからなのだと。今から思うとバカみたいに見えますが、私がソフトウェアに打ち込んでいたそもそもの理由は、それによって世界をより良い場所へと変えられると思っていたからなのでした。もうそんなことを信じてはいません。少なくとも前と同じようには。

第12章 Ken Thompson

・（もっと違ったようにプログラミングを学びたかった？）

　ええ、もちろん。高校のときにタイピングを習っておけばと思います。今でもタイピングが下手で困っています。でも何もしようと思わなかったし、何もしませんでした。そういうけじめがないんです。私はいつでも次にやりたいことをやって終わりです。私にもっと先見性とか計画性みたいなものがあれば、タイピングのようなことはチャンスのあるときにやっていたと思います。あとは数学をもっと深く学んでいたらとは思いますね。数学が役に立つような場面に確かに出くわしますから。そういった小さなことはたくさんあります。しかし昔に戻ってもう一度やり直さなければならないとしても、何も違ったようにはやらないだろうと思います。基本的に私は何も計画せず、ただ次のステップへと進むだけです。そしてもう一度やらなければならなかったとしても、同じようにただ次のステップを取っていくだけです。

・私はコードにはこだわりません。半分進んだところで別なやり方を見つけたなら、ただハックして乗り越えます。私の知っている人の多くは、一行のコードをいったん書いてしまうと、バグでも出ない限りは、それがそのままずっと固まってしまいます。とくにAPIのあるルーチンを書いていて、APIをどこか、封筒裏なりAPIリストなりに書いていようものなら、それで終わりです。どんなにまずかろうと二度と変えられることはありません。私の場合は、もっと良いやり方や分割の仕方を見つけたときには、喜んでまたばらします。既存のコードに執着することはありません。コード自体は常に劣化していくもので、書き換えるにしくことはありません。何も変わらなかったとしても、何かの理由で劣化するのです。

＃「コード自体は常に劣化していく」とは仙人か天使でなければ公言できない真実。

・（コードを捨てるのはいつ？）扱うのが難しくなったときです。私はほとんどの人より早く見切りをつけます。何かを付け加えたいと思い、それを付け加えるのが難しすぎると感じたらすぐにコードを捨てます。捨ててはじめからやり直し、自分のやりたいことが容易にできる別な区分けを考え出します。私が何かを捨てる引き金はとても軽いのです。

＃またもや仙人天使発言。

・（Cのポインタはメモリ破壊を引き起こす機能であり、GCする言語のほうが安全、という議論について）

　バグはバグです。バグがある原因は、自分でそれを作ったからです。実行時の安全性という意味で安全な言語なら、悪用し得るバッファオーバーフローを起こすかわりにオペレーティングシステムがクラッシュするだけです。「死のping」はオペレーティングシステムのIPスタックでした。死のpingはもっとあったのではないかと思います。「スーパーユーザになってマシンを乗っ取るping」はなくなったとしても「死のping」は残るでしょう。

＃「100パーセント安全でなければダメ」論。彼は天国に住んでいるらしい。Plan 9？

・（1999年のインタビューで、もうコンピュータは研究されつくしているので、コンピュータではなく生物学に進むよう息子さんに言っているが、それから10年たって、どう思うか？）

　考えは同じです。コンピュータの世界では予測できないような革新的なことは何も起きていません。一番最近の重要なものはインターネットだと思いますが、それは1999年にもありました。すべてが発展し、個々のコンピュータのスピードは格段に速くなっていますが、でも何が違うでしょう？

・（ハードウェアを極度に抽象化したプログラミングも楽しいのでは？）

　やみつきにさせるものがありますが、自分の子どもに入り込むように言おうとは思わないでしょう。変わったのだと思います。私が年取っただけかもしれませんが、ほかのレイヤの上にある、ほかのレイヤの上に、さらに別なレイヤを作るだけというのでは、たとえば決定性有限オートマトンを作るときの利点は得られないように思います。必要に応じて新しいアルゴリズムは時と共にどんどん複雑になっていきます。1つの新しいアルゴリズムが、他の50個の小さなアルゴリズムに依存しているというような。私が若かったころは、そういった小さなアルゴリズムに取り組んでいて、それは楽しいものでした。それ自体で理解できるものでした。細かく場合分けし、それぞれの場合は聞いたことはあるけれどよく知らないアルゴリズムによって解かれるというような、会計みたいな仕事をする必要はありませんでした。だから変わったのです。変わっていると本当に思っており、その多くは、時と共にすべて階層化され、階層を扱うようになったことによるのだと思います。私は階層を理解するには頑固すぎるのかもしれません。

＃しびれるねぇ（ピングドラム）。

第13章 Fran Allen

・（最後にプログラミングしたのはいつ？）

　かなり昔のことです。Cが現れたころにやめてしまいました。あれは大きな一撃でした。私たちは最適化や変換について非常に進んでいました。大きな問題を1つひとつ解決していました。Cが現れたとき、SIGPLANのコンパイラの会議の1つで、Cを支持するベル研のスィーブ・ジョンソンと、当時私のやっていた自動最適化のプロジェクトにいたビル・ハリソンが議論をしました。

　スティーブはプログラマが自分でやるからもはやオプティマイザを作る必要はないと主張しました。最適化はプログラマの問題なのだと。Cの設計の動機になったのは、高級言語では解決できなかった3つの問題です。1つは割り込みを扱うことです。もう1つはリソースのスケジューリングで、マシンのかわりにキューにあるプロセスのスケジューリングをするということです。3つ目はメモリ割り当てです。高級言語からはできませんでした。それがCの言い分でした。

＃どれも現在では当てはまらない。私見では、Javaレベルの高級言語による素朴な超循環評価器が、Cで実装されキンキンに最適化されたVMよりも速くなる日は10年以内にやってくる。ハードウェアのアーキテクチャが複雑になるにつれて、手作業でのアドホックな最適化はますます不利になる。そしてCPUクロックの向上が止まった現在、ハードウェアのアーキテクチャは複雑さを増す方向に向かっている。GPUやマルチコアなど。

・1960年までには、見事な言語のリストができていました。Lisp、APL、Fortran、COBOL、Algol 60。Cよりも高級な言語です。Cが開発されて、私たちは大きく後退したのです。Cは自動最適化、自動並列化、高級言語からマシンへの自動的なマッピングといった私たちの能力を壊してしまいました。これはコンパイラが大学でもはや基本的に教えられなくなった理由の1つです。

・Cのような言語は問題の解決法を細かく決めすぎてしまうからです。そういう言語が、学問としてのコンピュータサイエンスを壊してしまったのです。

　（中略）

根本にある問題はデータの場所を指定するということです。ほかの言語を見てもらえば、データの場所や、それをどう動かすか、マシンのどこに置くかということまで指定しようとはしないのが分かるでしょう。どの時点でも、究極的には値が問題にされていたのです。

・私たちが最適化の世界で計算についてやってきたことが、データについても行えるチャンスがあると思っています。私たちはデータをあまりうまく管理していません。データを自動的に管理する方法、一緒に使われるデータにローカル性を確立するための良い方法を私たちは持っていないのです。

　とてもエキサイティングな研究の流れがたくさんあります。しかし欠けているのは、もっと大きく大胆なコンセプトです。多くのことは既存の枠組みや現在の考え方の範囲内で起きています。一夜にして様相を変えるようなものではありません。何百万行というコードがあります。しかし私たちは「これはここでやる、あれはあそこでやる」という境界を壊そうと試み始める必要があります。

・現在我々は基本的にリファレンスを使ってやっています。ハードウェアによって、あるいは下にあるオペレーティングシステムやサポートシステムによって動かされています。そしてリファレンスは多くの場合要素のレベルです。

・（つまり、構造体や配列の中を指すポインタを持てるというような意味で？）

　ええ、要素の中にです。そしてそれが、ハードウェアやアーキテクチャのプロトコルに応じて、値をその使われる計算の部分へと運ぶのです。

　しかし別な方法として、データの相対的な位置を最適化の対象として場所を整理することもできるでしょう。ある計算には良いことが別の計算にはよくないということも出てくるでしょう。ある整理方法が、マトリックスのようなシンプルなものでさえ、違ったやり方でアクセスした場合にはまずいものになり得ます。だからアクセスの順序と場所の組み合わせによるのです。アーキテクチャやハードウェアにおける仕事が必要になるかもしれませんが、リファレンスやアドレッシングの機能の一部をハードウェア自体に任せるようにすれば、実現できると思います。データがメモリに来る時点で非常に多くの変換を行えるようなマシンがあります。マッピングをそこで行えるのです。

・私たちに必要なのはもっと高級な言語やドメイン固有言語、そして開発のための本当に良い方法です。

第14章 Bernie Cosell

・私が信じていたことが2つあって、それはとても有効に働いたのですが、プログラムは意味がなければならないということと、本質的に難しい問題というのはごくわずかだということです。すごく難しそうに見えるのは、おそらくはしなければならないことをすっかり理解してはおらず、コードが正しそうに見えるまでハンマーでたたくプログラマによる結果なのです。

・大学によっては9月から5月まで続く2期の授業があって、最初に非常に難しいプログラミングの問題に取り組ませていました。それからいくつもの難問を片付けた後、4月にふたたびそのプログラムに取り組ませるのですが、そのことは最初の時点では言わずにおくのです。そこで意図していたのは、ほんの6ケ月前に完璧に理解したと思っていたことを思い出すのがいかに難しいものか驚かせるということです。

・世の中には、たぶん私を含め、良いプログラマがいて、良いCのプログラムを書くことができます。しかしそれは本来あるべきよりも難しいのです。現代的な環境ではより難しく、それは環境自体が難しくなっているからです。Cの弱さが悪用されたり見落とされたりする可能性のある、注意しなければならない部分が量的に増えています。

・

　Javaは正しくない感じがします。私の古い反射神経がそう言っています。Javaは権威主義的すぎます。これはPerlが良いと感じられる理由の1つです。安全でチェックされていますが、とても多角的であり、私の中の芸術家的な部分を解放して、物事を明確に表現し正しいやり方を考えられるようにしてくれます。ある自由を手にできるのです。

　私が最初にJavaをいじったとき、まだ小さな言語だったときのことですが、「ああ、これはまた例によって、あんまりできのよくないプログラマを助けようと、できることを制限してまっすぐな細い道を歩かせる言語だな」と思いました。しかし私たちはそういうのが正しい地点に来ているのかもしれません。1パーセントか2パーセントのプログラマだけがすごい作品を作り出せる優れた柔軟な言語を使うには、世界はあまりに危険な場所になってしまったのかもしれません。

第15章 Donald Knuth

・（自分の本で取り上げるアルゴリズムについて）nが2の100万乗より大きいときにlog log nの割合だけ速くなるデータ構造なんかは取り入れません。そういうことをやっている論文がすごくたくさんあります。コンピュータが神のようであるとしたら、原理的にはより速いアルゴリズムが得られるという、一種のゲームをしているのです。

・

　問題は、ライブラリを自分で書けないなら、やることはライブラリを呼び出すことだけになり、プログラミングは楽しいものではなくなるということです。プログラミングの仕事がパラメタの正しい組み合わせを見つけるだけということになれば、すごくつまらない話で、そんなことを職業にしたい人がいるでしょうか？

　再利用可能ソフトウェアが過度に強調されていて、それは箱を開けて中に何があるか覗くことが決してない世界です。そんなブラックボックスがあるのは結構ですが、ほとんどの場合箱の中身を見ればそれを改善することができるし、箱の中身を一度知ればよりうまく使えるようになるのです。しかしそうする代わりに人々はあらゆるものの周りに閉じた覆いをつけ、世界のプログラマに閉じたものを渡し、プログラマはそれをいじることが許されないのです。彼らにできるのは組み立てることだけです。それでこのサブルーチンを呼ぶときはx0, y0, x1, y1を渡し、こっちのサブルーチンを呼ぶときはx0, x1, y0, y1を渡すというようなことを暗記します。それを正しくやるのが仕事というわけです。

・私にとってプログラミング言語におけるもっとも大きな革命は、C言語におけるポインタの使用です。ある程度複雑なデータ構造があるとき、構造のある部分と別な部分をつなぐ必要があり、それは様々な方法で高級言語に取り入れられています。たとえばアントニー・ホーアはすごくきれいなシステムを持っていました。しかしC言語で追加されたものは、最初私はそれが大きな間違いだと思っていましたが、後になってすごく気に入りました。つまりxがポインタのとき、x+1はxの1バイト後ということではなく、xが何へのポインタかに応じてxの1つ先のノードを指すということです。xが大きなノードを指している場合には、x+1は大きくジャンプすることになります。xが小さなのを指していればx+1は少しだけ移動することになります。私にはこれが記法におけるもっとも目覚ましい進歩に思えます。

＃いかにも「Cは遅すぎる、アセンブリ言語で書け」と言ってのけた人らしい意見。

・

　ポインタは今では私のお気に入りではなくなりました。私がここに持っているような64ビットコンピュータでは、マシンの能力を本当に生かそうと思うなら、ポインタを使わないほうがよいのです。というのも、このマシンは64ビットレジスタを持っているのにRAMは2GBしかありません。だからポインタは上位32ビットを決して使うことがありません。それでもポインタを使うたびに64ビットを消費し、データ構造のサイズが倍になってしまいます。さらに悪いのは、それがキャッシュを使うということで、キャッシュの半分が無駄になってしまいます。キャッシュはとても高価だというのに。

　だからプログラムを本当に限界まで持っていこうと思うなら、ポインタの代わりに配列を使う必要があります。複雑なマクロを書いて、それがポインタを使っているように見えるようにしているのです。これはある意味小さなことで、やがて廃れていくことでしょう。しかし私にとっては、ポインタは低レベルの記法における重要なアイデアだったのです。私がコードを書いたりデバッグしたりするときには、今でもトンプソンとリッチーに感謝の念を抱きます。どちらが考え出したのか知りませんが。

＃「だからポインタは上位32ビットを決して使うことがありません」って、ファイルのmmapは？

・アルゴリズムやデータ構造のコミュニティにおけるトレンドで気に入らないのは、彼らが「バロック調」とでも言うしかないデータ構造を追求していることです。それは精緻で巧妙で、知的挑戦という点では賞賛するほかないのですが、不毛なものです。生活につながっていません。別世界に生きているのです。それは結構な世界で、それ自体の組織を持ち、友好的でいい人たちですが、個人的にはあまり魅力を感じないし、実用とは結びついていません。

・誰かほかの人の考え方の中に浸って、そのボキャブラリや記法を解読できる能力はとても重要です。その人たちの考え方や発見した方法を理解できれば、自分で発見をするときに役立ちます。私は過去に優れた人々が言ったことが書かれた文献をよく読みます。今日の観衆からすると変わった方法で表現されているかもしれませんが、彼らの記法を通して彼らの考えを捉えようとするのは価値あることです。