プログラムが動くまで — 機械語への翻訳

どの言語も、最後にCPUが読むのは機械語です。違うのはいつ・どこで機械語に翻訳するかだけ。この「翻訳のタイミング」で、実行のしかたが大きく3タイプに分かれます。

登場人物メモ:

• ※1 機械語 — CPUが直接実行できる、そのCPU専用の命令
• ※2 バイトコード — 特定CPU向けではない「中間の命令」。VMが解釈する
• ※3 仮想マシン(VM) — バイトコードを解釈して動かすソフト（例：JVM）
• ※4 ビルド — ソースから、実行できる形（実行ファイル等）を作り出す一連の作業

• コンパイル型（C など） — 実行の前にソース全体を機械語へ翻訳し、できた実行ファイルをCPUが直接動かす。翻訳済みなので速いが、翻訳結果が特定のCPU/OS向けになり環境に依存する
• インタプリタ型（Python など） — 実行時にソースを1行ずつ解釈しながら動かす。すぐ試せて手軽だが、翻訳しながら走るぶんやや遅い
• バイトコード＋VM（Java／JVM） — まず環境に依らないバイトコードへ翻訳し、それを各環境のVMが解釈して動かす。両者の中間で、そこそこ速く・環境をまたぎやすい

速さと手軽さ・移植性はトレードオフで、翻訳をいつ済ませるかがそのまま性能と持ち運びやすさに効きます。

コンパイルの中では、ソースが段階を追って機械語に近づきます。

1. 字句解析 — 文字の並びを、意味のある最小の単位（トークン）に切り分ける
2. 構文解析 — トークンの並びを、文法にそった構造（木）に組み立てる
3. 中間表現 — 特定CPUに縛られない中間の形にする（最適化しやすい）
4. 機械語の生成 — 対象のCPU向けの命令に落とす

この一連を含め、ソースから実行できる成果物を作る作業全体がビルドです。ライブラリの結合なども、ここで行われます。

• 環境依存で動かない — 実行ファイルは特定のCPU命令セットとOSの決まりに合わせて作られる。相手のCPU/OSが違うとそのままでは動かない（だからOS別に配布物を分ける）
• 依存の食い違い — 必要なライブラリやそのバージョンが実行先に無いと動かない
• 翻訳の見落とし — インタプリタ型は文法エラーがその行に来て初めて表面化することがある
• 最適化の副作用 — 速くするための最適化で、境界条件の挙動が変わってはまることがある

環境ごと丸ごと箱に詰めて「どこでも同じに動かす」発想はDockerへ。バージョン管理はGitで。