- Cプログラムは動く。Cプログラムはクラッシュする。Cプログラマは燃え尽きる。
- デバッグという作業がバグを取り除くことなら、プログラミングとはバグを注入する作業に違いない --- ダイクストラ
- "#define QUESTION （（bb) ｜｜ !(bb）） --- シェークスピア
- もしどうにもうまく行かなかったら、それをバージョン1.0と呼べ。
- メンテナンス・フリー： 壊れたとき、直せないこと
- コンピュータは考えることが出来るか、という質問は、潜水艦が泳げるかという質問と同じである。
- 「再帰」を定義するには、我々は最初に「再帰」を定義しなければならない。
- 良質なプログラミングは、99%の汗と1%のコーヒーで成り立っている
■自分の足を撃つには
C:自分の足を撃て。
C++:間違って自分自身のインスタンスを一ダースも作ってしまい、全部の足を撃つことになる。救急治療は困難である、なぜなら、どれが本物の自分でどれがビットワイズコピーで、どれが単なるポインタのくせに「ここだよ助けてよ～」と叫んでいるのか、さっぱり分からないからである。
Basic：水鉄砲で足を撃つようなもの。
アセンブリ言語：銃を書き終えるまでにあなたは死んでしまっているので、自分の足を撃つ心配はしなくても良い。
80x86アセンブリ：銃が足と同じセグメントにないので、足を撃つことは出来ない。
FORTRAN：繰り返して自分のつま先を撃つ、つま先がなくなってしまうまで。 そしたら、次の足を読み込んでまた繰り返す。 もし弾がなくなってしまっても、とにかく繰り返す。 なぜなら、例外ハンドリングルーチンを持たないから。
Visual BASIC：自分の足を撃つ。 しかし、そうしているのが実に楽しいため、あなたは全く気にしない。
Prolog：あなたは、自分の足を撃とうとする。 しかし弾は目標を見失ってしまい、銃へバックトラック。 あなたの顔面で爆発する。
シェル (sh, csh...)：全く文法が覚えられないので、man page を読むのに五時間費やすが、とうとうあきらめる。 そしてコンピュータを銃で撃って、C に切り替える。
■ペットショップにて
とある旅行者がシリコンヴァレーのペットショップをのぞいていると、別の客が入ってきて店員にこういった。
「Cモンキーを一匹お願いします」
店員はうなずくと、棚のかごから猿を一匹取り出した。店員は、首輪とひもを猿に付けると、お客に渡した。
「５０万円です」
客は金を支払うと、猿を連れて出ていった。 びっくりした旅行者は、店員にたずねた。
「そりゃまたえらく値の張る猿ですねぇ。普通猿は数万円ぐらいのものでしょう。なぜそんなに高いのですか」
店員は答えた。
「あの猿は、C言語でコードが書けるんです。非常に早く、タイトでバグなしのをね。値段に見合うと思いますよ」
旅行者は、かごに入った猿をしみじみと見始めると、店員にこう言った。
「この猿は、さらに高いじゃないか。１００万円！こいつは何ができるんだい」
店員は答えた。
「その猿は、C++モンキーです。オブジェクト指向プログラミングができて、C++やJavaまで使えます。かなり使えるやつですよ」
旅行者はさらに周りを見渡し、かごを一人占めしている３つめの猿を見つけた。 その猿には、なんと５００万円の値札が付いていた。 彼は、あえぎながら店員に聞いた。
「この猿は、他の猿を全部合わせたよりも高いじゃないか。こいつは、一体全体、何ができるんだい」
「えーとですね」
店員は答えた。
「こいつに何が出来るか、実は私も知らないんですよ。こいつは"管理職"と呼ばれてますがね」
■車の故障
ソフトウェアエンジニア、ハードウェアエンジニア、マネージャの3人が、スイスでの会議へ出席するため車で険しい山道を下っていた。ところが、突然ブレーキが故障してしまった。 車はほとんど制御不能になり、道から落ちそうになったりガードレールに跳ね返ったりしたが、奇跡的に山肌に側面をこすりながら停止した。車に乗っていた3人は、震えてはいたものの幸い怪我はなかった。ただ、問題が 一つあった。彼らは、険しい山の中腹でブレーキのない車の中で立ち往生してしまったのだ。さて、どうする？
「よし」 とマネージャが言った。
「会議を開いて、ヴィジョンを決定し、ミッションステートメントを確立し、ゴールを設定、そして絶え間ない改良によって、このクリティカルな問題に付いてのソリューションを見つけよう。それで問題は解決だ」
「駄目駄目」 とハードウェアエンジニアが言った。
「それじゃ時間がかかりすぎるし、そのやり方がうまくいった試しがない。 ここにスイスアーミーナイフがあるから、すぐに車のブレーキングシステムを全部ばらせるさ。それで欠陥を見つけて直せば、大丈夫」
「えーと」 とソフトウェアエンジニアが言った。
「他のことをやる前に、また車を走らせて再現するかどうか試してみるべきじゃないかな」
■プログラムが動かないときの、プログラマの言い訳ベスト20
２０ それは妙だ…
１９ その操作は、誰も試したことがなかったんだよ
１８ 昨日は動いたよ
１７ そんなはずないよ
１６ ハードウェアの問題に違いない
１５ クラッシュしたときに、何かタイプミスしなかった？
１４ 君のデータの方がおかしいんだよ
１３ そこのコードは、もう何週間も触ってないよ
１２ 君の使っているのは、変なバージョンのやつだろ？
１１ 単に不運な偶然が重なっただけだ
１０ そんなに全部のことをテストできるわけないじゃないか
９ これがあれの原因であるわけがない("THIS can't be the source of THAT.")
８ それはちゃんと動くんだけど、いままでテストされてなかっただけなんだ
７ 誰かが私のコードをいじったに違いない！
６ ウィルスのチェックをちゃんとしたかい？
５ 仮にそれがちゃんと動かなかったとしても、何かまずいことがあるかい？
４ 君のOSで、そのバージョンを使ってはいけないんだよ
３ 君の使い方が悪い。何故君のそのやり方で使わなきゃならないんだ？
２ プログラムが壊れたとき、君はどこにいたんだ？
そして、プログラムが動かないときのプログラマの言い訳ナンバー１は：
「私のマシンではちゃんと動くよ」
■給料の法則
ディルバートの「給料の法則」は、以下のことに言及している。
「エンジニアと科学者は、ビジネス エグゼクティブやセールスの人々ほど稼ぐことが出来ない」
この法則が成り立つことは、誰しもが真であると認める次の二つの仮定から導き出された方程式により、証明された。 以下にその解を示す。
仮定1: 知識は力なり
仮定2: 時は金なり
すべてのエンジニアと科学者が知っての通り、次の等式が成り立つ。
力 = 仕事 / 時間
しかるに： 知識 = 力 かつ 時 = 金
よって： 知識 = 仕事 / 金
これを金について解くと、次の式が得られる。
金 = 仕事 / 知識
したがって、知識が0に近づくにつれ、なされた仕事に関わらず、金は無限大に近づいていく。
結論：知っていることが少なければ少ないほど、より給料が増える
