実際の引用はこうだと思うよ: 「フローチャートを見せて、テーブルを隠せば、私はずっと混乱するだろう。テーブルを見せてくれれば、フローチャートは必要ない。明らかだから。」 -- フレッド・ブルックス、『神話のマン・マンス』（1975年）

さらにこういうのもあるよ:

実際、悪いプログラマーと良いプログラマーの違いは、コードとデータ構造のどちらを重要視するかだと主張するよ。悪いプログラマーはコードを気にする。良いプログラマーはデータ構造とその関係を気にする。 -- リーナス・トーバルズ

HaskellやReScript/OCamlみたいな言語はCRUDアプリケーションにすごく合ってると思う。データと型についてまず考えさせられるから。その後、関数を通じてデータに対してどんな変換をしたいかを考える。新しいコードを見るときは、まず型を確認することが多い。具体的には、何が保存されていて、何が読み込まれているかをね。

ペルリスがたまに言及されるのを見るのは嬉しいね。SICPを再読してるけど、まだ新しいことを学んでるよ。

アラン・ケイとリッチ・ヒッキーのスレッドを思い出した。アラン・ケイは「データ」は悪いアイデアだと思ってる。彼の視点の解釈としては、必要なのはデータを「説明する」プロセスやインタープリター、ライブオブジェクトだってことだ。https://news.ycombinator.com/item?id=11945722 編集: 彼はQuoraでもっと詳しく書いてるよ。要するに、プログラミングの中心は「データ」じゃなくて「意味」だと言ってる。https://qr.ae/pCVB9m

100個の機能と1つのデータ構造があれば、グローバル変数でプログラミングしてるのとほぼ同じだよね。新しいインスタンスが新しいプロセスに相当する感じ。これ、あんまり良いルールじゃない気がする。

大学卒業したての頃に読んだ「Dive into Python」のこの引用は、プログラミングの本で読んだ中で一番影響を受けた言葉の一つだな。

「忙しい作業のコードは重要じゃない。データが重要だ。そしてデータは難しくない。ただのデータだ。もしデータが多すぎるなら、フィルターをかければいい。欲しいものでなければ、マッピングすればいい。データに集中して、忙しい作業は置いておけ。」

基本的に逆のことを言ってるんじゃない？パーリスは「正しいデータ構造を選ばず、人気のあるものにデータを押し込めろ」って言ってる。これは汎用プログラミングが広まる前は意味があったかもしれないけど、今は時代遅れだと思う。

ルール5. データが支配する。正しいデータ構造を選んで、物事をうまく整理できていれば、アルゴリズムはほぼ自明だ。プログラミングの中心はアルゴリズムではなくデータ構造だ。30〜40年コードを書いてきて学んだことはこれだ。

でも、2番目のルールはパイクの5番目のルールと直接対立してるんじゃない？これらはすべて、塩をひとつまみ加えて考えるべき格言のように思える。

2. 関数はバインディングを遅らせる; データ構造はバインディングを引き起こす。道徳: プログラミングプロセスの後半でデータを構造化すること。