『Coders at Work』ガイ・スティールの章
お次はガイ・スティール
自分的にはScheme(またはlambda)の人であとCommon Lispとか
ECMAScriptとか言語の標準化によく出てくる人っていうイメージ
やはり興味深いところが多すぎて困る
標準化
これを後押ししていたもう1つの要素は、Maclispがほかのオペレーティングシステムに移植されるようになっていたことです。どこもPDP-10オペレーティングシステムの独自の変種を使っていました。顧客を全部調べると、サポートしなければならない異なるオペレーティングシステムが半ダースほどあるのがわかりました。
たとえば「ファイル名変更」関数といっても、ファイル名を変えるためにオペレーティングシステムとやり取りする方法は、6つのオペレーティングシステムの間でかなり違っていたからです。
このへんからすでに始まっている感じがする
――― MIT時代にEmacsの誕生にかかわっていますね。
私から見たバージョンは、私が標準化の役割を果たしたということです。
そうなんだ・・・ここでも!?
歴史だな
文字に対してテーブルルックアップをしてTECOコマンドを実行させるというアイデアをリアルタイム編集モードに適用したらどうかということになったのです。
キーマップの始まりか(TECOというのはEmacsのもとになった?エディタ)
すぐに起きたのは、MIT周辺にいた4、5人の頭のいい人間が、それで何をするかという独自のアイデアを考えついたということです。ほんの数ヶ月のうちに、まったく互換性のないTECOのGUIが5つ現れました。
何にせよ異なるマクロパッケージが4つばかりあって、互換性がありませんでした。それで私は標準化役というかコミュニティの調停役をすることにしたのです。
結局そういうのが好きなんですね?
私はヒューマンファクタの専門家でも何でもないので、タッチタイプにおける利便性はまったく考えていませんでした。私が主に気にかけていたのは覚えやすいかということでした。
タイムマシンでここに戻って、npbfをesdfかhjklに変えてきていただきたい
TAOCP
TAOCPが大好きらしい
――― プログラミングを学んでいたときに重要だった本は何かありますか?
70年代には間違いなくクヌースの『The Art of Computer Programming』です。
これは、自分が○○歳のときには、という意味だろうか
それとも、70年代のプログラミング界では、という意味だろうか
――― 隅から隅まで読んだんですか?
ええ、隅から隅までというのにかなり近いです。
この本に出てくる人のなかでも、全部読んだというのは少数派っぽいです
クヌースはコードについてのストーリーを語るのが実に巧みです。『The Art of Computer Programming』を読み進め、1つのアルゴリズムを読んでいくなら、彼はそれを説明し、いくつかの応用を示し、練習問題をいくつか出して、読者に報われる旅をしたと感じさせてくれるのです。そしてその過程でたくさんの興味深い光景を目にすることになります。
レジェンドにレジェンド扱いされるクヌース先生すごすぎる
文芸的プログラミングとTeXのコード
文芸的プログラミングとTeXのコードも好きらしい
クヌースLOVE
どちらの場合も答えは15分もせずに見つかりました。“TeX: The Program”が非常によく書かれ、クロスリファレンスがつけられていたからです。このこと自体目を開かれるような体験でした。プログラムというのは、このようによく組織化し、よくドキュメントをつけ、何かを素早く見つけられるようにできるものなのだと驚いたものです。
そこから学んだもう1つのことは、プログラミングの達人がデータ構造やコードをいかに組織化し、読みやすいものにしているかということです。クヌースは非常に注意して“TeX: The Program”を構成しており、ほとんど小説か何かのように読んでいくことができます。
そんな本があったのか
つまりこれが文芸的プログラミングの最高峰ってことだよな
読んでみたい
ここにPDFがあるけど、大丈夫なやつだよな・・・?
プログラムの順番
プログラムをどう並べるかについて
気にはするけど答えはでないんだよなー
プログラムの全体を本当に理解する必要があるときには、腰を据えて全体を通して読もうとします。しかしこれはそのプログラムがどのように構成されているかの枠組みが頭に入っていないとできません。運が良ければ、プログラマが何かのドキュメントを残していたり、適切に名前付けをしていたり、ファイルの中で適切な順序で書いていて、通して読むことができるようになっているでしょう。
大ざっぱな方針としてはだいたい呼び出される方が上、呼び出すほうが
下になるように書いてることが多いけど
クヌース先生は必要になった順って言ってたし
ライブラリ的なものだとインタフェースになるものを上に持って来たくなったりするし
単純な一本道ではないから難しい
結果として、Pascalプログラムを読む最良の方法は後ろ向きに読むことで、そうするとプログラムをトップダウンに見ることができるのです。
自分のやり方も許されているようでよかったよかった
今の言語はもっと自由形式になっているので、理解しやすくコードを配置しようとする際のプログラマの優れたセンス以外に、当てにできるものはありません。
厳しい
けど
今では優れたIDEがあってクロスリファレンスできるので、ファイルの中の順序というのはそんなに問題ではなくなっているのかもしれません。
確かに
プログラム一般
――― プログラミングについての考え方で、当時と今とで一番変わったことはなんですか?
最大の変化は、最近ではコンピュータの中で起きていることをすべて理解することはできなくなったということでしょう。まったく手の届かない領域があり、あらゆるソフトウェアについてすべてを知ることはできません。
サスマン先生も同じことを言っていたけれどもふたりで
そういう会話でもしてたのかな
元ネタがなくなってたので代わりに掲示板を置いておく
Programming by poking: why MIT stopped teaching SICP
――― 実装すること以外に、インタフェースの良し悪しを判断する方法はありますか?
私は普通一般性と直交性を考えます。それと一般に受容されているやり方に従っているかどうかも。
インタフェースを書くほうが実装するより好きらしい
なんか最近自分もインタフェースが大事かなという気はしてきている
私は境界ケースを気にかけて多くの時間を費やしてきました。これは私がトレンチャード・モアと彼のAPLのための配列の理論から学んだことです。彼の論点は境界ケースについて気をつけていれば、中間の場合は自ずと片付くというものです。
私の論点は、端っこや隅っこをキレイにすれば、部屋のまんなかへんは
自然にきれいになるというものです(掃除
つながってるんです!(言い張る
デバッグ・テスト
――― 真夜中に目を冷まして問題が何か気づくということがなかった場合に、あなたが好んで使うデバッグテクニックはなんですか?シンボリックデバッガか、print文か、アサーションか、形式的照明か、あるいはその全部でしょうか?
私は怠け者であることを認めなければなりません。私が最初に試すのは、print文を突っ込んで何かわかるかどうかやってみるということです。
謝ってるけど、print文デバッグはレジェンドたちの中でもかなりポピュラー
一方で、私のプログラミングに対する考え方の発展の中で大きな転換は、あるHaskellで開発するプロジェクトに取り組んでいたときに得られました。Haskellは純粋関数型言語なので、print文をただ突っ込むというわけにはいかなかったのです。
それでユニットテストの世界に100パーセント浸ることを強いられました。それぞれの手続きにユニットテストをつけていきました。そしてそれが非常に良い方法だということがわかりました。
あとEiffelの「契約による設計」からアイデアをもらったりとかしたらしい
ガイ・スティールも変わるってことだ
One Language Every Yearてやつだな