- Brian Kernighanは、Rob Pikeと共著した The Practice of Programming を、インターネット、Python、Perl、Javaが急速に広がっていた1999年に「プログラムをプロとしてうまく書く方法」を扱おうとした本として振り返る
- 例の一部は時代を経て古くなったものの、スタイル・デバッグ・書き方の姿勢 のような原則は、言語や環境が変わっても応用できると見る
- CSVパースは今でも厄介で、仕様も完全には明確ではなく、pandasは強力だが 重く抽象化のレベルが高いため、単純なPythonコードのほうがよい場合もある
- Bell Labsは、長期的な思考、優れた同僚、低い製品・収益プレッシャーのおかげで、Unix、yacc、文書準備ツールのような仕事が可能だった 研究環境 だった
- 大規模言語モデルは、2022年11月以降に突然大きな影響を与えた技術であり、ClaudeがspaCy関連のPythonコードをほぼ正しく生成した経験は、プログラマーの働き方の変化を予告している
1999年のプログラミング環境と本の目標
- The Practice of Programming は、KernighanとRob Pikeが以前に共著した The Unix Programming Environment から約15年後に出た本
- 本の目標は、「プログラムを実際にどう書くのか」「効果的かつプロフェッショナルにどう書くのか」を扱うことにあった
- 1999年ごろのコンピューティング環境は、今とは大きく異なっていた
- インターネットは一般の人々にとって1995〜1996年ごろに現れた比較的新しい存在だった
- Pythonは比較的新しい言語で、Perlは依然として強く、Javaも人気があった
- 具体的な例は現在の読者にはやや直接的ではないかもしれないが、一般原則 は別の環境にも持ち運べると見る
- 司会者たちは、スタイルガイドとデバッグの章が特に今でも有効だと考え、「bug」という言葉がGrace HopperのMarkコンピュータの逸話より前に、Thomas Edisonとphonographの文脈でも使われていた点を印象深く受け止めた
CSV、pandas、メモリと抽象化
- Kernighanは本にあったCSVパーサーの例について、今日でも優れた CSVパーサー はないと語る
- 昨年の夏、awkにCSV機能を追加しようとして、「まともなCSVパーサー」を書くのに数週間から1か月ほどかけた
- CSV仕様は完全には明確でなく、ある意味では標準化されていないと見る
- pandasは強力だが 重いツール と評価される
- 多くの場合、pandas流の暗黙的な反復や選択メカニズムを理解するより、Pythonを直接書いたほうが単純だと語る
- 司会者は、機械学習・データサイエンスの作業ではpandasがよく選ばれる一方で、重要な実行性能が必要なときはより単純なアプローチを考えると述べる
- メモリ管理は、現在では多くのプログラミングにおいてほとんど気にしなくてよい領域になったと見る
- Cではメモリを直接管理しなければならず、非常に難しい
- C++でも可能だが、正しく扱う技法を身につけるのは難しいという
- Pythonでは大半が「魔法のように」動くと表現する
- 大きな抽象化が常に問題を完全に隠してくれるわけではない
- spaCyで本一冊分のテキストを処理していたところ、基本のジョブ割り当て量が 1GB だったためメモリ不足のメッセージを受け取り、設定を2倍にして解決した
- Kernighanが育った時代には、キロバイト ですら大きなメモリだった
- 組み込みコミュニティでは今でもメモリと性能が非常に重視されており、CだけでなくRustやZigのような言語もその文脈で言及される
Go、Plan 9、Bell Labsの研究環境
- 司会者は、The Practice of Programmingの問題意識が Go言語設計 の土台のように感じられたと語る
- Kernighanは、Rob PikeがGoを作った3人のうちの1人であり、本で扱われた不便さが後に新しい言語を考える際の背景にあった可能性は「十分にあり得る」と見る
- ただし、Pikeが当時「新しい言語で世界を改善しよう」と考えていたという具体的な記憶はないという
- 1990年代後半のPlan 9の仕事と、Limbo、Alefのような言語がGoへとつながる系譜の一部だったと見る
- Bell Labsでの経験は、Kernighanにとって理想的な環境に近かった
- Princetonの大学院生だった1960年代に、夏のインターンとして2度Bell LabsでMultics関連グループと働いた
- その経験が良かったため、復帰の提案を受けて他では面接を受けなかったという
- 1969年初めから2000年ごろまでBell Labsにいた
- 当時のBell Labsでは長期的な思考が可能で、四半期業績やすぐに製品・収益を出せという圧力が少なかった
- 人々は、興味深く重要だと思う仕事を比較的独立して進めることができた
- AT&Tが米国の大半に電話サービスを提供していた時期だったため、「問題の多い環境」であり、電話システムに役立つ可能性のある仕事も多かった
- Claude Shannonと直接会ったことはなかった
- ShannonはKernighanがBell Labsに来る数年前にMITへ移ったと記憶している
- Kernighanは、Shannonとオフィスを共有したことのあるRichard Hammingとは親しかったという
学び、本を書くこと、プログラミング的思考
- Kernighanの初期の学びは、Bell Labsで優れた人々、道具、興味深い問題に触れるなかで進んだ
- yaccは新しいプログラミング言語を簡単に作れるようにしたツールで、Kernighanはこれを従来の言語生成だけでなく、文書準備 や宣言的言語のような領域にも活用した
- 文書準備ツールにも長く関心を持っていた
- MITの初期の対話型テキスト準備プログラムrunoffの影響を受けた
- Princetonでは、自分の論文を作るためにFortranで似た文書準備プログラムを書いた
- Bell Labsでは、本を物理的により簡単に作成し、出版過程でプログラム例が壊れないようにするツールを作った
- 大学へ移ってからは、すでに知っている内容を非専攻の学生に説明する過程が重要な学びになった
- 文学や音楽に強い学生に、2進数がどう動くかを説明しなければならなかった
- Leibnizが1600年代後半の2進数の実質的な発明者であり、文字の代わりに音符を使って16進表記に似たものを作っていたことも、その過程で学んだという
- 本を書く動機は、「語る価値のある何か」と「一緒に語りたい共著者」がいるときに生まれるという
- Kernighanの本の大半は共著である
- 共同作業は互いの内容を補い磨けるため、1人で書くよりはるかに楽だと見る
大規模言語モデル、教育、推薦図書
- Kernighanは、自身のキャリアで重要だった発展として タイムシェアリングシステム、Unix、プログラミング言語の進化、Mooreの法則による資源増加、PCを挙げる
- タイムシェアリングは、物理的にコンピュータの前にいる必要やオペレータ処理を待つ必要なく、自分の予定に合わせて作業できるようにした大きな変化だった
- クラウドコンピューティングは、計算が集中化され、利用者は遠くのシステムと通信する高度な周辺装置を持つという点で、再びタイムシェアリングに近い形だと見る
- 現在もっとも興味深い技術としては 大規模言語モデル を挙げる
- 2022年11月ごろに突然現れ、短期間で大きな影響を与えた点が特異だと見る
- ClaudeにspaCy関連の作業を2〜3文で頼んだところ、約99.9%正しいPythonコードを生成し、Pythonの使い方も自分より洗練されていたと語る
- プログラマーが消えることはないだろうが、働き方は変わる可能性があると見る
- LLMは学生に新しいアプローチを開く
- ある学生は、古代Greekの翻訳改善にLLMを活用できると考えていた
- 1700年代の古い印刷文書のOCR結果を、言語モデルが持つ言語知識を使って改善できるという
- 非専攻者向けの授業では、コンピュータがどう動くかと、世の中で起きている技術問題を結びつけようとしている
- 受講生には人文学・社会科学の学生が多く、定量的推論要件を満たすために履修する場合が多い
- ハードウェア、ソフトウェア、通信、net neutrality、privacy、security、Google antitrustのようなテーマを技術的背景とともに扱う
- 大きな仕事を小さな仕事に分け、段階的に考える プログラミング的思考 は、論文執筆や法律問題の分析のような他分野にも移せると見る
- 初心者には、自分がやりたいことを見つけるのが重要だという
- ゲーム作り、個人財務の改善、テキスト分析のように、関心のある問題から始めれば心理的ハードルを下げられる
- 非専攻者向け授業では、NLTKでPride and Prejudiceを分析した後、学生が望む別の本を選んで同じ方法で探究する課題を使っている
- 推薦・言及された本と読書の好みは幅広い
- 技術書では The Mythical Man-Month を時々読み返し、一部はよく古びていない一方で、一部の言語表現は現在の基準では非常に性差別的に見えると語る
- Jennifer Pahlkaの Recoding America は、政府ソフトウェアがなぜ期待ほどうまく機能しないのか、そしてシステムがなぜ改善を難しくしているのかを扱う興味深い本として言及される
- 非技術系の読書としては、歴史、軍事史、探偵小説、Dick Francisの競馬小説、半導体を扱う Chip War を挙げる
1件のコメント
Hacker Newsの意見
この本は基礎になる本なので、すべてのプログラマー、特に初心者が読むべき
Kernighanの本らしく、文章は単純で簡潔かつ正確で、無駄なく核心だけが200ページ少しに収められている。例で原理を理解したあと、自分の文脈に当てはめればよい
K&P本の長所は、理論で圧倒するのではなく技術の実際の適用を見せ、そのあとで理論学習がより取り組みやすくなる点にある
たとえばネットワークプログラミングとプロトコル実装の経験がある状態でこの本を読んだが、"Notations"章で
printf/scanfスタイルの書式文字列でパケットレイアウトを指定するネットワークメッセージの pack/unpack ルーチンが示されていて、目が開かれるような体験だった。適切な記法と小さな言語の力を学べるし、仮想マシン、コードスレッディング、JITコンパイルのアイデアを示すコード片もあるKernighanとPikeのさらに古い本 "The Unix Programming Environment" も一緒に読む価値がある。"Program Development"章は、コンパイラ開発ツールを使って小さな計算機言語用のコンパイラを作る全過程を約50ページに収めており、私の知る限りコンパイラの書き方を最も小さく単純に説明した文章だ
結論として、Kernighanの本は全部買って勉強する価値がある
Cの本は昔読んだことがあり、文章が素晴らしかった記憶がある。プログラミングの知恵も多く得られるだろうが、技術文章の観点でもKernighanの本がなぜあれほど良いのか分析してみたい
Kernighanは文章作法をかなり勉強したか、少なくとも文章について第一原理的に多く考えた人のように思える。"The Elements of Programming Style" という題名も、StrunkとWhiteの有名な文章作法の本 "The Elements of Style" を参照したものだ
今の基準では少し古びているが、今でも読みやすい本だ
皮肉ではなく、キャリアで順調にやっている人にとってもなぜ必読書なのか知りたい
"The Practice of Programming" が本当に好き
これまで読んだプログラミング本の中で、この本の教訓がいちばん強く残っている。ここ数年読み返してはいないが、日々の実践に影響を与え続けていると感じる
具体的なプログラミング例の一部はかなり古いが、一般的なアイデアは今でも堅実だ
Kernighanが好きだ。本当に謙虚な人だ
YouTubeのある動画で、博士論文で難しい問題を解いていたが、あとになって理論が整備される前のNP完全問題だったと分かったという話をしていた
論文をお願いするメールを送ったらかなり早く返事をもらい、読んでみると本当に興味深かった
私や多くの人にとって、彼のプログラミングに関する考えが最も興味深く有用な部類に入るのは、そのかなりの部分が彼がそれを非常に明快に伝えられるからだ
最近の面接はLeetCodeより、この本に出てくる概念理解を見る方向になってほしい
このばかげた新世界では、Brian KernighanでさえLeetCode hardの面接に通らないかもしれない
どれもかなり実践的なプログラミング課題だった。Stripeには、Jackson Javaライブラリをforkしてバグを仕込んでおき、それを見つけて直せという面接があった。かなりユニークだったが、実際のプログラミング業務にはずっと近かった
mRNAでノーベル賞を受けたKatalin Karikóが研究費を取ってこられないという理由でUPennで降格された件も思い出す
Kernighanと彼の本たちに匹敵するほど優れたカテゴリの別の著者としてJon Bentleyがいて、彼の本にProgramming PearlsとMore Programming Pearlsがある
https://en.m.wikipedia.org/wiki/Jon_Bentley_(computer_scient...
この本は効率性について、アルゴリズムと言語を中心に上から考える方法を教えてくれるので、すべてのプログラマーに有益だ
Agner Fog、Fedor Pikusらの現代的な効率性の本は主にコンパイラ/OS/プロセッサレベルの性能技法を扱うので、一緒に読むと全体像がつかめる
みんな、gは発音しない
Rob Pikeを出演させるといいかもしれない。たぶん発音の訂正はきっちり指摘するはずだ。もう声が聞こえる気がする
Rob Pikeにもぜひ来てもらいたい。今進めているが、連絡を取るのが少し難しい方だ
動画の3分の1ほどしか見ていないけれど、司会者たちが 洞察に富んだ質問 をかなりうまく投げかけているのが分かった
私は動画の司会者の1人、Carterです。楽しんで見てもらえてうれしいです。Brian Kernighanと話すことができたのは本当に大きな栄誉でした
この形式は本を扱うので、説明欄やコメントの一部に、取り上げた本や、できれば メディア一覧 を整理しておくとよいと思う
「The Bit Player」（2018年のClaude Shannonドキュメンタリー）を視聴リストに入れ、「Recoding America」「Chip War」「Endurance: Shackleton's Incredible Voyage」も読書リストに加えた
ポッドキャストで取り上げる本の一覧に、Kernighanの Software Tools in Pascal も追加するとよいと思う
その本を持っているけれど、良い本だと思う
KernighanとPlaugherはまず「Software Tools」をRATFORで書き、その後「Software Tools in Pascal」を書きました。そしてその経験への直接的な反応として、Kernighanは「Why Pascal Is Not My Favorite Programming Language」という論文を書きました
Pascalで書くほうがRATFORで書くよりずっと簡単であるべきだったのに、実際はそうではなく、Kernighanはなぜそうだったのかを考えたのです
今でも興味深い文章で、たとえばここで読めます: https://www.cs.virginia.edu/~evans/cs655/readings/bwk-on-pas...
ただし、この文章が指しているのはもともとの標準Pascalです。Turbo Pascalのような拡張は多くの問題を解決しました。ただ、彼が言うように、拡張同士には移植性がありませんでした。それでもTurbo Pascalが事実上の「標準」拡張になったことで、ある程度は解消されました
アイデアと文章に感銘を受け、それがきっかけでKernighanの他の主要な著作も探して読むようになった
Kernighanは、少なくとも初版に関しては The Go Programming Language の共著者でもある