Coders at Work プログラミングの技をめぐる探求の紹介の後半です。
心に残ったひとことの引用と、それに対する個人的な感想を書きます。引用は手動で書き写しているので書き間違いがあるかもしれません。何か変だったら前後から類推するか本を当たってください。
ジョー・アームストロング
今から思うとおかしいのは、現代的な小道具というのはどれも、実際にはより生産的にしてくれるものではないことです。(略)ソフトウェア開発の大部分はどのみち頭の中で行われるのです。(略)それから今日では選択の重荷が大きすぎると思います。(略)昔は選択による麻痺状態なんていうものはありませんでした。単に始めるだけのことで、言語やなんかに何を使うかという選択は、すでになされていたのです。どれにするかと考えることはなく、ただやり始めれば良かったのです。
Erlang作者のジョー・アームストロング氏の懐古主義な感想です。わからないでもないです。
うまくいかないことが何かといえばソフトウェア再利用です。あきれるくらいひどい状態です。
次の次の引用に話が続きます。
長い間私は包括的な誤りを犯していました。その包括的な誤りとは、ブラックボックスを開けないということです。(略)抽象化の境界というのは容易に通り抜けることができ、中に入るとたくさんの恩恵が得られるのです。(略)初心者プログラマがそういった抽象化をすべて開いて見るべきだとは言いません。しかし言っておきたいのは、少なくともそれを開ける可能性について考えてみるべきだということです。
御意。
再利用性の欠如はオブジェクト指向言語から来るもので、関数型言語では話が違います。オブジェクト指向言語の問題は、それが周りに引きずっている暗黙の環境にあります。
個人的にあまり納得はできません。
暗黙の環境を多く引きずるほど再利用性が低いのは同意しますが、オブジェクト指向言語だと暗黙の環境を引きずる、とまでは言えないと思うからです。JavaのPOJOなどを見れば、やりようはあると思います。
–コードを書き始めるときはトップダウンですか、ボトムアップですか? それとも真ん中から?
ボトムアップです。少し書いてはテストし、少し書いてはテストします。私は今ではテストケースを先に書くようになりました。
ボトムアップのようです。興味深い回答です。
–C++はやらないんですか?
ええ、C++は満足に読めも書けもしません。C++は嫌いなんです。何か間違っているように感じます。複雑すぎます。私は小さくてシンプルな言語が好きなんです。C++は小さくもなければシンプルでもありません。
本書に繰り返し出てくるC++嫌いですが、Erlang作者からもダメ出しされてしまいました。
–デバッグで使うテクニックは何ですか? print文ですか?
print文です。プログラミングの偉い神様が言っています。「汝プログラムの間違っていると思われる部分にprint文を置きて再コンパイルし実行せよ」(略)「ジョーのデバッグの法則」というのがあります。それは、すべてのバグは最後にプログラムを修正した箇所からプラスマイナス3ステートメント以内にある、というものです。
print文デバッグの有用性は否定しませんが、こんなに威張って言えるのはジョー・アームストロング氏が大物だからでしょう。
私は仕様書がとても好きです。「必要ないでしょ? コードを読んでよ」という人たちはプロとはいえないと思います。コードは何をするかは示しますが、何を意図しているかは教えてくれません。コードというのは問題に対する答えなのです。仕様書やドキュメンテーションがないとしたら、答えから問題を予想する必要があります。そして間違った予想をすることだってあるのです。私は問題が何なのか言ってもらったほうがありがたいですね。
ここまでドキュメンテーションに重きを置く姿勢は、本書でインタビューされた人の中でも珍しい部類です。
「コードは答えなので問題が何かを示せ」というフレーズは、ドキュメント嫌いのプログラマにドキュメントを書かせるときに使えるかもしれません。
–プログラミングと直接関係はないスキルで、プログラミングを上達させてくれたとか、プログラマとして持っていて貴重だと感じるものは何かありますか?
文章ですね。コンピュータサイエンティストの誰かが、「ところで、もし国語がうまく使えないなら、決して良いプログラマにはなれないからね」と言っています。
ミスター弓立も同じことを言っていました。
–その他に良いプログラマの特徴はありますか?
ちゃんとしたプログラマになるためには、良い記憶力が必要だと何かで読んだことがあります。これはその通りだと思います。
まあ、そうかもしれません。
サイモン・ペイトン・ジョーンズ
「関数型言語でUML図に相当するのは何ですか?」とよく聞かれます。私の思いつく一番良い答えは型システムです。オブジェクト指向プログラマが絵を描くところで、私は型のシグネチャを書きます。
Haskell作者のサイモン・ペイトン・ジョーンズ氏です。
個人的にこの回答は理解できません。理解できないとは異論があるという意味ではなく、文字どおり理解できません。図示が理解の助けになると思っているからです。図示に頼る自分は、オブジェクト指向に毒されているのでしょうか。そうは思いません。図での理解はオブジェクト指向と無関係に重要と思っているからです。
私のデフォルトは非常に一般的なものはそもそも書かないということです。私は自分のプログラムをできるだけ美しいものにしようとはしますが、必ずしも一般的にしようとはしません。これは違うことです。私はプログラムを、手にしているタスクを実行できる、可能な限り明快で分かりやすいものにしようと努めます。
コードの汎用度や抽象度の高さよりも、小さくて明解であることに重きを置く姿勢は興味深く感じます。
関数プログラムをどのようにデバッグするかというのは、ここのところしばらく関心を集める研究テーマになっています。(略)これは私が安全でないprintfによる甚だ未熟なデバッグテクニックを使うことへの、逃げ口上になっていたわけです。(略)良いデバッグ環境の重用性を過小評価したりけなしたりするつもりはありません。(略)現実世界はとてもごちゃごちゃしており、ツール的なサポートは重要だろうと思います。
私は大きなことを学ばなければならないのが嫌いなのです。大きくてぐちゃぐちゃしたものからは、本能的に身を離します。しかし同時にそれが実用的には有用で重要であることも認めています。私にとっての疑問は、そういったものの設計にもう少し時間をかければ、もっと小さく、複雑でなく、行き当たりばったりでないやり方で設計することはできなかったのかということです。
インタビューを読むと、美しい言語への志向はありつつも、現実への理解も感じます。ブレンダン・アイク氏が極小のサブセットでプログラムを書くべきと考える人を批判していますが、サイモン・ペイトン・ジョーンズ氏はその批判される側にはいないようです。
ピーター・ノーヴィグ
–業界で働こうと思う人たちのために、コードを書くこと以外で必要な、伸ばしておくべきスキルは何でしょうか?
人とうまくやっていくというのが中心的なことだと思います。
大人な回答です。jwzであれば、人とうまくやろうなんて考えている暇があればコードを書け、と言いそうです。
プログラミングの大きな部分は可能な限り多くのことを頭の中に入れる能力にかかっていますが、それには限界があります。少なくとも私の頭には。そうするとほかの人たちに依存する必要が出てきて、適切な抽象化をして人の作ったものを使えるようにする必要があります。
本書でインタビューされる人の中では、ジョシュア・ブロック氏に近いエンジニアリング志向を示す発言です。
テスト駆動設計というのは素晴らしいものです。私も以前よりずっと使うようになりました。しかし何でもテストできたとしても、問題へのアプローチの仕方が分からなければ、解にたどり着くことはできないのです。
この発言につながる話は実に秀逸です。単体テストを順々にパスするように書き進めたらボトムアップ的にコードができあがるというテスト駆動開発でありがちなエピソードを叩き斬る話です。そんなアプローチで書けるコードはそもそも簡単なコードで、書く前からおおよそどう書くかの全体像が頭にあるんだろうという見解です。テスト駆動開発信者はぜひ読んでみるべきです。
「我々がここにいるのは最も意味のあるソリューションを提供するためだ。完璧なソリューションはどこかにあったとしても、それはおそらくコストに見合わない」と考えます。「今一番重要なことをやろう」と言い、それはあきらめるのです。(略)ドイツの諺に、「完璧は良さの敵」というのがあります。(略)実践的なエンジニアはみんなこの教訓を学ぶ必要があります。
–どうして抱えてもいない問題を解こうとしたくなるんでしょうね?
賢くありたい、完全でありたいと思うのでしょう。何かを完成させてから別なものに進みたいと思うのでしょう。人は一度に一定量のものしか扱えないので、「これはもう完璧にやった。だから頭からのけて先に進むことができる」と言いたいのです。しかし完璧にやることの投資利益率を計算する必要があります。それはいつもS字型の曲線になっていて、80から90パーセントまでいくと、投資に対するリターンは逓減していきます。
これらの発言につながる話も秀逸です。簡単に言うとソフトウェア開発における収穫逓減の話です。残り10%の完璧さを目指すために多大のコストをかける姿勢を批判します。まったくそのとおりです。この罠は本当に危険です。「完璧は良さの敵」というフレーズは使えそうです。
ガイ・スティール
–自分が書いたのではない大きなコードの山には、どのようにアプローチしますか?
使い方は知っているけど中身は知らないソフトウェアの場合は、特定のコマンドや操作を1つ選んで、それをたどっていくことがよくあります。
ここではトップダウンともボトムアップとも言いませんが、各論から入って抽象化する姿勢(帰納的な発想)がうかがえます。
プログラムの全体を本当に理解する必要があるときには、腰を据えて全体を通して読もうとします。しかしこれはそのプログラムがどのように構成されているかの枠組みが頭に入っていないとできません。運が良ければ、プログラマが何かのドキュメントを残していたり、適切に名前づけをしていたり、ファイルの中で適切な順序で書いていて、通して読むことができるようになっているでしょう。
トップダウンの理解の必要性を述べています。
–コードを書くときには、低レベルの関数からではなく、高レベルの関数からトップダウンに構成していくんですか?
私は高レベルのアイディアを提示しようと努めます。
上に同じく、トップダウンのアプローチをうかがわせます。
–Javaのような言語で仕事するときには、設計をインターフェースから取りかかるのですか?
ええ。昔よりインターフェース指向になりました。実装コードのない、メソッドの入力とアクションと出力についての記述です。(略)インターフェースを設計しているときには、実装がどのようなものになるかイメージを持っているべきです。少なくとも実装のためのアイディアは必要です。
ここにも、トップダウンのアプローチが見られます。
あらゆる面で優れた言語を作るというのは本当に難しく、それはある部分では簡潔な記法がそうたくさんはないためです。ハフマン符号の問題です。
(略)
–その問題を解決するためにLispが取った方法は、あらゆることを一様に半簡潔にするということでした。この一様性によって、ユーザが言語に自分で一様に半簡潔なファーストクラスの構文上の拡張を導入できるという利点が得られますが、S式の構文に抵抗を持っている人もたくさんいます。(略)あなた自身は、「みんな本当にLispを理解すればカッコを嫌うなんてことはなくなる」と思う、高慢なLisp屋なのでしょうか。
いいえ、私は高慢な見方はしていないつもりです。
ただひとつのプログラミング言語があらゆる用途に渡って最適になることはない、という見解を話したガイ・スティール氏に対して、Lispは例外ではないか、と問いかける対話です。ふたりともLispの世界の偉人であることを指摘しておきます。
Perlは批判できるほど本格的に使ったと言えるか分かりませんが、この言語には引かれませんでした。C++も引かれませんでした。C++のほうは結構書いていますが。(略)しかし私はビョーン・ストラウストラップの努力に対する批判者とは見られたくありません。(略)Cの型システムは根本的に壊れていますから。
本書で何人目かわからないほどのC++嫌い発言ですが、ストラウストラップ氏に配慮してC++ではなくCに責任転嫁しました。
–あなたが好んで使うデバッグテクニックは何ですか? シンボリックデバッガか、print文か、アサーションか、形式的証明か、あるいはその全部でしょうか?
私は怠け者であることを認めなければなりません。私が最初に試すのは、print文を突っ込んで何か分かるかやってみるということです。(略)一方で、私のプログラミングに対する考え方の発展の中で大きな転機は、あるHaskellで開発するプロジェクトに取り組んでいたときに得られました。Haskellは純粋関数型言語なので、print文をだた突っ込むというわけにはいかなかったのです。それでユニットテストの世界に100パーセント浸ることを強いられました。
この発言と、サイモン・ペイトン・ジョーンズ氏(Haskell作者)がprint文デバッグを告白する発言(上記参照)がなんとも興味深い部分です。
ダン・インガルス
–Smalltalkの別な側面として、アラン・ケイが最近特に強調しているのは、それがオブジェクトの話ではなかったということです。重要なのはメッセージパッシングだと言っています。(略)それがどうしてそんなに中心的なアイディアだと言うのでしょう?
それは本当の分離をもたらしてくれるからです。アランの最近の言い方だと、これは適切なものだと思いますが、ずっと下までインターネットのようであるべきだということです。
昔書いた話のことだと思います。
クヌースがTEXに取り組んだ方法を見ると、すごく数学的で、美しくエレガントです。それと比べて、Smalltalkの最初のエンジンはまったく場当たり的でした。ただ必要なものをまとめただけです。
クヌース先生の前ではみんな大人しくなります。
–優れた技術的リーダーになるための秘訣みたいなものはありますか?
第一に、何をしようとしているのかについて明確であること。明確なビジョンを得るのが仕事です。(略)彼らが自分の担当部分をどのようにやるか自由にさせておくことができます。必要なところにだけ立ち入ってマイクロマネジメントすればいいのです。
大人です。
–Smalltalkの素敵な環境を使って開発するときにはシンボリックデバッガを使っていると思うのですが、print文に頼ることはありますか?
優れたデバッガという選択肢があるときにそのようなことをする人が果たしているのかと思いますね。どこにprint文を入れるんですか?(略)最近はprint文スタイルのデバッグを随分やるようになりました。それというのも、JavaScriptだと十分優れたデバッガがない場合がよくあるからです。
本書では様々な人にデバッグ方法を質問する場面があります。時代もあるかもしれませんが、ほとんどの人がprint文デバッグを告白します。ダン・インガルス氏は例外的にprint文デバッグは時代遅れと言い切ります。もっともJavaScriptへの皮肉も忘れていませんが。
型というのは実質的にプログラムに関するアサーションです。私は物事を可能な限りシンプルにすることに価値を置いていて、型が何かをあえて言わないというのもその一部です。(略)アサーションは非常に役に立ちます。
ぜひ、ジョシュア・ブロック氏の静的型付け支持の発言と比べてください。個人的には、ジョシュア・ブロック氏に共感します。
–コードリーディングについてですが、初めて見るコードにはどのように取り組みますか?
(略)それが何をするのか分かっているところから出発するとしましょう。私はたぶんトップダウンでいくと思います。それぞれの部分が何で、どのように連携するのかを理解しようとします。
トップダウンだそうです。
L・ピーター・ドイチュ
分かっているのは、ソフトウェアが基礎的な部分へと下りていくほど、非常に優れた人間によって作られていることがより重要になるということです。エリート主義的な見方かもしれませんが、私はそう思っています。
御意。
我々の持つ基本的にすべてのプログラミング言語の世界が、我々の感覚や脳や社会がそれを扱うよう共進化してきた物理的な世界と、非常に根本的に異なっているということです。だから人々がそれをうまくやれると期待するのはそもそも馬鹿げているのです。本当に良いプログラマになれるというのは、どこかちょっとおかしいところがあるはずです。「おかしい」というのは言い過ぎかもしれませんが、人を人間として良く機能させる資質と、人をプログラマとして非常に優れたものにする資質とは、重なる部分があまりないのです。
言いたい放題です。本書の中ではjwzに準ずる過激派です。
始めからやり直す必要があるでしょう。ポインタの概念を持った言語をすべて捨てることです。現実の世界にはポインタのようなものはないのですから。
ここでのポインタとはCの生のポインタ批判ではなく、参照のような言語機能を含めた広義の意味でのポインタを批判しています。言外に、値だけを扱うプログラミング(狭義の関数型プログラミング)をほのめかしているのだと思います。
非常に良いプログラマであり、良い設計者だったと思います。しかしシステム思考者ではなかったのです。変更が及ぼす影響や帰結という考え方に慣れていないだけでなく、それが必須な問であるという認識も欠いているようでした。私から見ると、大規模設計をするときに問わなければならない質問を理解している人と、どういう理由でかそういう質問がよく分からない人の間にはっきりした違いがあります。
システム思考者ではなかったあるプログラマのエピソードから上記発言につながります。コードが書けることとシステム思考は、確かに、必ずしも両立するとは限らないと思います。
エリート主義的に聞こえるかもしれませんが、プログラミングをすべきなのは記号の世界にいて快適に感じる人です。記号の世界を飛び回っているのがすごく快適に感じるのでなければ、その人はプログラミングをすべきではないのかもしれません。
またまた言いたい放題ですが、わかるような気がします。
もはやLispでプログラムを書かなくなったのは、あのシンタックスに我慢できなくなったからです。シンタックスが重要だというのは紛れもない人生の真実です。
本書の中でLispを真っ向から批判する人はL・ピーター・ドイチュ氏ぐらいでしょうか。シンタックスが重要というのは個人的には同意見です。
ラリー・ウォールが言語設計について語るというのもいい神経です。Perlは言語として醜悪です。
まさに言いたい放題…
ケン・トンプソン
計算の理論の基礎がちょうど現れたころです。シェルソートが現れ、それがnの2乗ソートよりも速い理由が誰にも分かりませんでした。それでみんな実験して解明しようとしていました。
こんな時代があったのか、という軽い驚きがあります。
–ソフトウェアはどのように設計しますか? グラフ用紙に落書きするのか、UMLツールを立ち上げるのか、ただコードを書き始めるのか?
どれくらい大きいのかによりますね。多くの場合、しばらくの間は頭の中に収まっていて、紙には何も書きません。そして難しい部分に集中します。簡単な部分は自然に消えます。(略)ある時点で、断片が底から落ち始め、その断片からピラミッドが出来上がっていくのを目にします。頭の中でピラミッドが十分な高さになったら、下から手をつけ始めます。
ブレンダン・アイク氏のゲシュタルトなプロセスの発言に通じます。
私は一番下を見、階層を想像すること、そのオペコードの下で何が効率的で何が効率的でないかをイメージすることができます。(略)現代的なプログラミングはいろいろな面で私をおびえさせます。変換以外の何もしない階層を何層も何層もひたすら積み重ねています。トップダウンに読まなきゃいけないプログラムというのは私を混乱させます。(略)ただ深いところへ深いところへ問題を先送りしているだけです。私はそういうのを頭に入れることができません。理解できないのです。(略)しかしただコードの塊を渡されて「これを読んで改良しろ」とか「別なことをするように変えろ」と言われたなら、通常トップダウンで読みます。
わかります。一方、現代に生きる我々は現代的なプログラミングに適応する必要があります。
–コードを書き始める前に何か書くことはありますか?
コードを書く前に通常データ構造を書き出します。
(略)
–Cのプログラムを書く場合、そのデータ構造の定義はCのコードということになるんでしょうか?
いいえ。箱と矢印です。
やはり図です。サイモン・ペイトン・ジョーンズ氏の発言と比較すると興味深い話です。
それから私はボトムアップのドキュメンテーションを好みます。
(略)
–では書くのと同じようにコードをボトムアップで理解するのですね?
ええ。それが頭の中で把握し、記憶するための方法です。
ケン・トンプソン氏はボトムアップで理解する派のようです。
–デバッグするときには、どんなツールを使いますか?
ほとんどの場合値をprintするだけです。
ケン・トンプソン氏はprint文デバッグ派のようです。
コンパイラは最悪です。GCCが出すコードを見てご覧なさい。ひどいもんです。本当にひどい。しかも遅いし。
GCCが何より遅いかと言うと、手で書いたアセンブリ言語との比較です。
–今なら、C++が良い言語か悪い言語かおっしゃることはできますか?
間違いなく良いところはあります。しかし全体としては悪い言語だと思います。
本書では珍しく少しC++を褒めてくれました。総論としてはダメ出しですが。
–私がクヌースにインタビューしたとき、彼は技術的な文章のコツは、すべてを2度、補い合うように書くことだと言っていました。だから彼はそれを文芸的プログラミングのバグではなく機能だと考えているわけです。
2つの方法があるなら、一方が本当であり、それはマシンが実行するほうです。もう一方は本当ではありません。一方が他方よりも極端に簡潔であるのでない限り、それに価値はありません。(略)アルゴリズムの微細な記述をしようとし、それを1つはプログラミング言語で、もう1つは文章でしようとするのは、クヌースにはできるのでしょうが、私にはできません。
本書でインタビューされる人たちで、ドキュメントに関する見解の別れ方はとてもおもしろい部分です。「クヌースにはできますが、私にはできません」は、ドキュメントを書きたくないプログラマが使えるフレーズです。
フラン・アレン
–コードはどのように読みますか?
(略)
私は通常直感が働くか、あるいはそのソリューションの構造がどうなっているかあらかじめ知っていて、真ん中あたりから始めて核になる部分を探します。
これも、ブレンダン・アイク氏のゲシュタルトなプロセスの発言に近いかもしれません。
–少なくともIBM360プロジェクトに関しては、ソフトウェア開発プロセスを持ち込んだことでプロジェクトが救われたと感じているわけですね?
まったく必要なことでした。しかしソフトウェアの人たちにとっては、そういった人たちが入ってくるのは、ものすごく苦痛なことでした。ソフトウェアについて何も知らず、ただひたすら設計レビューや設計仕様といったものを要求してくるのですから。
–ではプロジェクトを救う助けになったわけですね。それがその人たちを勇気づけて、クリーンルームプロセスという次の段階へと進み、行きすぎることになったのでしょうか?
ええ、そう思います。
(略)
私たちソフトウェアの作りについてある程度経験のある人間たちには、彼らの主張はぎょっとするものでした。しかし何かを売り込もうと思ったら、時に大胆な主張をする必要もあるのでしょう。
この発言の前にブルックス(「人月の神話」)の話があって、ここにつながります。
–(略)技術的マネジメントの難しさの1つは、物事をどうやるべきかについて自分の考えを持つことと、みんなが自分のアイディアを入れられる余地を空けておくことの間で適切なバランスを取ることでしょう。
(略)2人やってきて、シンボルテーブルにハッシュを使いたいと言ったんです。私は「それはできないわ。どうやればいいのか分からないんだから」とか何とか答えました。次の月曜に出てきたら、彼らがもう作っていました。(略)うまく行ったし、ずっと速くなっていました。私には大きな教訓になりました。新しい考えに対してもっと心を開かなきゃいけないと。
(略)
下請け会社で働いていた人の1人がオブジェクト指向プログラミングを最近知って、それを究極まで適用してやろうと決めたんです。請負業者の監督は私の仕事だったんですが、彼を止めることができませんでした。そしてプロジェクトは頓挫しました。
示唆に富みます。自分の無知を知る必要もありますが、任せてうまく行く保証もありません。
若い人にすぐマネージャになろうとしないよう勧めるということです。そういう方向に才能のある人は引かれることでしょうが、まずは技術的な仕事で評判を確立することです。
(略)
–技術的に高いものを持っていないけどほかの人の力をまとめあげるのが上手な優れたマネージャというのはあり得るのでしょうか?
あり得るでしょう。自分が技術に優れていると勘違いをせず、部下の誰が優れていて誰がそうでないか見分けられるのであれば。
技術リーダーについての話が続きます。
1960年代までには、見事な言語のリストができていました。Lisp、APL、Fortran、COBOL、Algo60。Cよりも高級な言語です。Cが開発されて、私たちは大きく後退したのです。Cは自動最適化、自動並列化、高級言語からマシンへの自動的なマッピングといった私たちの能力を壊してしまいました。
こういう視点でのC言語批判は初めて読みました(低レイヤすぎるという批判はいくつも読んでいますが)。
–最近のもっと新しい言語はCよりも高級になっていますよね。JavaとかC#とかPythonとかRubyとか。
それでも依然として指定しすぎです。根本にある問題はデータの場所を指定するということです。ほかの言語を見てもらえば、データの場所や、それをどう動かすか、マシンのどこに置くかということまで指定しようとはしないのが分かるでしょう。どの時点でも、究極的には値が問題にされていたのです。
L・ピーター・ドイチュ氏の発言(「ポインタの概念を持った言語をすべて捨てることです」)とシンクロします。
–あなたが仕事を始めたころは、女性は詳細志向だから良いプログラマになると思われていました。最近では、ほかのことすべてをおろそかにしても何かに集中するという奇妙な能力のために、プログラマの大半が男性なのだと考えられています。
ええ。
興味深い話です。
バーニー・コーセル
–クヌースを通して読んだんですか?
当時はあれがホットだったんですよ。私が一番脂ののっていた時期でした。私たちはみんな新しい巻が出るごとに、頭を突っ込んで隅から隅まで読んでいました。
こんな時代があったようです。
プログラムは読まれることを意図しているということです。(略)ソースコードはコンピュータではなく人間のためのものだと思うようになりました。(略)反抗を示す人もいます。自分が優れたプログラマであることに絶対的な自信を持っていて、私を自分のやっていることが理解できないただの老いぼれだと思っています。私もそう遠くない昔に同じことを言っていたので分かります。「プログラムは動くだろ。何の問題があるんだ?」と。私が「プログラムが動くからって誉めてはもらえないぞ。我々が目指しているのはその次のレベルだ。プログラムが動くのは当然の条件だ」と言うと、彼らは驚きます。
「プログラムが動くのは当然の条件だ」って発言はクールです。今後、使わせてもらいます。
–コードの大きな山を前にしたとき、どのように取り組んでいたんですか?
(略)私はコードを本のようには読みません。そのプログラムが何をしているか解明しようと、トップダウンでコードのヒントを見つけようとします。プログラムを読むのと並行して、自分ならその問題をどう解くかを考えます。
トップダウンに理解するようです。自分ならどう書くかという視点でコードリーディングするのは新鮮な意見です(自分でも無意識にやっていたかもしれませんが)。
–リファクタリングについて聞かれたことはありますか?
いいえ。何ですかそれ?
–あなたが今ちょうど説明したことです。
バーニー・コーセル氏ほど大物になると、「リファクタリング」という用語を知らなくても堂々としたものです。
彼(注:ケン・トンプソン)と剣を交わすのは気が進みませんが、私のコンピュータセキュリティの授業では、現代のコンピュータで起きた最大のセキュリティ問題はCだと教えています。
仕方ありません。
Javaは正しくない感じがします。私の古い反射神経がそう言っています。Javaは権威主義的すぎます。これはPerlが良いと感じられる理由の1つです。(略)私が最初にJavaをいじったとき、まだ小さな言語だったときのことですが、「ああ、これはまた例によって、あんまりできのよくないプログラマを助けようと、できることを制限してまっすぐな細い道を歩かせる言語だな」と思いました。しかし私たちはそういうのが正しい地点に来ているのかもしれません。
Java批判です。一方で、必要悪として認める冷静さもあります。
ドナルド・クヌース
TEXを開発している間に膨大なことを学びました。学んだことの1つは、ソフトウェアが脳のどれほど大きな部分を占めるかということです。(略)ソフトウェアが私の頭の大部分を満たしてしまい、ほかのことが追い出されることになりました。
指摘したのが誰だったのか確信がありませんが(略)「スーパープログラマとして生まれついた人間は世界の人口の2パーセント足らずであり、スーパーライターとして生まれついた人間は世界の人口の2パーセント足らずだ。クヌースはみんなにその両方であることを求めている」
–不変条件や様々なアサーションに関して、ダイクストラのような人たちは、プログラムのステップごとに非常にフォーマルなアサーションをつけ、プログラムの正しさを証明できるようにすべきだと言っています。(略)フォーマルにプログラムの正しさを証明すべきだという考えに対してはどのように思いますか?
1つには何かを証明するということの不可能性があります。(略)正しいと信じる理由が増えはするかもしれませんが、決してループから出られはせず、それは理論的に不可能なのです。
最近のコメント