原著である『Coders at Work: Reflections on the Craft of Programming』が執筆されたのが2009年で、2019年現在の時間軸から見るとおよそ10年前のインタビュー集ということになるが、10年前に想像されていた未来よりも、プロセッサ性能などの進化がゆっくりだった事もあってそこに面白さを読み取ることもできる。

いずれも強烈な個性を発する凄腕プログラマの、プログラミング行為に関する一家言が舌鋒鋭く収録されており、読むのは大変だが面白い一冊である。全体として、道具にEmacsを使っているハッカーが多かった印象。

読みながらマークした箇所などから、備忘録として書いておく。

ジェイミー・ザウィンスキー

Netscape（現代のMozilla Firefox）初期開発者かつXEmacsの作者。
初期のNetscapeが成功してから買収され、めちゃくちゃなリリース戦略で沈没した経験を赤裸々に語っている。
とにかくC++への恨み節がすごい。
過剰なエンジニアリングに陥ることは避けて、とにかくリリースしてからコードを綺麗にすれば良いって主張には共感した。
組織を作るなら4人以下のチームを複数作れ、という格言もよい。

ブラッド・フィッツパトリック

memcachedの作者で、インタビュー当時はGoogleに在籍していたらしい。
C++の構文はひどいものだが、実行効率のために選択して書くのは気にならないと述べている。Googleでもコア言語として選ばれているが、パフォーマンス上必要のないところまでC++で書きがちな文化だとも。この前後にGolangが登場したと考えると興味深い示唆。
現実的なC++を選択する立場として、JavaのJVMをこき下ろしているのが面白い。
コードを読むことの大切さが、後になって身にしみて感じるようになったとのこと。
スタイルガイドは大事だし、ファイルやプロジェクト内で一貫したスタイルが使われていることが大事だとも。確かにGoogleもスタイルガイドをオープンに公開しているもんね。
「あのXSS脆弱性を作りまくっているPHPプログラマたちは、航空管制しすてむを作っているのとは別な種類の人間ということは、はっきりさせておいたほうがよい」

ダグラス・クロックフォード

JSONの生みの親。ECMAScript 4（ES4）やES5の改定にも携わった。インタビューでも触れられている。
マッシュアップブームの隆盛（今となっては懐かしい）こそが、再利用可能コンポーネントの実現だが、これはXSS脆弱性を作っているようなものだと。
C言語のデザインには山ほど間違いがあり、++演算子はとくに危険。++は使わないと主張。
コードスタイルの議論（カッコをどちらに付けるとか）に意味は無い。あれは車が道路の左側を走るべきか右側を走るべきかのような話で、正解は無いとも。これは分かる。
「多くのクラス指向の言語では言語自体が規律を課していますが、JavaScriptでは自分で規律を持ち込む必要があります」　JSLintを作った人らしい主張。
数学はプログラミングにとって重要だが、それ以上に文章を書く能力のようなものの方が必要。母国語もまともに書けないならプログラミングはできない。耳が痛い。

ブレンダン・アイク

JavaScriptの言語設計者。インタビュー当時はMozillaのCTOを担っていたよう。
採用が見送られたECMAScript 4（ES4）の議論を振り返り、「プリミティブを最小限にしてシュガーを取り除け。ラムダさえあれば何だってできる」という主張は、多くの人に合わないと切って捨てている。実際、2019年現在のECMAScriptでは、関数オブジェクトやプロトタイプベースといった強力過ぎる機能はなるべく利用者からは隠されるような構文が増えている気がする。
Netscapeが大きなコード書き直しの失敗例となったのは、デザインパターン本を振り回すような連中のせいと強烈に批判している。デザインパターンを聖典のようにありがたがる連中がかなり嫌いっぽい。
採用したい人材は、C++やJavaのデザインパターンを行儀よくやっている人物ではなく、何か違ったことをしている人物。優秀な人は優秀な人と働きたがるから、紹介（コネ）はズルに見えるかも知れないが有用とも。

ジョシュア・ブロック

JavaのCollections Framework設計者で、インタビュー当時はGoogleのJavaチーフアーキテクトの肩書き。これだけで強い……。『Effective Java』共著者の1人。
『人月の神話』はみんな読むべきと。読もう（積んでいる）。
人はプログラミング言語を選ぶとき、コミュニティをも選んでいると主張。酒場を選ぶのに似ている（そこにどんな人がいて、どんな話をしているのかが重要）と。
「要求分析は交渉であるだけでなく、理解のプロセスなのです。多くの顧客は問題を言いはしません。ソリューションを語るのです」　顧客が本当に必要としているソフトウェアについて、なかなか深い話。
EclipseやIntelliJのような現代のIDEsは素晴らしく、これらのお陰で気軽にリファクタリングが行えるようになり、みんな綺麗なコードを書くようになったと。本書には低レイヤに強い人が多く登場するが、この人はビルドツールなどの変遷には付いて行けないと話す。その辺りも何となくJava畑の人という印象がする。
Javaの新しい構文（ジェネリクスやforeachなど）を入れるにあたっての、デリケートで慎重な考え方の下りが面白い。「C++は複雑さの閾値をとうに越えている」とも。

ジョー・アームストロング

プログラミング言語Erlangの作者。伝説的な人物がどんどん出てくる。
現代（ここでは2009年）のプログラマには、選択肢が多くて選択が重荷であると言っている。10年後の2019年はさらに大変だ……。
コードの書き方で迷っている時は、同僚に話してみることが大事で、自分が何に迷っているか説明しているうちに回答へ行き着くことがよくあるとも。これめっちゃ分かる。
Cを理解したいならCのコンパイラを書け、Lispを理解したいならLispインタプリタを書け。強い。
デバッグ手法に関しては強硬なprint文デバッグ論者。
コードは問題に対する答えであって「仕様を知りたいならコードを読んでよ」はプロと言えない。ユーザガイドのためにドキュメンテーションは必要とのこと。はい。
ドキュメントを書くことは型について考えること。「is a」から始める。
優れたプログラマの見分け方は、問題に動かされるのかソリューションに動かされるのか。その時に問題を選ぶ人であるとの言。

サイモン・ペイトン・ジョーンズ

プログラミング言語Haskellの設計者でありコンパイラGHCのリード開発者。
論文でもプログラミングでも、「どんなにつまらなく見えることでもいいから、何かを始めなさい」が自身にとってとても重要なアドバイスだったと懐古している。わかりみが強い。
みんなが関数プログラミングを書ける必要は無いが、純粋関数的な傍流世界からの見え方が、Pythonのような主流世界の言語にも影響を与えると評している。
この人もprintfデバッグ論者。
「ソフトウェアを制限する主要なものはコンピュータのスピードではなく、ソフトウェアが何をするのか理解する我々の能力なのです」　かっこいい。

ピーター・ノーヴィグ

Sun→NASA→Googleと渡り歩き、Googleのリサーチ部門トップを務める。この人もLispハッカーで、Lisp & Emacs利用者の登場率が本当に高い。
Googleにおいても成功する人は「完璧に理解する」よりも「とにかく前に進んでやってみよう」とする人であるとのこと。いい話だ。
テスト駆動開発アプローチには否定的で、何故ならGoogleにおいて欲しいものはassertEaual（等しいかチェック）などよりもassertAdFastAsPossible（可能な限り早いかチェック）であるから。検索エンジン会社の研究部門ならではの見方と感じた。
オーバーエンジニアリング問題について、「賢くありたい、完全でありたいと思うのでしょう」「90から90パーセントまでいくと、投資に対するリターンは逓減していきます」などと述べている。研究開発は特にそうだろうなと思う。
良いレビュワーはたくさんの問題を見付けてフィードバックしてくれる人、良いプログラマは書くコードが最高でなくても、ソフトウェアを構成するコードを完全に理解している人であるとのこと。面白い言い方だけど、たしかに現場の助けになる人はこういうタイプ。
採用後にうまく行く人は、採用会議の時点で面接官の誰か1人が最低ランクの評価を付けている人。その人を採用するために「この男は採用しなきゃいけない」と他の誰かが熱く用語するような人が最高だと述べていて、この話はめちゃくちゃ面白かった。

ガイ・スティール

プログラミング言語Schemeの共同設計者で、Common Lisp/Fortran/C/ECMAScript/Schemeの標準化組織に携わっている。EmacsとJavaの誕生にも深く関わっている。何それ強い……。
「必要は発明の母です。アイデアが生まれるのは、特定のコンテキストにおいて必要となったからです」　至言だ。
良いプログラムは、意味が感じられるようなストーリーがあり、読み易いとのこと。
初期のEmacs実装において多くのキーバインディング派閥があって、そこから共通セットに収斂していく過程が読める。面白い。
初期のSchemeコミュニティは反対投票文化で、全員が同意しないと言語に何も付け加えられなかった。Common Lispは、多数であればみんなを満足させるに十分だから採用される文化。
C++は書くけど好きではなく、C++で書こうと思うようなことはJavaでもっと簡単にできると主張。C++の努力は認めるが、型システムが根本に壊れているCとの後方互換を確保するデザインは致命的な欠陥であるとバッサリ。

ダン・インガルス

プログラミング言語Smalltalkの主要実装者。グラフィックス描画分野でもBitBltの考案と実装を知られている人物。
Smalltalkで真に重要な概念はオブジェクトでなくメッセージ・パッシング。これはよく聞く言説であると自分も思う。
若いときに学ばなきゃいけないということはない。若者はただ単に多くの時間を持っているというだけ。勇気づけられる言葉だ。
「優れたデバッガが存在するのにprint文に頼る必要なんてあるの？」派閥の人。Smalltalkのシンボルデバッガはとても優秀らしい（僕はSmalltalkを触ったことが無いので分からない）。

L・ピーター・ドイチュ

Ghostscriptの作者でありJITコンパイルの考案者。強い。
時と共にかつてはプログラミングが必要だったことの多くが、もはや「プログラミング」ではなくなり、そこそこちゃんと動くようになってきたという時代観を披露している。
「ポインタの概念を持った言語をすべて捨てることです。現実の世界にはポインタのようなものはないのですから」　Cのポインタを功罪あったと語る人は本書に多く登場するが、ここまで切って捨てる言い方は珍しくて印象に残った。
XPやアジャイル開発の支持者ではない。顧客との強い結びつきによって要求を強く満たせるかも知れないが、顧客は自分の必要とするものを必ずしも分かっていないからと主張している。これはiPhoneを生んだAppleなどの例を考えても、頷ける言説であると思う。
ソフトウェアは資産として扱うべきであり、継続的な保守や投資を必要としない資産は無い。ソフトウェアライブラリを保守するには、ある程度のコストがかかると期待すべき。いかにも。
この人もLispハッカー。でも構文はPythonの方が好きだとも。
Perlは言語としては醜悪であり「犬の間違った端から出てきたもの」とのこと。

ケン・トンプソン

C言語の先駆けB言語の作者であり、ベル研究所でUNIX誕生にも寄与している。UTF-8の考案者でもある。いわゆる「ヒゲ面ハッカー」の元祖。すごい。インタビュー当時はGoogleに在籍していた模様。
ほとんどの人よりも早く「コードを捨てる」決断ができると言っている。
うまくはやるべきだが本当に良いものを追求すべきではない。そこそこ良いところから本当に良いところまで持って行く頃には、ムーアの法則に追い越される。シビレる言い方だ。
C/C++がバグを作っているのではなくて使い方の悪い人がバグを作っている。
デバッグはprint出力派閥。
GCCが出すコードはひどい。GCCが現れてから1000倍もコンピュータが速くなったのにコンパイラがとんでもなく遅い。辛辣な意見だ。
Javaで主流になったGCは、OSやコンパイラを書くならGCを使うのは間違い。許容できるコストを支払って考えたくないものを丸ごと取り除けるなら使っても良い。
Googleでコア言語であるC++よりもCの方が好き。テストもおもちゃも、大抵のコードはCで書いているとのこと。C++は良いところもあるが全体としては悪い言語との評。

フラン・アレン

女性初のチューリング賞受賞者。長い45年間のIBMでのキャリアでコンパイラ最適化を研究していた。
IBMで導入された「クリーンルーム」ソフトウェアエンジニアリング手法について、当時のIBMには必要なことだったが、膨大なプロセスがつらかったと複雑な思いを吐露している。ウォーターフォールのようなもの？
採用の時に見ていることは、夢中になれるものを持っているかとのこと。
農場育ちの人にはプログラミングに良い素養を持った人が多い。農場は自然を相手に入力と出力のあるシステムを扱う分野だからと。面白い意見。
IBMのリサーチ部門にはガラスの天井があった。プロセスがあり管理者層があり、女性の数や女性の地位が悪い方向に変わっていた。
コンピュータサイエンスが女性にアピールしないのは、一日中コンピュータの前に座りっぱなしのオタクがやることだと思われているからとの意見を披露。この辺り、プログラミング教育が盛んに叫ばれる2019年では味わい深い。

バーニー・コーセル

ARPANETシステム（インターネットの基礎となったネットワーク）の実装者。
プログラミングを独学する時はとにかくたくさんプログラミングを書くこと。ただ書くだけでなく、具体的な目的を持つ小さなプログラムを書いてみる。本当に効く。
マイクロマネジメントの真逆、好きなだけバカをやらせてもらうマネジメントスタイルをされた経験があり、あるレベルの信頼と信用を置いて放っておいてくれたフランク・ハートという人物を称賛している。
プログラムは読まれることを意図して書かれるべきで、Perlに「if」と「unless」が両方あるのは良いことだと述べている。
現代のコンピュータで起きた最大のセキュリティ問題はCだと授業で教えているとのこと。ケン・トンプソンの後にこの人のインタビューが出てくるのがニクい。Cの登場はシステムプログラミングにおいてはものすごい恩恵だったが、システムとアプリケーションの両方をCで書く必要はないとも。これは何となく理解できる。
Javaも正しくない、権威主義的過ぎるとのこと。この人はお気に入りの道具がPerlらしく、Cみたいに横着もできないしJavaのように堅苦しくないところが好きっぽい。

ドナルド・クヌース

『The Art of Computer Programming』シリーズの著者で、組版システムTeX の作者。
プログラミングを書くのは本を書くよりも難しい。本を書くのにどれくらい見積もるのは困難で、プログラミングを書く作業量を見積もるのはそれ以上に困難であるとも。
「再利用可能性」が過大に評価されている点を辛辣に批判している。ブラックボックスなライブラリを組み合わせて何かを作るのは楽しくないとのこと。2019年現在、この傾向はどんどん進んでいるように感じるなぁ。
C言語におけるポインタの使用は革命だったと述べている。一方で、すでにお気に入りではなくなったとも。

[ツッコミを入れる]