プログラミングの学び方 - Geohot

The only advice I have for learning programming is go program.

これまでにたくさんのプログラミング系のチャンネルや記事を見てきたが、それでも Geohot の言っていることがいちばん端的で核心を突いていると思う。江湖一點訣、說穿不值錢――動画を見ただけで急に強くなるわけでもないし、AI の補助があるからといって突然ひらめいて開発者になれるわけでもない（もちろん、AI をうまく使えばその過程は確かに速くなる）。結局は、書き始めるしかないのだ。

この言葉は、彼が Lex Fridman Podcast に出演した回の一部を切り出したものだ。Podcast 全体は3時間あり、通して見る価値がある。

Geohot とは誰か

簡単に言うと、PS3 のキーを破って Sony に訴えられた人物であり、iPhone も突破して、iPhone を AT&T の回線以外でも動くようにしたことがある。近年は自動運転ソフトウェア comma.ai と、深層学習フレームワーク tinygrad（PyTorch みたいなものだと思えばよい）を作っている。tinygrad は、彼が Twitch 配信中に始めた小さなプロジェクトで、1000行以内で使いやすい深層学習フレームワークを作るのが目標だ。YouTube には配信アーカイブがあり、GitHub でコードを直接見ることもできる。

彼のもっと詳しい経歴については、別記事で紹介しようと思っている。

何の言語を学ぶべきか

Geohot が勧める順番は C、Assembly、Python、その次に3つの発展ルートだ。

1. Functional Programming。たとえば Haskell で、純粋関数の世界を理解する。彼自身、Haskell で簡単な Scheme インタプリタを書いたことがある。インタプリタを書くと、あるプログラミング言語がどうやって電脳が実際に実行できる形へ変換されるのかを理解できる。詳しくは彼の配信アーカイブを見ればよい。

2. Verilog あるいは他の HDL 言語で、ハードウェアの世界を理解する。ハードウェアとソフトウェアはまったく異なる心的モデルだ。Geohot は以前、fromthetransistor という Repository を立ち上げ、トランジスタから積み上げて簡易ブラウザを作るためのアウトラインを書いていた。概念的には From Nand To Tetris にとても近い。

3. Deep Learning。たとえば PyTorch だ。彼の学び方は、論文を直接読んで、それを tinygrad 上でどう実装するか考えるというものだ。実はこれが深層学習を学ぶうえで最も効果的な方法だ。そうしないと、多くのエンジニアは既存のフレームワークをそのまま使って、いくつかパラメータを調整するだけで、背後にある原理をまったく理解していないまま終わってしまう。

まずは土台がどう動いているかを理解するべきだ。C はどうコンパイルされて Assembly になるのか、そして Assembly から Stack、Heap、CPU、RAM といったコンピュータアーキテクチャの核心概念が自然に立ち上がってくる。それらを理解して初めて、Python が与えてくれるあらゆる恩恵に感謝できるようになる。

配信から何を学べるか

Geohot の配信には、拾えるものがたくさんある。

当時の配信では大半を Vim で書いていたが（VS Code の良さに気づいてからは VS Code に移行した）、 টাইピングも思考も非常に速い――本当に、彼の Vim の熟練度と、問題に直面したときにどこから手を付けるべきかが伝わってくる。

僕は以前、タイピング速度をそれほど気にしていなかったし、手をキーボードの上に置いたまま保つことにも特に注意していなかったが、これは思っていた以上に重要だ。遅いと、思考が途中で途切れやすい。これは LLM がまだ日常開発を代替できない時期のインタビューなので、手でコードを書くのが依然として主流だ。ただ、Geohot 自身の最近の配信では、手書きは少し減っていて、Opencode を使うことが増えている。

彼のデバッグのスタイルも見ておく価値がある。たとえ超一流のエンジニアでも、問題にぶつかれば文法を調べ、ドキュメントを確認する。それ以上の神秘的な技巧などない。配信では大量の試行錯誤が見られる。ここに log を1つ足し、あそこにも1つ足して、結果を確認する。単純だが効果的だ。彼はできるだけコードを簡潔に保ち、少し書いたらすぐ検証する。大量に書いてから動かし、問題が起きてもどこから探せばいいかわからない、というやり方はしない。

ここ数年で彼はかなり多くのプロジェクトを積み上げてきた。興味があれば、誰かがアーカイブしている YouTube チャンネル で宝探しするとよい。

なぜこういう人がこんなに稀なのか

最近、僕も気づいたのだが、まだ機能をそんなに書いていないのに、先に DDD だの最新フレームワークだのを叫び、状態管理は A だけでは足りないから B と C も重ねるべきだと言い、何かあるたびにリファクタリングだと叫ぶエンジニアが少なくない。しかし、リファクタリングへの理解は、コードの塊を関数に包んで別の場所へ移すことだったりする。その結果、機能がまだできていないのに、プロジェクトはすでに改修不能なくらい複雑になっている。

フロントエンドは性質上、Bundler なしで Web を書くのは確かに少し窮屈だが（それでも実現はできる）、実際のところ、多くの場面ではプロジェクトにそこまで派手な包装は必要ない。

Geohot は以前、半分冗談で「優れた Pull Request を送ってくれるなら、相手が人間でも猿でも気にしない。給料はバナナ払いでもいい」と言っていた。

僕の10年のキャリアでは、それぞれの分野をかなり深く理解しているエンジニアを何十人も一緒に仕事してきたが、底層まで透徹して理解している人はたった1人しか会ったことがない。そういう人と協力すると、問題を見る角度、デバッグの方向、「複雑さ」に対する許容度が、普通のエンジニアとは明らかに違う。